Deliverability · Authentication

Email Authentication Explained: SPF, DKIM, and DMARC

Email was designed in an era of implicit trust, with no built-in way to verify that a message claiming to come from your domain actually did. Authentication is the layer that fixes that, and in 2026 it’s no longer optional — it’s the precondition for reaching the inbox at all. This guide explains what each protocol does, how they fit together, and the important truth about what authentication can and can’t tell you.

What is email authentication and why does it exist?

Authentication exists because the protocol that carries email, SMTP, has no native mechanism to confirm a sender’s identity — anyone can put your domain in the From field, which is exactly what phishing and spoofing exploit. Email authentication is a set of standards, published as DNS records, that let a receiving server cryptographically bind a message to a sending domain and so detect when a message is forged. When you authenticate, you’re publishing public proof of which servers and signatures are legitimately yours, and receivers check that proof before deciding where your mail lands. The flow below shows the three checks a message passes through.

SPF: authorizing your senders

SPF, the Sender Policy Framework, is the most straightforward of the three: it’s a DNS TXT record that lists the servers and IP addresses authorised to send mail for your domain. When a message arrives, the receiving server looks at the sending IP and checks it against your SPF record — if the IP is listed, SPF passes. It’s a simple authorisation list with no encryption involved, validating the envelope sender (the return-path) rather than the address recipients see.

SPF has two well-known limitations that shape how it’s used. First, it breaks on forwarding: when a message is relayed through an intermediate server, that server’s IP isn’t in your record, so SPF fails for legitimately forwarded mail. Second, the record is capped at ten DNS lookups, and routing through enough third-party services breaches that limit and causes SPF to fail entirely — which is why consolidating includes matters and why you should never use a permissive +all that authorises everyone. SPF on its own can’t stop spoofing of the visible From address, which is precisely the gap the other two protocols close.

DKIM: signing your messages

DKIM, DomainKeys Identified Mail, adds a cryptographic signature to every message — think of it as a tamper-evident watermark unique to your domain. Your mail server signs outgoing messages with a private key, and the matching public key is published in DNS, so the receiver can verify the signature and confirm two things: that the message genuinely came from your domain, and that it wasn’t altered in transit. Crucially, and unlike SPF, a DKIM signature survives forwarding, because it travels with the message rather than depending on the connecting IP.

A few technical details are worth knowing. The signature’s d= tag names the signing domain and is what DMARC aligns against; the h= tag lists the signed headers, which should always include From, Subject, Date, and Message-ID; and a body-hash tag lets receivers detect any tampering with the content. The modern baseline is a 2048-bit RSA key — older 1024-bit keys still work but are increasingly flagged — and good practice is to rotate keys at least every six months using a dual-selector pattern: publish a new key at a new selector, move signing over once DNS propagates, then retire the old one. DKIM’s main weakness is that modifications to the message body, as mailing lists often make, break the signature.

DMARC: tying it together

DMARC, Domain-based Message Authentication, Reporting and Conformance, is the policy layer that turns SPF and DKIM into actual protection. It does three jobs: it checks that at least one of SPF or DKIM passed and aligns with your visible From domain, it tells receivers what to do with messages that fail — deliver, quarantine, or reject — and it sends you reports showing who’s sending as your domain. Without DMARC, a spoofed message could slip through by passing SPF with a different return-path or by simply not being DKIM-signed; DMARC closes those gaps by demanding alignment with the address recipients actually see. The table compares the three.

The division of labour is clean: SPF and DKIM are the authentication mechanisms that establish what’s legitimate, and DMARC is the policy mechanism that ties them to your brand-visible identity and decides the outcome. A useful way to remember it is that SPF and DKIM answer “is this real?” while DMARC answers “does it match the From address, and what should I do if it doesn’t?”

How do the three work together?

In practice they run as a sequence on every inbound message. The receiver performs the SPF check, comparing the sending IP to your record; it performs the DKIM check, verifying the signature against your published public key; and then it performs the DMARC evaluation, confirming that at least one of those passed and that the passing domain aligns with the From header. If alignment holds, the message is delivered normally; if not, the receiver applies your DMARC policy. The records that drive all this are just DNS entries — the terminal shows a representative set.

# SPF — authorize your senders (one record, under 10 lookups)
example.com.  TXT  “v=spf1 include:_spf.yoursender.com -all”
 
# DKIM — publish the public key at a selector
sel1._domainkey.example.com.  TXT  “v=DKIM1; k=rsa; p=MIGfMA0…QAB”
 
# DMARC — alignment, policy, and reporting
_dmarc.example.com.  TXT  “v=DMARC1; p=reject; rua=mailto:dmarc@example.com”
# Together: SPF or DKIM must pass AND align with the From domain.

