Email authentication methods: SPF, DKIM, and DMARC explained

The three core email authentication methods are SPF, DKIM, and DMARC. SPF checks whether the connecting server is authorized for an envelope domain. DKIM checks a domain-backed cryptographic signature on the message. DMARC connects one of those passing identities to the domain people see in the From address, then adds policy and reporting.

They are complementary, not interchangeable. A message can pass SPF and still fail DMARC. It can fail SPF after forwarding and still pass DMARC through DKIM. It can pass all three and still be unwanted or malicious. A useful deployment therefore asks which identity each method authenticates, whether that identity aligns, and what the result actually proves.

SPF vs DKIM vs DMARC at a glance

METHOD  CHECKS                                IDENTITY USED                         COMMON FAILURE
SPF     connecting IP is authorized          MAIL FROM / Return-Path or HELO       forwarding changes the connecting IP
DKIM    signed headers and body still verify  DKIM-Signature d= domain + selector   gateway or list modifies signed content
DMARC   SPF or DKIM passes and aligns          visible RFC 5322 From domain          auth passes only for provider domains

DMARC pass = aligned SPF pass OR aligned DKIM pass.
Authentication is evidence of domain identity, not consent or inbox placement.

The visible From, SMTP envelope sender, DKIM signing domain, and connecting IP are separate fields. Mailbox interfaces often hide all but the From address, which is why raw headers matter. Green checkmarks in a sending dashboard show that records were found; a received message shows which identities the receiver evaluated in production.

SPF authorizes an IP for an envelope identity

Sender Policy Framework is published as a DNS TXT record. During SMTP delivery, a receiver checks whether the connecting IP is authorized by the SPF policy for the MAIL FROM domain. When MAIL FROM is empty, as it normally is for a delivery-status notification, SPF can evaluate the HELO identity instead. SPF does not authenticate the visible From header by itself.

example.com. TXT "v=spf1 include:_spf.workspace.example include:mail.vendor.example -all"

CONNECTING IP -> receiver expands the policy for the envelope domain
include       -> delegate part of authorization to a named service
-all          -> IPs not matched by the policy fail

Publish one SPF record per name. Merge authorized sources into that policy;
do not publish a second v=spf1 record to add another provider.

SPF has a limit on DNS-querying mechanisms during evaluation. Nested includes, redirects, MX lookups, and other mechanisms can exhaust it even when the record looks short. Flattening records by hand creates a different risk because provider IP ranges change. Prefer a narrow sender inventory, provider-supported includes, subdomain separation where useful, and continuous validation.

DKIM signs the message with a domain key

DomainKeys Identified Mail adds a DKIM-Signature header. The sending system hashes the selected headers and body, signs that result with a private key, and identifies a signing domain in d= and selector in s=. The receiver retrieves the public key from selector._domainkey.signing-domain and verifies the signature.

DKIM-Signature: v=1; a=rsa-sha256; d=mail.example.com; s=tx2026; ...

Receiver lookup:
tx2026._domainkey.mail.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY..."

Verify all three:
1. dkim=pass in the final receiver's Authentication-Results
2. header.d is the domain you expected
3. header.s is an active selector owned by that sending service

A DKIM pass means the signed parts verified against the published key. It does not mean every header was signed, the signer is trusted, or the recipient requested the message. A provider can validly sign with its own domain; that proves the provider's identity but will not help DMARC for your From domain unless the DKIM d= domain aligns with it.

Use a different selector for each service or key generation. That lets you rotate one key without interrupting another and identify the owner of a signature during an incident. Keep private keys in the sending service, publish only the public record, use current provider-supported key sizes, and remove old selectors after the transition and queued-mail window have passed.

DMARC adds visible-From alignment, policy, and reports

DMARC evaluates the domain in the visible RFC 5322 From header. It passes when SPF passes with an aligned envelope domain or DKIM passes with an aligned signing domain. Relaxed alignment generally allows related domains under the same organizational domain; strict alignment requires the domains to match exactly.

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

