SPF, DKIM, and DMARC: what RFC 7208, 6376, and 7489 define

RFC 5321, the base SMTP specification, has no concept of sender authentication built in. Any server can open a connection and claim any MAIL FROM or From address it wants. Three separate standards, published years apart, each close one piece of that gap. None of them is sufficient alone.

What SPF, DKIM, and DMARC each close

SPF (RFC 7208) authorizes which IP addresses may send on behalf of a domain, via a DNS record. DKIM (RFC 6376) cryptographically signs a message so a receiving server can verify it wasn't altered in transit. DMARC (RFC 7489) ties the two together: it requires at least one to pass and align with the visible From domain, and it defines the policy a receiving server applies when neither does.

Each standard answers a different question. SPF answers "did this come from an authorized server." DKIM answers "was this message altered." DMARC answers "what should happen when the answer to either is no."

RFC 7489 states its own scope directly:

"Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling."

How each standard works

SPF: a receiving server queries the sending domain's DNS TXT record, checks the connecting IP against the mechanisms listed there, and returns pass, fail, softfail, or neutral based on the first match.

DKIM: the sending side computes a hash of selected headers and the body, encrypts that hash with a private key, and attaches the result as a DKIM-Signature header. The receiving side fetches the corresponding public key from DNS, decrypts the signature, and compares it against a hash it computes itself.

DMARC: the receiving server checks whether SPF or DKIM passed, then checks whether the passing protocol's domain aligns with the From header the recipient sees. If neither passes aligned, it applies the domain's published policy, none, quarantine, or reject, and sends aggregate reports back describing what it saw.

Anatomy of the three records

SPF record (a single DNS TXT record):

DKIM (a header plus a DNS-published public key):

• v, a, d, s, h, bh, b (in the DKIM-Signature header): version, algorithm, signing domain, selector, signed headers, body hash, signature.
• v, k, p (in the {selector}._domainkey.{domain} TXT record): key version, key type, base64 public key.

DMARC record (a single DNS TXT record at _dmarc.{domain}):

One message, traced through all three

A message from globex.example, From: hello@globex.example, connecting from an IP listed in globex.example's SPF record and signed with a DKIM key published under the same domain:

1. SPF: the receiving server checks the connecting IP against globex.example's SPF record. Match found. SPF pass.
2. DKIM: the receiving server fetches the public key at the signature's selector, verifies the signature against the message. Hashes match. DKIM pass.
3. Alignment: both the SPF envelope domain and the DKIM d= value match globex.example, the domain in From. Both align.
4. DMARC: at least one aligned pass exists. DMARC pass. The published policy is not applied.

The receiving server records the combined result in one header:

Authentication-Results: mx.inbox.example;
  spf=pass smtp.mailfrom=globex.example;
  dkim=pass header.d=globex.example header.s=selector1;
  dmarc=pass header.from=globex.example

Where these standards stop working

None of the three holds up under every path a message can take. SPF fails when a message is forwarded, since the envelope sender changes to the forwarder's domain, a domain never listed in the original SPF record. DKIM fails when a mailing list rewrites the subject line or appends a footer, since that invalidates the signed hash. DMARC fails whenever either does, since it needs at least one aligned pass.

This is the gap RFC 8617 (ARC) exists to address: a way for an intermediary to record what authentication looked like when it received the message, so a later hop's failure doesn't erase that history.

Check it yourself

Three lookups confirm all three records exist: the SPF TXT record, filtered for the spf1 prefix; the DKIM public key at your provider's selector; and the DMARC policy at _dmarc.

dig +short TXT yourdomain.com | grep spf1
dig +short TXT <selector>._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com

A message you've already received tells the same story from the other side: open its raw source (Gmail's "Show original") and read the Authentication-Results header a receiving server actually wrote.

Where this fits

This page covers what SPF, DKIM, and DMARC define as standards. For the step-by-step walkthrough of configuring them for your own domain, records, rollout order, common pitfalls, see the practical configuration guide. For what happens when a message passes through an intermediary, see ARC. For the connection-level standards that protect a message in transit rather than its authenticity, see transport security. For the full standards landscape, see the reference hub.

SPF checks the SMTP envelope's MAIL FROM, not the visible From header a recipient sees, a distinction that page covers in detail.

FAQ

Do I need all three, or is one enough?

Each covers a different failure mode, and DMARC itself requires at least one of SPF or DKIM to pass aligned. Running only one leaves the other's failure mode uncovered.

Can SPF pass while DMARC still fails?

Yes. SPF can pass on a domain that doesn't align with the visible From header. DMARC requires both a pass and alignment, so an unaligned SPF pass doesn't satisfy it.

Is DKIM alone enough to stop spoofing?

No. DKIM verifies a message wasn't altered, but without DMARC there's no policy telling a receiving server what to do when DKIM, or SPF, fails.

Why does SPF break when a message is forwarded?

The envelope MAIL FROM changes to the forwarding server's domain, a domain that was never listed in the original sender's SPF record.

RFC reference

RFCs covered: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC). Superseded / updated by: RFC 6376 is updated by RFC 8301 (deprecates SHA-1 and 512-bit keys) and extended by RFC 8463 (adds Ed25519-SHA256). RFC 7208 and RFC 7489 have no successor.