What makes the system resilient is the redundancy between SPF and DKIM. Because DMARC passes if either one passes and aligns, a forwarded message that fails SPF can still pass on DKIM, and a message that somehow loses its signature can still pass on SPF — so the two mechanisms cover each other’s weaknesses. This is also why publishing all three matters rather than picking one: each protocol alone leaves a gap, and only the combination, bound together by DMARC alignment, actually closes them.

What is alignment, and why does it matter?

Alignment is the concept that trips up most implementations, and it’s the entire reason DMARC adds protection that SPF and DKIM can’t provide alone. Alignment means the domain that SPF or DKIM authenticated must match the domain in the visible From header. SPF authenticates the envelope return-path, and DKIM authenticates the domain in its d= tag — but neither of those is necessarily the address recipients see. DMARC requires that the authenticated domain line up with the From domain, which is what defeats the classic attack where a message passes SPF using a sender’s own return-path while displaying your domain in the From field.

There are two alignment modes. Relaxed alignment, the common default, allows subdomains of your organisational domain to match — so mail.example.com aligns with example.com — while strict alignment demands an exact match, suiting high-security domains. The key takeaway is counterintuitive but important: a message can pass SPF and pass DKIM and still fail DMARC, purely because the authenticated domain doesn’t align with the From address. That’s not a bug; it’s the precise mechanism that makes spoofing detectable, and it’s the most common reason legitimate mail from third-party platforms fails authentication.

The supporting protocols: BIMI, MTA-STS, and ARC

Beyond the core three, a handful of protocols extend the authentication stack, and they’re worth knowing even if not every sender needs them. ARC, the Authenticated Received Chain, addresses the forwarding problem directly: it preserves the original authentication results as a message passes through intermediaries like mailing lists, so DMARC doesn’t break when a legitimate forwarder relays your mail. It’s a genuine fix for a real weakness, though adoption is still limited. MTA-STS enforces encrypted transport by preventing downgrade attacks that strip TLS, closing a confidentiality gap — though in practice very few domains have deployed it and a substantial share of those are misconfigured.

BIMI, Brand Indicators for Message Identification, is the visible payoff of the stack: it displays your verified brand logo next to your messages in supporting inboxes. It requires DMARC at enforcement (quarantine or reject), and for the strongest version, a registered trademark and a Verified Mark Certificate that carries an annual cost. None of these supporting protocols substitute for SPF, DKIM, and DMARC — they build on top of them — but they round out a mature program, with BIMI offering brand visibility, MTA-STS adding transport security, and ARC repairing the forwarding edge case.

Why authentication is now mandatory

What changed in 2024 is that authentication moved from best practice to requirement. Gmail and Yahoo began requiring SPF, DKIM, and DMARC for bulk senders that year, Microsoft followed in 2025, and by 2026 the expectation has cascaded down to every sender regardless of volume — providers now silently junk or reject unaligned mail even from small domains. Receiving servers treat authentication as a primary spam-filtering signal, evaluated before content is even considered, so failing SPF or DKIM pushes mail toward spam before a filter looks at a single word. The scale of impact is real: one provider reported hundreds of billions fewer unauthenticated messages after enforcement began.

The implication is that authentication is now the entry ticket, not a nice-to-have. Sending without it means your mail may be rejected or filtered regardless of how good the content is, and authentication failures are logged in your sending history, contributing to reputation decay over time. The encouraging flip side is that missing or misconfigured authentication is both the most common root cause of deliverability problems and one of the easiest to fix — and the staged process of getting from a published record to full enforcement is the subject of our DMARC enforcement rollout guide.

Does authentication mean your mail is trusted?

Here’s the most important thing to understand, and it’s the one most often misunderstood: authentication proves identity, not trustworthiness. SPF, DKIM, and DMARC confirm who sent a message — that it genuinely came from the domain it claims — but they say nothing about whether the message is good. A spammer can fully authenticate their own domain, passing all three protocols perfectly, because authentication answers “who” rather than “whether this is worth delivering.” Passing authentication is the floor, not the ceiling.

That’s why authentication is necessary but not sufficient. It gets you eligible to compete for the inbox, but once your identity is confirmed, engagement and reputation decide where your mail actually lands — perfect authentication won’t rescue a poorly engaged list or bad sending practices. Authentication also isn’t set-and-forget: new sending services, key rotation, and alignment drift all need ongoing attention, and a DMARC record stuck at monitoring provides no protection at all. For senders who want full control over their authentication — setting SPF, DKIM, and DMARC directly, managing alignment, and rotating keys on their own schedule — our PowerMTA server hosting puts the entire stack in your hands, while the engagement and reputation work that authentication merely enables does the rest.