MONITOR  p=none        collect aggregate evidence; no requested enforcement
CONTAIN  p=quarantine  ask receivers to treat failures as suspicious
ENFORCE  p=reject      ask receivers not to accept failing mail

Receiver handling remains local policy. A DMARC record is not a command
that every mailbox applies identically.

The current core DMARC standard is RFC 9989, published in May 2026. Aggregate reporting is specified separately in RFC 9990. Older rollout articles commonly recommend the pct tag; RFC 9989 removed it. The current protocol adds t=y for a testing policy, but receiver adoption changes over time, so reports, controlled domains, and measured policy changes remain safer than depending on one tag.

Where ARC, BIMI, and transport security fit

Authenticated Received Chain records authentication evidence observed by intermediaries and seals the chain as a message passes through them. It can help a final receiver evaluate forwarded or mailing-list traffic after SPF or DKIM changes. ARC does not make DMARC pass and does not tell a receiver to trust an intermediary; the receiver decides how much weight to give the chain.

BIMI lets an eligible domain publish a brand indicator that supporting mailbox providers may display. It depends on strong authentication and provider-specific eligibility, but it is not a replacement for SPF, DKIM, or DMARC. A valid BIMI record never guarantees that a logo will appear.

TLS protects the connection between mail systems. MTA-STS and DANE can strengthen transport policy, while TLS reporting provides failure visibility. These controls address transport confidentiality and downgrade resistance; they do not authenticate the visible author identity the way DMARC does. Likewise, S/MIME and OpenPGP can authenticate or encrypt content for users, but they solve a different layer.

Verify authentication from a real received message

• Send one message from every production service and meaningful From domain to controlled Gmail, Microsoft, and other representative inboxes.
• Download the original source. Screenshots and forwarded copies can omit or replace the evidence you need.
• Find the final receiver's Authentication-Results header and record SPF, DKIM, DMARC, ARC, and evaluated domains.
• Compare smtp.mailfrom or Return-Path with the visible From domain for SPF alignment.
• Inspect every DKIM result, d= domain, and selector; one message can carry multiple signatures.
• Confirm DMARC passed through the path you expected rather than an unrelated aligned source.
• Repeat for transactional, marketing, support, billing, recruiting, and employee systems; one test does not represent the domain.

From: Acme Billing <[email protected]>
Return-Path: <[email protected]>
DKIM-Signature: ... d=receipts.example.com; s=tx2026; ...
Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=receipts.example.com;
  dkim=pass header.d=receipts.example.com header.s=tx2026;
  dmarc=pass header.from=example.com

Both authenticated domains align under relaxed DMARC alignment.

Deploy email authentication without breaking legitimate mail

• Inventory every service that uses the domain in From, including overlooked support, finance, recruiting, survey, CRM, and ticketing systems.
• Give every approved service an owner, purpose, DKIM selector, envelope domain, and retirement plan.
• Publish one valid SPF policy and remove obsolete authorization rather than accumulating includes forever.
• Enable aligned DKIM for every important stream; it is generally more resilient than SPF under forwarding.
• Publish DMARC reporting, classify sources by owner, and repair known unaligned traffic before enforcement.
• Use dedicated subdomains where traffic behavior, ownership, or enforcement risk differs.
• Change one policy boundary at a time and retain a tested rollback record.
• Continue monitoring after enforcement because vendors, selectors, routes, and organizational ownership change.

What email authentication cannot guarantee

Authentication is necessary sender-identity evidence, not a reputation score or permission receipt. A compromised authorized account can send a message that passes. An attacker can register a lookalike domain and authenticate it correctly. Wanted mail with poor list practices can pass every protocol and still receive complaints or land in spam.

Treat SPF, DKIM, and DMARC as the identity layer beside consent, suppression, secure credentials, monitored forms, recognizable content, controlled volume, and receiver-specific delivery evidence. The goal is not three DNS checkmarks. It is a system in which every legitimate sender can prove its relationship to the domain people see—and unexplained use becomes visible enough to investigate.