SPF vs DKIM vs DMARC: what is the difference?

What does SPF do?

SPF answers one question: is the server that delivered this message allowed to send for the domain? The domain owner publishes a TXT record that starts with v=spf1 and lists allowed sources, for example include:_spf.protonmail.ch for Proton Mail. A receiver compares the connecting IP address with the list and gets a result: pass, fail, softfail or neutral, depending on the qualifier at the end (-all, ~all or ?all).

SPF checks the envelope sender (the MAIL FROM) and the HELO name, not the From address that the reader sees. That gap is the reason DMARC exists. SPF also has hard limits: a domain must have only one SPF record, and evaluation stops with a permanent error after 10 DNS-querying terms (include, a, mx, ptr, exists, redirect). The full method is in the guide to creating an SPF record.

What does DKIM do?

DKIM answers a different question: was this message signed by the domain it claims, and did it arrive unchanged? The sending server signs selected headers and the body with a private key. The receiver reads the signing domain (d=) and the selector (s=) from the DKIM-Signature header, fetches the public key at selector._domainkey.domain in DNS and checks the signature.

Because the signature travels with the message, DKIM survives a forward that leaves the message intact, which SPF does not, since a forwarder sends from its own IP address. RFC 6376 says signers must use RSA keys of at least 1024 bits for long-lived keys, and recommends new selectors when keys change. Providers publish the keys for you: three CNAME records for Proton Mail and Fastmail, four for Mailbox.org. Details are in the guide to setting up DKIM.

What does DMARC do?

DMARC ties SPF and DKIM to the visible From domain and tells receivers what to do when neither check lines up. A message passes DMARC when SPF or DKIM passes and the domain it authenticated matches the From domain. Alignment is relaxed by default (same organizational domain) and strict when set with aspf=s or adkim=s.

The record sits at _dmarc.yourdomain and carries a policy: p=none (monitor only), p=quarantine (treat as suspicious) or p=reject (refuse). An rua address receives aggregate reports, which show who sends mail in your name. RFC 9989, published in May 2026, is the current specification; it obsoletes RFC 7489, removes the pct tag and adds a t test flag. The rollout from monitoring to rejection is in the guide to setting up DMARC.

Do I need all three?

Yes: a custom domain that sends mail should publish SPF, DKIM and DMARC, because major receivers ask for them. Google's sender guidelines require SPF, DKIM and a DMARC record (policy none is enough) for senders above 5,000 messages a day to Gmail accounts. Microsoft asks Outlook.com senders above 5,000 a day for the same three, from 5 May 2025, and Yahoo requires SPF, DKIM and DMARC for bulk senders too.

A personal mailbox sends far fewer messages, so the thresholds do not bind you. The records still decide whether your mail reaches the inbox, and they stop others from forging your address. According to Postelva's count of 12 November 2026 from provider help pages, a full Proton Mail setup takes 8 DNS records and a full Mailbox.org setup takes 11, of which 3 and 4 are DKIM keys. The MX records are covered in what an MX record is.

Which mistakes break the three records?

Three mistakes cause most failures: a second SPF record, more than 10 lookups, and a DMARC policy set too strict too early. A domain with two SPF records returns a permanent error, so add the new provider's include to the existing record. Stacking a mail host, a newsletter tool and a helpdesk can push the lookup count past 10, and the record then fails for every sender. Mailbox.org and Proton both advise starting DMARC at p=none, and Mailbox.org warns that a strict policy applied too early can bounce legitimate mail.

A fourth mistake is keeping the previous provider's DKIM and SPF entries for months. They do no harm to delivery, but they widen the list of servers allowed to speak for you. Remove them once the move is confirmed.

How do the three work together on one message?

The receiver runs SPF and DKIM, then DMARC combines the results. Take a message from [email protected] sent through Proton Mail. SPF passes if the connecting server is in the _spf.protonmail.ch list. DKIM passes if the signature made with the key under yourname.com verifies. DMARC then asks whether at least one of the two passed with yourname.com in the aligned identifier. If yes, the message passes; if not, the receiver applies your policy and files the result in the next aggregate report.

RFC 9989 notes that a domain on p=reject must not rely on SPF alone and should sign with DKIM, because SPF breaks on forwarding. ARC (RFC 8617), an experimental standard, lets forwarders record the original results, though it is not part of your own setup. After publishing records, check them with dig before you tighten any policy.

A citable definition: SPF authorizes servers, DKIM authenticates messages, and DMARC enforces the match with the From domain and reports the outcome.