SPF, DKIM and DMARC: An Email Authentication Workflow
Inspect SPF, DKIM and DMARC in a sensible order without confusing published DNS with successful delivery.
Inventory the services that send for you
Begin with a list of the systems you actually use: a mailbox provider, newsletter platform, transactional service and any support or invoicing software. For each, record the visible From domain, expected return-path domain and the DKIM selector supplied by the provider. This inventory gives DNS results context. A record can look plausible in isolation while omitting a service that sends legitimate mail or retaining a service that your organization no longer uses.
SPF describes an authorized sending path
SPF evaluates a sending IP against policy associated with the envelope sender domain, rather than simply reading the visible From address. Its include and redirect structure can depend on further DNS responses. Use the SPF checker to inspect the published or pasted record and its conservative lookup estimate. A static count cannot fully reproduce every message-dependent evaluation. If a DNS request does not complete, keep the result inconclusive instead of treating the unavailable record as a pass.
DKIM connects a signature to a published key
A sending system signs message content with a private key. Receivers use the selector and signing domain to locate a public key in DNS, commonly under selector._domainkey.example.com. This checker can inspect publication, common tags and base64 encoding. It does not validate an RSA key’s ASN.1 structure or modulus strength. It cannot verify a message without that message’s signature and signed content. Record the selector your provider actually uses; querying a guessed selector can produce an absence that says little about another valid selector.
DMARC brings the visible sender into the comparison
DMARC checks alignment between the visible From domain and a successful SPF or DKIM identity, and publishes a requested handling policy. A record checker helps inspect the tags and policy; a generated record is a draft to review against your sending inventory. Do not assume changing policy fixes an unaligned service. Confirm the authentication setup of each service first, then use observations and provider guidance when deciding how to handle messages that fail the aligned checks.
| Check | Uses | Does not establish |
|---|---|---|
| SPF record | Envelope-sender policy | Visible From alignment or inbox placement |
| DKIM record | Published selector key and basic encoding | RSA key structure or a message signature pass |
| DMARC record | Alignment settings and requested policy | That every sending service is aligned |
| Headers / reports | Receiver-reported observations | Authenticity of arbitrary pasted evidence |
Use real messages and reports as separate evidence
For a practical check, send an ordinary test message through each expected service and inspect the headers added by a trusted receiving system. Compare the visible domain, return path and signing domain with your inventory. DMARC aggregate reports provide another view: sources, message counts and reported authentication outcomes over a period. Use the report reader to identify a source worth investigating. A report can summarize failures, but it does not automatically explain whether they are abuse, forwarding or a legitimate misconfiguration.
Keep scope and trust visible
Pasted headers and XML reports are data supplied to the tool; the reader does not establish their authenticity. A copied Authentication-Results line from an untrusted part of a message should not outweigh the recipient provider’s own trusted results. Likewise, a public DNS key proves publication, not that your service signed the message you inspected. Keep a short evidence log containing the record, the relevant message or report, the provider and the time of the check before drawing a conclusion.
Investigate delivery with a broader checklist
Passing authentication is only one part of mail delivery. Gmail publishes sender requirements that also cover sending infrastructure, message formatting and user-facing practices. Start a delivery investigation with the exact receiving provider’s response and a reproducible example. Review changes to your sender inventory before changing DNS again. Authentication tools clarify records and observations; they cannot promise inbox placement, bypass a provider’s policies or determine reputation from a single record check.