SPF verifies which servers can send email for your domain. DKIM proves the email was not altered in transit. DMARC ties both together and tells receiving servers what to do when authentication fails. All three are now required by Google, Yahoo, Microsoft, and Apple for bulk senders (Cloudflare, 2024; Google Workspace Admin Help, 2024; Microsoft Tech Community, April 2025).
That is the 40-word version. The rest of this post covers how each protocol actually works, why you need all three (not just one or two), what breaks when they are misconfigured, and how to check your setup in under five minutes.
Key Takeaway
- SPF checks WHERE the email came from (is the sending server authorized?)
- DKIM checks WHAT the email says (was the message tampered with?)
- DMARC checks WHO sent it (does the From: address match?) and sets the policy
- All four major providers (Google, Yahoo, Microsoft, Apple) now require all three for bulk senders
- Check your domain right now: SPF Checker | DKIM Checker | DMARC Analyzer
Why email authentication exists
Email was designed in the 1970s with zero built-in identity verification. The SMTP protocol lets anyone claim to be anyone. You can send an email with a From: address of [email protected] from any server in the world, and the protocol itself will not stop you.
Attackers figured this out decades ago. Today, 3.4 billion phishing emails are sent globally every day (StationX, 2025). The FBI's 2024 Internet Crime Report logged 193,407 phishing complaints and $2.77 billion in business email compromise (BEC) losses in the United States alone (FBI IC3, 2025). By early 2026, 82.6% of phishing emails showed signs of AI assistance, up from just 4% in November 2025 (Deepstrike, 2026).
SPF, DKIM, and DMARC were built to close this gap. They are not spam filters. They are identity verification protocols that let receiving servers answer one question: "Did this email actually come from who it claims to come from?"
SPF: who is allowed to send email for your domain
SPF (Sender Policy Framework)
RFC 7208 · DNS TXT record · Checks the sending server's IP addressSPF lets you publish a list of IP addresses and servers authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from your domain, it performs a DNS lookup, retrieves your SPF record, and checks whether the sending server's IP appears in that authorized list. Match = pass. No match = fail.
An SPF record lives in your domain's DNS as a TXT record. It looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net -all
This record says: "Google's mail servers and SendGrid's servers are authorized to send email for this domain. Reject everything else." The -all at the end is a hard fail, meaning any server not in the list should be treated as unauthorized.
What SPF does well: It prevents unauthorized servers from sending email using your domain's envelope address (the Return-Path). If someone spins up a random server and tries to send as your domain, SPF catches it.
What SPF cannot do: SPF checks the envelope sender (Return-Path), not the From: header that recipients actually see in their inbox. An attacker can set the Return-Path to their own domain (passing SPF) while putting your domain in the visible From: field. Without DMARC, this spoofing works. SPF also breaks when emails are forwarded, because the forwarding server's IP is not in your SPF record.
The 10-lookup limit. SPF allows a maximum of 10 DNS lookups per evaluation (RFC 7208, Section 4.6.4). Every include:, a:, mx:, and redirect: in your record counts as a lookup. Exceed 10, and SPF returns a PermError, which means every email fails SPF. This is one of the most common configuration issues, especially for organizations using many third-party services. Check your lookup count with our free SPF Record Checker.
Common Mistake
Having two SPF TXT records for the same domain invalidates SPF entirely. This happens when a new email service tells you to "add" an SPF record rather than modify your existing one. You must combine all authorized sources into a single SPF record.
DKIM: proving the email was not altered in transit
DKIM (DomainKeys Identified Mail)
RFC 6376 · Cryptographic signature · Verifies message integrityDKIM uses public-key cryptography to sign outgoing emails. The sending server generates a hash of selected email headers and the message body, encrypts that hash with a private key, and attaches it as a DKIM-Signature header. The receiving server looks up the public key via DNS, decrypts the signature, independently hashes the same content, and compares. If the hashes match, the email has not been tampered with since it was signed.
DKIM involves two pieces: a private key (stored on your sending server, never shared) and a public key (published in DNS so anyone can verify signatures). The public key record looks like this:
selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."
The "selector" is a label your email provider assigns (like google or s1) so you can have multiple DKIM keys for different services without conflicts.
What DKIM does well: It guarantees message integrity. If anyone modifies the email headers or body after the sending server signs it, the DKIM check fails. This catches man-in-the-middle tampering and some forms of email interception. Unlike SPF, DKIM survives email forwarding in most cases because the signature travels with the message.
What DKIM cannot do: DKIM alone does not tell the receiving server what to do when verification fails. A failed DKIM check is just information; without DMARC, the receiving server has no policy instruction and may deliver the email anyway.
Key length matters. DKIM keys come in 1024-bit and 2048-bit lengths. Yahoo explicitly requires a minimum of 1024-bit for bulk senders. NIST recommends 2048-bit. If you are still on 512-bit keys (common in older configurations), Yahoo will reject your email even if everything else passes. Verify your key strength with our DKIM Record Checker.
DMARC: the policy layer that ties everything together
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
RFC 7489 · DNS TXT record · Policy + alignment + reportingDMARC builds on SPF and DKIM by adding two things: alignment (the domain in the visible From: header must match the domain authenticated by SPF or DKIM) and policy (explicit instructions telling receiving servers what to do when authentication fails). DMARC also enables aggregate reporting, so domain owners receive data about who is sending email using their domain.
A DMARC record is published at _dmarc.yourdomain.com as a DNS TXT record:
v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r
This record says: "Reject emails that fail authentication. Send me aggregate reports. Use relaxed alignment for both DKIM and SPF."
DMARC alignment: the critical concept most people miss
This is where most confusion lives. SPF and DKIM can both pass, and DMARC can still fail. Here is why.
DMARC requires alignment: the domain authenticated by SPF or DKIM must match the domain in the From: header that recipients see. If you send marketing email through a third-party service like MailChimp, that service might sign the email with its own DKIM domain (d=mailchimp.com) rather than yours. DKIM passes (the signature is valid), but DMARC fails because mailchimp.com does not match your From: domain.
The fix is configuring your third-party senders to use custom DKIM signing with your domain and to set the Return-Path to your domain for SPF alignment. Most modern email service providers support this, but it requires explicit configuration.
Relaxed vs. strict alignment. DMARC supports two alignment modes. Relaxed alignment (the default) requires only that the organizational (root) domains match. An email from [email protected] aligns with DKIM signed by d=mail.example.com because the root domain (example.com) is the same. Strict alignment requires an exact domain match, including subdomains. Start with relaxed; move to strict only after you have confirmed all your sending sources are properly configured.
The three DMARC policies
| Policy | What It Does | Protection Level | When to Use |
|---|---|---|---|
p=none |
Deliver emails normally, even when they fail authentication. Monitoring only. | None | Starting point. Collect data, identify all legitimate senders before enforcing. |
p=quarantine |
Route failing emails to the spam/junk folder. | Partial | Intermediate step. Failing emails still reach the user but are flagged. |
p=reject |
Block failing emails entirely. They never reach the recipient. | Full | Target state. Maximum protection against domain spoofing. |
A critical misconception: p=none does not protect you. It tells receiving servers to deliver failing emails normally. Your domain can be spoofed just as easily as if you had no DMARC record at all. All four major email providers accept p=none as the minimum for compliance, but it provides zero actual protection. It exists purely for monitoring and data collection before you move to enforcement (EasyDMARC, 2025; Red Sift, 2024).
Generate or validate your DMARC record with our free DMARC Record Generator.
How all three work together
Think of it as a three-layer verification chain:
- SPF answers: "Is this server allowed to send for this domain?" (server authorization)
- DKIM answers: "Has this email been tampered with since it was sent?" (message integrity)
- DMARC answers: "Does the From: address match what SPF/DKIM authenticated, and what should we do if it doesn't?" (policy enforcement)
DMARC passes when at least one of the following is true:
- SPF passes AND the SPF domain aligns with the From: domain
- DKIM passes AND the DKIM signing domain aligns with the From: domain
You do not need both SPF and DKIM to align. One is sufficient for DMARC to pass. But configuring both gives you redundancy: if SPF breaks (common with forwarding), DKIM can still carry DMARC. If DKIM breaks (rare, but possible with message modification), SPF provides the fallback.
| Protocol | Checks | Protects Against | Limitation |
|---|---|---|---|
| SPF | Sending server IP vs. authorized list | Unauthorized servers sending as your domain | Does not check visible From: header; breaks on forwarding |
| DKIM | Cryptographic hash of message content | Message tampering in transit | No policy instruction; does not tell servers what to do on failure |
| DMARC | Alignment of From: with SPF/DKIM domains | Domain spoofing in the visible From: address | Cannot catch lookalike domains (e.g., examp1e.com) |
For an expanded glossary covering SMTP, IMAP, Return-Path, and 100+ more email terms, see our Email Glossary.
The adoption problem: most domains are still unprotected
Despite all four major providers requiring authentication, the adoption numbers are worse than you might expect.
Of the 1.1 million domains monitored by DmarcDkim.com in April 2026, only 10.7% have full DMARC protection (p=reject at 100% enforcement). Another 18.5% have partial protection (p=quarantine or partial percentage). The remaining 70.9% have no effective DMARC protection at all: either p=none, an invalid record, or no record whatsoever (DmarcDkim.com, April 2026).
EasyDMARC's 2026 report across 1.8 million domains tells a similar story. Valid DMARC records grew from 523,921 in 2023 to 937,931 in early 2026, but enforcement-level policies (p=quarantine or p=reject) only cover 411,935 of those. More than half of all DMARC records are stuck at p=none: technically present, functionally useless (EasyDMARC, 2026).
The gap between large and small organizations is especially stark. Over 80% of Fortune 500 companies have enforcement-level DMARC policies. Among smaller businesses, the number drops significantly. In specific sectors: 41% of banking institutions worldwide lack DMARC entirely, and healthcare has just over one-third at even the minimum p=none level (SendLayer, 2025; Valimail, 2025).
Why all four providers now require authentication
In October 2023, Google and Yahoo jointly announced that bulk senders (5,000+ emails per day) must implement SPF, DKIM, and DMARC. Enforcement began February 2024. Microsoft followed in April 2025, with enforcement starting May 2025. Apple iCloud Mail also mandates all three protocols.
The results have been measurable. Google reported 265 billion fewer unauthenticated messages delivered to Gmail users in 2024, a 65% reduction. More than 2.5 million domains newly published DMARC records in the first 60 days of enforcement alone. During the 2024 holiday season, Gmail users encountered 35% fewer scams (Google, 2024; Valimail, 2025).
For a full breakdown of exactly what each provider requires (spam rate thresholds, one-click unsubscribe, error codes, and enforcement timelines compared side by side), see our complete guide to bulk sender requirements.
The deliverability payoff
Authentication is not just about security. It directly affects whether your emails reach the inbox.
Fully authenticated domains (SPF + DKIM + DMARC) achieve a 2.7x higher likelihood of inbox placement compared to unauthenticated emails (The Digital Bloom, 2025). One retail organization saw spoof attempts drop 93% and promotional inbox placement rise from 86% to 92% after implementing p=reject with proper DKIM alignment (Landbase, 2026).
The logic is straightforward. Inbox providers use authentication signals to assess sender reputation. A domain with p=reject and clean authentication is telling Gmail, Outlook, and Yahoo: "I take responsibility for every email sent from my domain. If it does not authenticate, it is not from me." That signal carries weight in deliverability algorithms.
Run a comprehensive deliverability check on your domain with our free Domain Email Health Score tool. It covers DNS, authentication, blacklists, and overall sending reputation in one scan.
Common configuration mistakes (and how to avoid them)
Most authentication failures are not attacks. They are misconfiguration. Here are the ones that show up most frequently.
1. Exceeding the SPF 10-lookup limit
Every include: directive triggers a DNS lookup. Add Google Workspace, your CRM, your marketing platform, your transactional email service, and you can hit 10 quickly. Exceeding the limit causes a PermError: every message fails SPF. The fix is either consolidating includes, using SPF flattening, or moving some services to DKIM-only authentication with DMARC alignment.
2. Forgetting to configure DKIM for third-party senders
Your marketing platform sends email "from" your domain, but by default it signs with its own DKIM key. DKIM passes (the signature is valid), but DMARC alignment fails because the signing domain does not match your From: domain. Every major ESP (SendGrid, Mailchimp, HubSpot, Postmark) supports custom DKIM. You just have to set it up.
3. Staying at p=none indefinitely
p=none is a starting point for monitoring, not a destination. 29.4% of all domains with DMARC records are stuck at p=none (DmarcDkim.com, 2026). This provides zero protection. The path: start at p=none, review aggregate reports for 2 to 4 weeks to identify all legitimate sending sources, move to p=quarantine with pct=10, gradually increase the percentage, and finally move to p=reject.
4. Ignoring subdomain policy
DMARC's sp= tag controls subdomain policy separately. Without it, subdomains inherit the parent domain's policy. If you have p=reject but no sp= tag, your subdomains are also at p=reject, which is probably what you want. But if you have unused subdomains (like test.yourdomain.com), attackers can spoof those unless your policy covers them. Explicitly set sp=reject if your subdomains do not send email.
5. Not monitoring DMARC reports
Setting up DMARC without a rua= tag (aggregate report address) is like installing a security camera without recording. You will never know who is sending email as your domain, whether legitimate services are failing authentication, or if you are being actively spoofed. Always include a report address.
How to check your setup right now
You can verify your entire authentication chain in under five minutes using these free tools:
- SPF: SPF Record Checker to verify your record exists, is valid, and does not exceed the 10-lookup limit.
- DKIM: DKIM Record Checker to confirm your public key is published and your key length is at least 1024-bit (2048-bit recommended).
- DMARC: DMARC Record Generator to validate your existing policy or create a new one.
- Full health check: Domain Email Health Score for a comprehensive assessment covering all protocols, DNS configuration, and blacklist status.
- Bulk sender compliance: If you send 5,000+ emails per day, run the Bulk Sender Compliance Checker to test against Google, Yahoo, and Microsoft requirements simultaneously.
If any of these checks fail, your emails may be landing in spam or getting rejected outright. As of November 2025, Gmail rejects 100% of unauthenticated emails from bulk senders. Microsoft started outright SMTP rejection in May 2025. There is no grace period left.
Frequently asked questions
What is the difference between SPF, DKIM, and DMARC?
SPF checks whether the sending server is authorized to send email for your domain. DKIM uses cryptographic signatures to verify the email was not tampered with in transit. DMARC ties both together by checking that the domain in the visible From: address aligns with the domains authenticated by SPF or DKIM, and tells receiving servers what to do when authentication fails. You need all three: SPF alone does not check the From: header users see, DKIM alone does not instruct servers on failure handling, and DMARC cannot function without at least one of the other two passing.
Do I need SPF, DKIM, and DMARC if I don't send bulk email?
Yes. Google requires SPF or DKIM from all senders, not just bulk senders. Yahoo requires both SPF and DKIM from all senders. Even if you send only a few emails per day, missing authentication can land your messages in spam or get them rejected. DMARC is technically only required for bulk senders (5,000+ emails/day) by current enforcement, but publishing a DMARC record at p=none costs nothing and gives you visibility into who is sending email using your domain.
What does DMARC p=none actually do?
A DMARC policy of p=none tells receiving servers to deliver emails that fail authentication normally, without taking any action. It is a monitoring-only mode. Your domain can still be spoofed just as easily as if you had no DMARC record at all. The value of p=none is the reporting: you receive aggregate reports showing who is sending email using your domain, which helps you identify all legitimate senders before moving to p=quarantine or p=reject.
How long does it take to set up SPF, DKIM, and DMARC?
For a single domain with one email provider, the DNS changes take about 15 to 30 minutes. SPF requires adding one TXT record. DKIM requires adding one or two TXT records (your provider gives you the values). DMARC requires one TXT record. DNS propagation typically completes within an hour. The harder part is auditing all your sending sources first: marketing platforms, CRM tools, transactional email services, and any third-party system that sends email on your behalf. For organizations with many sending sources, the full rollout to p=reject can take weeks or months of monitoring.
