Email Authentication Explained: SPF, DKIM, and DMARC

SPF, DKIM, and DMARC are three standards that together prove an email actually came from your domain and decide what happens when one does not. They exist because plain email has no built-in way to verify the sender, which is exactly what spammers and phishers exploit. Publish all three correctly and you make your domain far harder to spoof while improving the odds your real mail reaches the inbox.

All three are published as DNS TXT records, so they sit right alongside the rest of your DNS records. A DNS lookup is all it takes to see whether a domain has them. You can check any domain's SPF and DMARC status with our DNS tool.

What each one does

Standard	Job	Lives in	Defined by
SPF	Lists which servers may send mail for your domain	TXT record	RFC 7208
DKIM	Adds a tamper-proof cryptographic signature to each message	TXT record (selector)	RFC 6376
DMARC	Sets the policy for failures and requests reports	TXT record (_dmarc)	RFC 7489

SPF: who is allowed to send

An SPF record names the mail servers permitted to send on behalf of your domain. A receiver checks the sending server against that list. Full detail in SPF records explained.

DKIM: a signature that proves nothing changed

DKIM attaches a digital signature to each message using a private key, and publishes the matching public key in DNS. Receivers verify the signature to confirm the message is genuine and unaltered. See DKIM explained.

DMARC: the policy and the reports

DMARC ties SPF and DKIM to your visible From address and tells receivers what to do with failures: monitor, quarantine, or reject. It also sends you reports showing who is mailing as your domain. See DMARC explained and the breakdown of DMARC policies.

Alignment: the part everyone misses

Here is the single most common source of confusion. A message can pass SPF and still fail DMARC. That is not a bug, it is the entire point of DMARC.

SPF checks the envelope sender (the MAIL FROM address, also called the Return-Path), which recipients never see. DKIM checks the domain in the signature. DMARC checks something different: whether either of those domains matches the From: address the user actually reads. That match is called alignment, and without it a spammer could pass SPF for their own throwaway domain while displaying your brand in the From line.

So DMARC passes only when at least one of the following is true:

• SPF passes and the Return-Path domain aligns with the From domain, or
• DKIM passes and the signing domain aligns with the From domain.

One is enough. This is why DKIM matters more than its reputation suggests: DKIM alignment survives forwarding, and SPF alignment often does not.

Alignment has two modes. Relaxed (the default) accepts a match on the organisational domain, so mail.example.com aligns with example.com. Strict, set with aspf=s or adkim=s in your DMARC record, demands an exact match. Start relaxed. Strict mode breaks a surprising number of legitimate setups, especially SaaS platforms that send from their own subdomains on your behalf.

Where it usually goes wrong

Four failure modes account for most broken setups.

The SPF ten-lookup limit. An SPF record may trigger at most 10 DNS lookups while being evaluated, a hard cap set by RFC 7208 (section 4.6.4). Every include:, a, mx, ptr, and redirect counts, and each vendor's include can nest more inside it. Exceed 10 and the result is permerror, which most receivers treat as a failure. Adding one more marketing tool is the classic way a working setup silently breaks. Also note that +all or a missing all mechanism defeats the purpose entirely: end with ~all (softfail) or -all (hardfail).

Forwarding. When a mailing list or a forwarding address relays your message, the sending server changes but the From address does not, so SPF breaks by design. DKIM survives, because the signature travels with the message, which is exactly why DKIM alignment is the more durable of the two paths. Where forwarding is unavoidable, ARC lets an intermediary vouch for the original authentication result, though receivers are free to decide how much to trust it.

Third-party senders. Your invoicing tool, help desk, CRM, and marketing platform all send as you. Each needs to be authorised in SPF and, ideally, given its own DKIM key. Missing one means a whole category of your mail fails while everything else looks fine.

Weak or stale DKIM keys. Use 2048-bit keys where your DNS provider supports them; 1024 is the practical floor. Rotate them periodically, and remember that a key removed from DNS invalidates signatures on mail still in transit.

Domains that do not send mail at all. Parked domains and lookalike registrations are prime spoofing targets precisely because nobody configures them. Publish v=spf1 -all, a DMARC record with p=reject, and a null MX record per RFC 7505. It takes minutes and closes the easiest attack path against your brand.

Rolling out DMARC without breaking your mail

Going straight to p=reject will silently destroy legitimate mail you did not know you were sending. The staged path exists for a reason.

1. Publish p=none with reporting. This changes nothing about delivery and starts the aggregate reports flowing to the address in your rua= tag. You are buying visibility, not enforcement.
2. Read the reports for two to four weeks. They show every source sending as your domain and whether each one aligns. Almost everyone finds a forgotten sender here.
3. Fix what you find. Authorise the legitimate senders in SPF, add DKIM signing where you can, and identify anything genuinely unauthorised.
4. Move to p=quarantine, optionally with pct= to apply it to a fraction of mail first. Failures now go to spam rather than the inbox, which is recoverable.
5. Move to p=reject once reports show clean alignment. Failures are now refused outright.

Set a subdomain policy too. The sp= tag governs subdomains independently, and since attackers frequently spoof subdomains you never use, sp=reject is often appropriate well before the parent domain is ready for it.

Why all three, and why now

Each standard covers a gap the others leave open, which is why they are designed to work as a set. SPF alone breaks when mail is forwarded; DKIM alone does not say what to do on failure; DMARC ties them to the address users actually see and adds enforcement and reporting. We walk through the interplay in SPF vs DKIM vs DMARC.

Since 2024, the large mailbox providers require authentication for bulk senders, so this is no longer optional if you send marketing or transactional mail. Missing or broken authentication is one of the most common reasons legitimate mail lands in spam, covered in why your email goes to spam.

How to check a domain

You do not need to read raw DNS to audit a domain's email security. Our DNS tool reports whether SPF and DMARC are present, and our guide how to check SPF, DKIM, and DMARC shows how to verify all three by hand. Once DMARC is enforcing, you can even add a brand logo to your messages with BIMI.

Checking the domain tells you what policy is published. To see how a specific message fared, read its headers: every server that touched it leaves a trace, and the receiving server records the SPF, DKIM, and DMARC verdicts it reached. How to read email headers walks through the Received chain and the Authentication-Results line, and our email header analyzer parses a pasted header block for you. That is the fastest way to answer "why did this message fail" rather than "is the domain configured."

Get these three right and you have closed the easiest door an attacker can use against your brand, and given your real mail its best shot at the inbox. Check any domain with our DNS tool, or have an agent pull the records through the dns_records tool in our MCP server.