SPF vs DKIM vs DMARC

At a glance

The three records answer three different questions. SPF asks whether the server is allowed to send for a domain. DKIM asks whether a domain signed the message and whether it arrived unchanged. DMARC asks whether either of those domains matches the address the reader actually sees, and tells receivers what to do when none does.

The last row is the reason you need all three. SPF and DKIM each authenticate a domain, but that domain can belong to anyone, including whoever is spoofing you. DMARC is what connects their results to your From address, and it has no result of its own to offer until one of them passes.

SPF: is this server allowed to send?

SPF checks one domain from the SMTP envelope: the address in the MAIL FROM command, which receivers usually record as the Return-Path header. RFC 7208 also recommends checking the name the server announced in HELO, and for bounces, whose envelope sender is empty, it uses postmaster@ plus the HELO name instead. The receiver fetches the TXT record published at that domain and checks whether the connecting server's IP address is on the list. What is SPF? covers the record syntax, the 10-lookup limit and which ending to use.

What SPF doesn't check

• The From address. Section 11.2 of RFC 7208 spells this out: a sender can pass SPF with its own domain in the envelope and still put any address it likes in the From header.
• Who the sender is. SPF maps a domain to a set of servers, not to people. Section 11.4 notes that it cannot tell two users of the same mail server apart.
• The content. A pass means the server was allowed to send. It says nothing about what the server sent.

SPF and forwarding

SPF is evaluated against the IP address of the last server that handed the message over. When a forwarder relays your message and keeps your envelope sender, the receiver sees the forwarder's IP address, which your record doesn't list, and section 10.3 of RFC 7208 says the check will fail. Some forwarders rewrite the envelope sender to an address of their own, which avoids the failure, but then SPF passes for their domain, not yours.

DKIM: did this domain sign it, unchanged?

DKIM adds a signature to the message in a DKIM-Signature header. Its d= tag names the signing domain and its s= tag the selector, and the receiver fetches the public key from selector._domainkey under the d= domain (RFC 6376 section 3.6.2.1). A valid signature proves two things: the d= domain took responsibility for the message, and the headers and body it signed have not changed since. Section 1.5 is careful about how far that goes: verifying says the signed parts are unchanged and makes no wider promise about the message's integrity, such as the parts that weren't signed. What is DKIM? covers selectors and key length.

What DKIM doesn't check

• That the signer is the author. The From header must be one of the signed fields (section 5.4), but section 1.2 deliberately keeps the signing domain separate from the author: the d= domain is not required to match any address in the message. Anyone can sign mail that claims to be from you with a domain they control, and the signature will verify.
• Who receives it. A signed message can be re-sent to new recipients and still verify. Section 8.6 describes spammers doing exactly that with mail signed by a well-known domain.
• Unsigned mail. On its own, DKIM gives receivers no instruction about a missing or broken signature. Section 6.3 says a missing or unverifiable signature alone should not be the reason to refuse a message.

DKIM and forwarding

The signature travels inside the message, so it doesn't matter which server delivers it. Section 1 of RFC 6376 notes that relays typically make no substantive change to the content and so preserve the signature. It breaks when someone edits what was signed. Mailing lists are the usual case: section 5.3.1 calls it very common for them to add a trailer to the body.

DMARC: does it match the From address?

DMARC is the only one of the three that checks the From domain, the address a mail app shows the reader. RFC 9989 calls it the Author Domain. DMARC doesn't authenticate anything by itself. It takes the domains that SPF and DKIM verified and checks whether either of them aligns with the From domain, and a single aligned pass is enough. On top of that it adds what neither of the others has: a policy (p=none, quarantine or reject) telling receivers what you want done with mail that fails, and rua reports showing who sends mail as your domain. The record is a TXT at _dmarc under your domain. What is DMARC? covers the policies and reports, and DMARC alignment explained covers what counts as a match.

What DMARC doesn't check

• The rest of the address. Section 4.1 of RFC 9989 says DMARC validates the domain only, not the local part before the @.
• The display name. A message from "Your Bank" <alerts@example.net> passes DMARC as long as it was sent with SPF or DKIM that the owner of example.net set up. Sections 2.4 and 11.4 put display name attacks explicitly out of scope.
• Whether the message is wanted. A pass only says the domain owner authorized the use of the domain. RFC 9989 states that it carries no value assertion about the message and does not guarantee inbox delivery, and receivers are free not to follow your policy.

DMARC and forwarding

DMARC inherits the behaviour of the two checks under it. After a plain forward, SPF usually fails but an aligned DKIM signature usually survives, so DMARC still passes. That is why section 7.4 of RFC 9989 says domains that publish p=reject must not rely on SPF alone and must sign their mail with DKIM. When a mailing list changes the message, DKIM breaks as well, and DMARC fails unless the list rewrites the From line, which RFC 9989 says list software now widely does. Forwarding and mailing lists explains what this means before you enforce.

The order to set them up

Section 5.1 of RFC 9989 asks domain owners to send mail with at least one, and preferably two, identifiers that align with the From domain. In practice, two is better because each covers a gap in the other: DKIM survives forwarding, and SPF still gives an aligned pass on direct delivery if a signature fails to verify. The order follows from what each record depends on:

1. SPF. Publish one record that lists every server and service sending with your domain in the envelope. Build it with the SPF generator and check the lookup count with the SPF checker. Services that bounce to their own domain won't align through SPF, whatever your record says; why SPF often isn't aligned explains the fix.
2. DKIM. Turn on signing with your own domain in every service that sends for you, then confirm the keys are published with the DKIM checker.
3. DMARC with p=none and reports. Section 5.1.4 says to publish the DMARC record once SPF, DKIM and a mailbox for aggregate reports are in place, starting with p=none and a rua address. The DMARC generator builds one. This changes nothing about delivery; it starts the reports.
4. Fix, then enforce. The reports show legitimate senders that fail alignment, and section 5.1.6 says those must be fixed before you move to an enforcing policy. Section 5.1.7 warns that getting there can take many months of reports. Moving from p=none to p=reject lays out the stages.

To see where a domain stands on all three at once, run the domain health check.