SPF vs DKIM vs DMARC: What's the Difference?
SPF, DKIM and DMARC are three separate email authentication protocols that work together to prove an email genuinely came from your domain. Each one solves a different part of the problem. This guide explains what each protocol does, how they relate to one another, and what you need to set up for full protection.
The short version
- SPF checks which servers are allowed to send email for your domain.
- DKIM adds a cryptographic signature to each email so the recipient can verify it was not altered in transit.
- DMARC ties SPF and DKIM together and tells receiving mail servers what to do when an email fails both checks.
You need all three. SPF and DKIM handle authentication. DMARC handles enforcement and reporting.
What is SPF?
SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and hostnames allowed to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from [email protected], it looks up the SPF record for example.com and checks whether the sending server's IP address is on the list.
How an SPF record looks
This record says: allow Google Workspace servers, Microsoft 365 servers, and the IP 203.0.113.10 to send email. Reject everything else (-all).
What SPF does well
- Simple to set up for straightforward email configurations
- Blocks direct IP spoofing from unlisted servers
- Widely supported by all major email providers
Where SPF falls short
- Breaks when forwarded.If someone forwards your email, the forwarding server's IP is not in your SPF record, so the check fails.
- 10-lookup limit. SPF records are limited to 10 DNS lookups. Organisations with many SaaS tools regularly exceed this, causing a PermError that breaks authentication entirely. See our guide on how to fix SPF too many DNS lookups.
- No content integrity. SPF only checks the sending server. It does not verify whether the email body or headers were changed after sending.
What is DKIM?
DKIM (DomainKeys Identified Mail) adds a digital signature to the headers of every outgoing email. The sending mail server signs the message using a private key. The recipient looks up the corresponding public key in your DNS and uses it to verify that the signature is valid and the message was not altered in transit.
How DKIM works step by step
- You generate a public/private key pair and publish the public key as a DNS TXT record under a selector, for example
s1._domainkey.example.com. - When your mail server sends an email, it hashes specified headers and the body, then signs the hash with the private key. The signature is added as a
DKIM-Signatureheader. - The receiving server extracts the selector and domain from the signature header, fetches the public key from DNS, and verifies the signature.
- If the signature is valid, the email passes DKIM. If the content was altered or the key does not match, it fails.
How a DKIM DNS record looks
What DKIM does well
- Proves the email has not been tampered with since it was signed
- Survives email forwarding (the signature travels with the message)
- Lets you delegate signing to third-party services without giving them your domain password
Where DKIM falls short
- More complex to set up. You need to generate keys, configure your mail server or email provider, and publish DNS records for each selector.
- Does not say what to do on failure.DKIM by itself only says “this email is valid” or “this email failed verification”. It does not tell the receiving server whether to deliver, quarantine or reject a failed message.
- Can break if mailing lists modify headers or body. Some mailing list software adds footers or rewrites subject lines, which invalidates the DKIM signature.
What is DMARC?
DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It does two things that neither SPF nor DKIM can do alone:
- Alignment.DMARC checks that the domain in the visible “From” header matches the domain that passed SPF or DKIM. This prevents attackers from passing SPF with their own domain while spoofing yours in the From header.
- Policy enforcement. DMARC tells receiving servers what to do when an email fails authentication: deliver it anyway (
p=none), send it to spam (p=quarantine), or reject it outright (p=reject). - Reporting. DMARC tells receiving servers to send aggregate reports (RUA) back to the domain owner, giving you visibility into who is sending email as your domain and whether it is passing or failing authentication.
How a DMARC record looks
For a detailed breakdown of every tag, see our What is DMARC guide, or use our DMARC Generator to build one for your domain.
How SPF, DKIM and DMARC Work Together
Think of email authentication as a three-layer system. Each layer addresses a different question:
| Question | Protocol | How |
|---|---|---|
| Was this sent from an authorised server? | SPF | Checks the sending IP against the DNS allow-list |
| Was the message altered in transit? | DKIM | Verifies a cryptographic signature on the message headers |
| Does the visible From domain match, and what do we do if it fails? | DMARC | Checks alignment and enforces policy (none, quarantine, reject) |
The authentication flow
When a receiving mail server gets an email claiming to be from your domain, this is roughly what happens:
- The server checks SPF: is the sending IP in the SPF record for the envelope sender domain?
- The server checks DKIM: does the message have a valid DKIM signature, and does the signing domain match?
- The server checks DMARC: does the domain in the visible From header align with either the SPF-authenticated domain or the DKIM-signing domain?
- If alignment passes for either SPF or DKIM, the email passes DMARC. If both fail alignment, the receiving server applies the DMARC policy (none, quarantine or reject).
- The receiving server sends an aggregate report (RUA) back to the address in your DMARC record so you can see what happened.
Why you need both SPF and DKIM
SPF fails when email is forwarded. DKIM fails when mailing lists modify content. By having both, you give DMARC two chances to find a passing, aligned result. If one breaks, the other can still save the email.
SPF vs DKIM vs DMARC: Quick Comparison
| Feature | SPF | DKIM | DMARC |
|---|---|---|---|
| DNS record type | TXT on root domain | TXT on selector._domainkey | TXT on _dmarc |
| What it checks | Sending server IP | Message signature | SPF/DKIM alignment with From header |
| Survives forwarding? | No | Usually yes | Yes (if DKIM passes) |
| Detects content changes? | No | Yes | Via DKIM |
| Provides enforcement? | Partial (-all hint) | No | Yes (none/quarantine/reject) |
| Sends reports? | No | No | Yes (RUA aggregate, RUF forensic) |
| Setup complexity | Low | Medium | Low (record), Medium (monitoring) |
Common Misconceptions
“SPF alone is enough”
SPF only checks the envelope sender, not the visible From header. An attacker can pass SPF using their own domain while displaying your domain in the From field. Without DMARC alignment checking, the recipient sees your domain and trusts the email.
“DKIM prevents spoofing”
DKIM proves a message was signed by a specific domain, but it does not prevent anyone from signing emails with their own domain. An attacker can set up DKIM for evil.com and send phishing emails that show your domain in the From header. Only DMARC alignment stops this, because it requires the signing domain to match the From domain.
“DMARC p=none protects us”
A p=none policy tells receiving servers to take no action on failing emails. It is a monitoring-only mode, useful for gathering data before enforcement, but it does not block any spoofed emails. You need to move to p=quarantine or p=reject for actual protection.
“We only need this on our primary domain”
Attackers target all domains associated with your brand. If you operate from example.com but also own example.co.uk, both need SPF, DKIM and DMARC. Our UK MSP DMARC Audit: Q1 2026 found that 80% of 192 UK MSPs had an unprotected alternate domain.
How to Set Up SPF, DKIM and DMARC
Step 1: Publish an SPF record
Create a DNS TXT record on your root domain listing every service that sends email on your behalf. For active sending domains, end with ~all (soft fail). This lets DMARC evaluate both SPF and DKIM before making a decision, which is important because -all (hard fail) can cause legitimate forwarded mail to be rejected at the SPF layer before DKIM is considered. For parked or non-sending domains, use -all since no legitimate mail exists. Use our SPF Flattener to check you are within the 10-lookup limit.
Step 2: Configure DKIM signing
Most email providers (Google Workspace, Microsoft 365, Postmark, Mailchimp) provide DKIM keys that you publish in DNS. If you run your own mail server, generate a 2048-bit RSA key pair using your MTA's DKIM module. Publish the public key as a TXT record at selector._domainkey.yourdomain.com.
Step 3: Publish a DMARC record
Add a TXT record at _dmarc.yourdomain.com. Start with monitoring mode to see who is sending email as your domain:
Step 4: Monitor and fix senders
Collect aggregate reports for two to four weeks. Identify any legitimate senders that are failing SPF or DKIM (often forgotten SaaS tools or marketing platforms). Fix their DNS records or add their includes to SPF.
Step 5: Move to enforcement
Once all legitimate senders are passing, move to p=quarantine and then p=reject. For active sending domains, use relaxed alignment (adkim=r; aspf=r) to avoid breaking third-party senders that use subdomain Return-Paths and DKIM signing domains. Always set a subdomain policy (sp=reject) to protect unused subdomains from spoofing and to mitigate the subdomain bypass risk that relaxed alignment introduces. Avoid adding a ruf= tag: forensic reports can expose full message headers and content, creating GDPR risk, and most receivers ignore the request anyway.
What About Domains That Do Not Send Email?
Parked domains, alias domains and defensive registrations should be locked down with restrictive records to prevent spoofing:
SPF: v=spf1 -all
DMARC: v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s
No DKIM record is needed because no server should be signing email for these domains. For more on securing parked domains, see our guide on how to redirect parked and alias domains.
Check Your Domain Now
Use our free tools to see how your SPF, DKIM and DMARC are configured right now:
Need Ongoing Monitoring?
A point-in-time check tells you where you stand today. For continuous monitoring with DMARC aggregate report parsing, sender visibility, alignment tracking, and alerts when records change, sign up for ShieldMarc. Start free and upgrade when you need more.