SPF, DKIM and DMARC Explained: The Complete Email Authentication Guide
SPF, DKIM, and DMARC are the three email authentication standards that verify a sending domain is who it claims to be. SPF authorizes sending IP addresses. DKIM cryptographically signs outgoing messages. DMARC enforces policy and protects the visible From address users see. All three work together. None is sufficient alone.
If your organization keeps receiving spoofing complaints despite having SPF configured, the reason is almost always one of two things: SPF checks the wrong address, or DMARC is set to p=none and has never been moved to enforcement. This guide explains how each standard works, where each fails individually, and how to implement all three correctly.
What Is Email Authentication and Why Does It Matter?
Email was designed without any mechanism to verify the sender. Anyone could send an email claiming to be any domain. This design gap enables email spoofing, phishing, and business email compromise. Email authentication is the set of DNS-based technical standards built to close it.
Three standards address this problem: SPF, DKIM, and DMARC. SPF and DKIM each solve different parts of the problem individually. Both have weaknesses when deployed alone. DMARC ties them together and enforces what receiving servers do when authentication fails.
Since February 2024, both Google and Yahoo require DMARC for bulk senders. Authentication is now a deliverability requirement as well as a security control. For broader context, see The Complete Guide to Email Security.
What Is SPF in Cyber Security and How Does It Work?
SPF, defined in RFC 7208, is a DNS TXT record that lists which IP addresses and mail servers are authorized to send email on behalf of a domain. Receiving mail servers check the sending IP against this record to determine whether the sender is legitimate.
| Qualifier | Meaning | DMARC Impact | Recommended For |
| +all | All senders pass (no restriction) | DMARC may pass for any sender | Never use |
| -all | Unlisted senders fail (hardfail) | DMARC fails for unlisted IPs | Production enforcement |
| ~all | Unlisted senders softfail | DMARC may fail for unlisted | Testing or migration periods |
| ?all | Neutral, no statement made | No DMARC impact | Not recommended |
The critical limitation of SPF that most guides underexplain is what SPF actually checks.
SPF checks the envelope sender, also called the Return-Path. This is a technical delivery address used for bounce handling, invisible to the end user in their email client. It is not the visible From address that recipients see when they open an email.
An attacker can send email that fully passes SPF by setting the Return-Path to a domain they legitimately control while displaying a trusted company’s domain in the visible From header. The recipient sees the familiar brand name. The email passes SPF. The attacker has successfully impersonated the target without triggering any SPF failure.
This is the precise mechanism behind phishing and BEC attacks that organizations with SPF configured do not understand why they failed to prevent. SPF was never designed to protect the visible From address. That protection requires DMARC.
Two additional SPF limitations complete the picture: SPF breaks when email is forwarded because the forwarding server’s IP is not in the original domain’s SPF record, and SPF has a maximum of 10 DNS lookups that organizations using multiple sending services frequently exceed.
For context on how spoofing attacks exploit this gap, see What Is Email Spoofing and How to Stop It.
How Do You Set Up an SPF Record for Your Domain?
Set up SPF by identifying every mail-sending service your domain uses, then creating a DNS TXT record listing each authorized sender. Use -all as your production qualifier. For Microsoft 365, include include:spf.protection.outlook.com. For Google Workspace, include include:_spf.google.com. Test with MXToolbox after publishing.
If your domain uses multiple sending services and hits the 10 DNS lookup limit, SPF flattening replaces include: references with their resolved IP addresses. Update the flattened record whenever sending service IP ranges change. Monitor and update the SPF record whenever a new sending service is added.
What Is DKIM in Cyber Security and How Does It Work?
DKIM, defined in RFC 6376, adds a cryptographic digital signature to every outgoing email. The sending mail server signs each message using a private key. The receiving server verifies the signature using the public key published in DNS under a DKIM selector record.
A valid DKIM signature confirms two things: the message was signed by a server the domain authorized, and the email body and signed headers were not modified after signing. Any change to the content or signed headers invalidates the signature.
Use 2048-bit DKIM keys. The 1024-bit key size is considered insufficient against current computing capabilities. Configure your mail server to sign with 2048-bit keys and publish the corresponding public key in DNS.
How Does DKIM Improve Email Security?
DKIM provides three genuine improvements over SPF alone. It proves message integrity by covering the email body and signed headers, making any post-delivery modification detectable. It survives email forwarding, where SPF breaks. And it provides DMARC alignment on forwarded email precisely because it does not depend on the delivery IP address.
The DKIM limitation most guides do not address is the replay attack. DKIM signs message content and headers. It does not sign the recipient address. A valid DKIM-signed email from a trusted sender can be captured and delivered to a completely different recipient without breaking the signature.
A practical example: a bank sends a DKIM-signed account notification. An attacker captures the message and delivers it to a different target at the envelope level. The email body is unchanged. DKIM passes. The new recipient receives what appears to be a verified bank communication they never requested. The signature is technically valid. DKIM cannot distinguish this scenario from legitimate delivery.
DKIM alone does not prevent replay attacks. DMARC adds the policy enforcement layer that addresses alignment between authentication results and the visible From domain. Rotate DKIM keys annually as a minimum security hygiene practice to limit exposure from any compromised key.
What Is DMARC in Email Security and How Does It Work?
DMARC, defined in RFC 7489, instructs receiving servers what to do when email fails SPF or DKIM checks. It is the only email authentication standard that protects the visible From address that recipients see in their email client.
DMARC checks whether the visible From domain aligns with the domain authenticated by either SPF or DKIM. When alignment fails, DMARC applies its configured policy: p=none (monitor only, take no action), p=quarantine (route to spam), or p=reject (block delivery entirely).
Two reporting mechanisms provide visibility: aggregate reports (rua) deliver daily authentication summaries, and forensic reports (ruf) provide data on individual failures. NIST SP 800-177 and UK NCSC guidance both identify DMARC enforcement as a baseline email security requirement. For how DMARC fits the full architecture, see Email Security Architecture: How the Full Stack Fits Together.
How Does DMARC Enhance Email Security Beyond SPF and DKIM?
DMARC closes the gap both SPF and DKIM individually leave open. SPF checks the envelope sender. DKIM checks message integrity. Neither checks the visible From address. DMARC enforces that at least one passes AND aligns with the From domain, then acts on the result.
DMARC aggregate reports give visibility into every source sending email on your domain’s behalf, including legitimate services you may have overlooked and attackers actively spoofing you. Organizations that deploy DMARC at p=none and review their first reports typically identify three to five unauthorized or misconfigured sources sending in their domain’s name.
Since February 2024, Google and Yahoo require DMARC for bulk senders, making authentication a deliverability requirement. Non-compliance causes delivery failures to Gmail and Yahoo Mail recipients.
How Do SPF, DKIM and DMARC Work Together?
SPF, DKIM, and DMARC function as a three-stage authentication chain.
SPF checks the sending IP against the envelope sender domain. DKIM validates the message signature. DMARC checks that at least one passes AND aligns with the visible From domain, then applies policy based on the result.
The failure scenario matrix is what most guides skip and what IT teams need when debugging authentication problems. When SPF passes but DKIM fails: DMARC passes only if SPF aligns with the From domain. When DKIM passes but SPF fails: DMARC passes only if DKIM aligns. When both pass but neither aligns: DMARC fails. When both fail: DMARC fails regardless of policy.
The scenario that surprises most organizations: SPF passes, DKIM passes, but DMARC still fails. This occurs when both authenticate for a domain different from the visible From header. Alignment requires the authenticated domain to match the From domain, not just that some authentication passed.
A practical example: your marketing platform sends from its own domain but displays yours in the From header. SPF passes for the platform’s domain. DKIM signs for the platform’s domain. Neither aligns with your From domain. DMARC fails and your marketing emails are blocked or quarantined.
| Feature | SPF | DKIM | DMARC |
| What It Checks | Sending IP address | Message integrity signature | Alignment with visible From |
| DNS Record Type | TXT record | TXT (selector._domainkey) | TXT (_dmarc) |
| Survives Forwarding | No | Yes, if content unchanged | Depends on SPF/DKIM result |
| Protects From Header | No | No | Yes |
| Enforces Delivery Policy | No | No | Yes (none/quarantine/reject) |
| Sufficient Alone | No | No | Only with aligned SPF or DKIM |
What Is a DMARC Policy and How Do You Set One Up Step by Step?
Moving too quickly to p=reject is the most common DMARC mistake. Follow these seven steps in order.
Step 1: Confirm SPF and DKIM are configured, passing, and aligning with your From domain before creating any DMARC record.
Step 2: Create a DMARC TXT record at p=none with aggregate reporting addresses: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Step 3: Monitor DMARC aggregate reports for four weeks using DMARC Analyzer or Dmarcian.
Step 4: Identify every legitimate sending source failing authentication and fix each failure.
Step 5: Progress to p=quarantine and monitor for a further two to four weeks.
Step 6: Confirm no legitimate senders are being quarantined and resolve any remaining failures.
Step 7: Progress to p=reject for full enforcement. Add sp=reject to your record to cover subdomains.
| Tag | Purpose | Required or Optional | Example |
| v | Version identifier | Required | v=DMARC1 |
| p | Domain policy | Required | p=reject |
| rua | Aggregate report address | Recommended | rua=mailto:dmarc@domain.com |
| ruf | Forensic report address | Optional | ruf=mailto:forensic@domain.com |
| pct | Percentage of messages subject to policy | Optional | pct=100 |
| sp | Subdomain policy | Optional | sp=reject |
| adkim | DKIM alignment mode | Optional | adkim=s |
| aspf | SPF alignment mode | Optional | aspf=r |
For the complete post-enforcement management guide, see Email Security Best Practices: The Definitive 2026 Checklist.
What Is BIMI and How Does It Connect to DMARC?
BIMI (Brand Indicators for Message Identification) displays a verified brand logo in the inbox in Gmail, Yahoo Mail, and Apple Mail alongside authenticated messages. It requires DMARC at p=quarantine or p=reject. Most major mailbox providers require a Verified Mark Certificate (VMC) to activate logo display.
BIMI is the most visible output of a complete DMARC implementation. For the full setup guide, see What Is BIMI and How It Boosts Email Brand Trust.
How Do You Test and Monitor Your Email Authentication Setup?
Test your setup using MXToolbox for SPF and DKIM record verification, Mail Tester for a full authentication pass check, and Google Postmaster Tools for Gmail delivery and domain reputation data. Route DMARC aggregate reports to DMARC Analyzer or Dmarcian and review them monthly after reaching enforcement, not only during initial setup.
Rotate DKIM keys annually. Cyber Security Solutions Ltd recommends annual key rotation as a minimum security hygiene practice. For Microsoft 365-specific configuration guidance, see Email Security for Microsoft 365: Complete Setup Guide.
Conclusion
SPF, DKIM, and DMARC email security work as a system: no single standard is sufficient alone. Moving DMARC from p=none to p=reject is the single highest-impact email security action most organizations have not yet completed. To have your current authentication configuration reviewed and gaps identified, visit cybersecuritysolutionsltd.com for a free email authentication audit.
“`htmlFAQs
No. SPF checks the envelope sender (Return-Path), not the visible From address users see. An attacker can pass SPF using a legitimate Return-Path while spoofing any domain in the From header. DMARC is required to protect the visible From address. DKIM is required for DMARC alignment on forwarded email. All three standards are needed.
DMARC p=quarantine sends failing messages to the spam folder rather than the inbox. DMARC p=reject blocks delivery entirely. p=reject is the recommended final policy for full domain protection. p=quarantine is a useful intermediate step that provides enforcement while you continue verifying no legitimate senders are being incorrectly caught.
DMARC alignment requires the domain authenticated by SPF or DKIM to match the visible From domain. SPF can pass for the envelope sender domain while the From header displays a different domain. When the authenticated domain and the From domain do not match, DMARC fails even though SPF passed. This is the most common source of unexpected DMARC failures.
Stay at p=none for a minimum of four weeks while reviewing DMARC aggregate reports. Use DMARC Analyzer or Dmarcian to identify every source sending in your domain’s name and fix all authentication failures before progressing. Moving to p=reject before legitimate senders are aligned will block real business email from customers and partners.
A DKIM replay attack captures a valid DKIM-signed email and delivers it to a different recipient. Because DKIM signs message content but not the recipient address, the signature remains valid when replayed. The new recipient receives a message that passes DKIM verification despite never being sent to them by the original legitimate sender.
Receiving servers discard email from your domain that fails DMARC alignment checks. The message is not delivered and no bounce notification goes to your domain. Legitimate sending sources that are not authenticated will have their messages silently discarded. This is why completing the full monitoring and p=quarantine phases before reaching p=reject is essential.
