22 June 2026 · 5 min read
SPF, DKIM and DMARC answer different questions. SPF checks whether the sending server is allowed to send for the domain in the envelope sender. DKIM checks whether the message was signed by the domain in its signature and arrived unaltered. DMARC checks whether either of those passed for the domain in the visible From address, tells receivers what to do if not, and sends you reports. You need all three: SPF and DKIM provide the evidence, and DMARC decides whether that evidence is about your domain.
Side by side
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Standard | RFC 7208 | RFC 6376 | RFC 9989 |
| Published at | TXT at the envelope sender domain | TXT or CNAME at <selector>._domainkey | TXT at _dmarc |
| Checks | The connecting IP address | A cryptographic signature over headers and body | Whether SPF or DKIM passed and aligned |
| Domain it checks | Envelope sender (Return-Path) | The d= signing domain | The visible From domain |
| Survives forwarding | Usually not | Usually, if the message is not modified | Yes, if DKIM still aligns |
| Tells receivers what to do | Only loosely, through -all or ~all | No | Yes: p=none, quarantine or reject |
| Sends you reports | No | No | Yes, aggregate reports to rua |
SPF: is this server allowed to send?
An SPF record lists the servers allowed to send mail for a domain:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.0/24 -allThe receiver takes the connecting IP address, looks up the SPF record of the domain in the envelope sender (the MAIL FROM, also called the Return-Path), and checks whether the IP is listed.
What SPF does not do:
- It never looks at the From header. An attacker can pass SPF for their own domain in the envelope while putting your domain in the visible From.
- It breaks on forwarding. The forwarding server's IP is not in your record.
- It has a ten-lookup limit. More than ten DNS lookups returns a permanent error. Fixing too many SPF DNS lookups covers the cure.
Check a record with the SPF checker.
DKIM: was this message signed, and is it intact?
DKIM signs selected headers and the body with a private key and adds the signature in a header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1;
h=from:to:subject:date:message-id; bh=...; b=...The receiver fetches the public key from selector1._domainkey.example.com and verifies the signature. The bh= value is a hash of the body, so a changed body fails verification. Because the signature travels with the message, it usually survives forwarding.
What DKIM does not do:
- It does not tie
d=to the From header. A platform can sign with its own domain while the From address is yours, and an attacker can sign their own message with their own domain. Both pass DKIM. - It breaks if the message is modified. Mailing lists that add footers or gateways that rewrite links invalidate the signature.
Check a selector with the DKIM checker.
DMARC: does the evidence match the From address?
DMARC has no check of its own. It takes the SPF and DKIM results and adds alignment: a message passes DMARC only if SPF or DKIM passes and the domain it passed for matches the domain in the visible From address.
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com- SPF alignment compares the envelope sender domain with the From domain.
- DKIM alignment compares the
d=domain with the From domain. - Relaxed alignment, the default, only needs the same organisational domain, so
mail.example.comaligns withexample.com. Strict alignment (aspf=s,adkim=s) needs an exact match.
This is what stops an attacker. Their SPF pass is for their own envelope domain and their DKIM signature is for their own d=, so neither aligns with your From domain and DMARC fails.
The p= tag then tells receivers what to do with failing mail: none (monitor only), quarantine (treat as suspicious, usually the spam folder) or reject (refuse it). The rua= tag asks receivers to send you aggregate reports showing every source that sent mail as your domain and whether it aligned. Neither SPF nor DKIM gives you that visibility. The DMARC report analyser turns the reports into a per-source view.
One aligned pass is enough
DMARC passes if at least one mechanism passes with alignment. That has two practical consequences:
- Forwarding. A forwarded message usually fails SPF but keeps a valid DKIM signature, so it still passes DMARC on DKIM.
- Third-party senders. Getting SPF to align through a sending platform needs a custom Return-Path on your domain, which not every platform supports. Getting DKIM to align usually just means completing the platform's domain authentication so it signs with
d=example.com.
So DKIM alignment is the one to rely on, and SPF alignment is a useful extra. When both pass but DMARC still fails, the cause is alignment: why DMARC fails when SPF and DKIM pass shows how to find it.
Setting up all three, in order
- SPF and DKIM for every legitimate sender: your mailbox provider, marketing platform, CRM, help desk and anything else that sends as your domain.
- DMARC at
p=nonewith aruaaddress, to start receiving reports. - Fix alignment for each source the reports show failing.
- Move the policy to
p=quarantine, thenp=reject, once your own mail passes. p=none vs quarantine vs reject explains each step.
Run the DMARC checker to see what your domain publishes today. If you would rather have the rollout and the report reading done for you, hosted DMARC stages the policy from p=none to p=reject.