Email authentication has three separate layers -- SPF, DKIM, and DMARC -- and they are commonly described as if any one of them is sufficient on its own. They are not. Each one closes a specific gap that the others leave open. Understanding exactly what each layer does, and does not do, explains why all three need to be in place before your domain is meaningfully protected against email spoofing and deliverability problems.
Photo by Walls.io on Pexels
What SPF Does and What It Misses
SPF (Sender Policy Framework) is a DNS TXT record that lists which IP addresses and services are authorized to send email for your domain. When a receiving mail server gets a message claiming to be from you@example.com, it looks up the SPF record for example.com and checks whether the sending server's IP is in the list. If it is, SPF passes.
The first gap SPF leaves: it only validates the server IP against the envelope From address -- the technical sender used during SMTP negotiation -- not the header From address that appears in your email client. An attacker can send a message with From: legitimate@yourdomain.com visible in the recipient's inbox while using a completely different technical sender that passes SPF. This is a display-name spoof, and SPF is not designed to stop it.
The second gap is forwarding. When email is forwarded, the forwarder re-sends the message from its own IP, which is almost certainly not in your SPF record. SPF fails for legitimately forwarded email. This matters because DMARC's enforcement depends on which authentication checks pass.
One important operational constraint: SPF allows a maximum of ten DNS lookups during evaluation. Every include:, a:, mx:, and redirect: directive adds to that count. Many domains exceed this limit as they add new email services over time, causing a permerror that some receiving servers treat as an outright failure. The SPF specification is in RFC 7208.
What DKIM Does and What It Misses
DKIM (DomainKeys Identified Mail) signs outgoing messages with a private key held by your sending service. The corresponding public key is published as a DNS TXT record at a subdomain like mail._domainkey.example.com. When a receiving server gets the message, it fetches your public key and verifies the signature. A valid signature proves two things: the message body was not altered in transit, and the signature came from a sender with access to your private key.
DKIM survives email forwarding because the signature is tied to the message content, not the sending server's IP. A forwarder passes the message along with the original DKIM signature intact, and the receiving server can still verify it. This is the key advantage DKIM has over SPF in forwarded-email scenarios.
The gap DKIM leaves: it says nothing about the From: address visible to the recipient. A phishing email can carry a perfectly valid DKIM signature for the attacker's own domain (malicious.com) while displaying a spoofed From: header that looks like it came from your domain. The signature proves the attacker's domain signed it -- which is true -- but it tells the recipient nothing about who the apparent sender is. DKIM proves message integrity and signing authority, not that the visible sender is who they claim to be.
The DKIM specification is in RFC 6376.
What DMARC Does and Why It Requires Both
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the mechanism that ties SPF and DKIM together and adds enforcement. A DMARC record at _dmarc.example.com does three things:
- Defines a policy for what to do with messages that fail authentication:
p=none(report only),p=quarantine(send to spam), orp=reject(block outright). - Enforces alignment -- the domain in the
From:header must match the domain used in the SPF check or the DKIM signature. - Provides a reporting mechanism -- participating mail servers send aggregate and forensic reports to the address you specify in
rua=.
Alignment is the critical concept that closes the gaps SPF and DKIM leave individually. DMARC requires that the From: domain -- the one visible to the recipient -- is aligned with either the SPF-validated envelope sender or the DKIM-signing domain. This is what prevents display-name spoofing. Even if an attacker constructs a message that passes SPF under their own domain, DMARC will fail because that domain does not match your From: address.
The reporting mechanism is underused. The aggregate reports tell you which services are sending email as your domain, which ones are passing authentication, and which are failing. This gives you visibility into shadow sending you might not even know about -- a forgotten newsletter service or a misconfigured third-party tool. DMARC.org has reference material on interpreting the reports.
The DMARC specification is in RFC 7489.
Why You Need All Three: The Combinations
Here is what each partial configuration actually gets you:
SPF only: You block random IPs from claiming to be your domain under the envelope address. But display-name spoofing still works, and DMARC has nothing to enforce without a policy record.
DKIM only: You can sign messages and prove they are not altered in transit. But you have not told anyone what to do with messages that fail signing, and DMARC still has nothing to work from.
DMARC only: No useful effect. DMARC needs at least one of SPF or DKIM to be passing in alignment before it can make an enforcement decision. A DMARC policy without underlying authentication is a record that never triggers.
SPF + DKIM: Two authentication mechanisms are in place. But without DMARC, receiving servers have no instruction on what to do when they fail. Messages that fail both SPF and DKIM alignment are delivered as if no authentication was present.
SPF + DKIM + DMARC: This is the complete picture. DMARC aligns both mechanisms to the visible From: domain, gives receiving servers actionable policy instructions, prevents display-name spoofing, and gives you reporting to monitor what is happening to your domain's email traffic.
Setting Up a Minimal Secure Configuration
For a domain sending from a single provider (Google Workspace, for example), a minimal working set looks like this:
SPF (TXT record at root domain):
v=spf1 include:_spf.google.com ~all
DKIM: Generated and published by your mail provider -- they give you the subdomain and TXT value to add. Nothing to write yourself beyond adding their record.
DMARC (TXT record at _dmarc.yourdomain.com):
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100
Start with p=quarantine rather than p=reject. It protects your domain while giving you time to review aggregate reports and confirm that all legitimate sending services pass authentication before moving to the stricter policy.
Checking Your Current Configuration
The fastest way to check whether SPF, DKIM, and DMARC are all in place is to query all TXT records for your domain and _dmarc.yourdomain.com at once. The DNS Lookup tool from EvvyTools retrieves all record types and flags email health issues alongside the raw record values, so you can confirm all three layers are present without running separate queries.
For a broader walkthrough of every DNS record type and what each value means, see DNS Records Explained: A Practical Guide to Reading and Debugging Your Domain's DNS.
Top comments (0)