SPF, DKIM, and DMARC: Email Authentication Implementation Guide
Email spoofing — sending email that appears to come from your domain when it does not — is the enabling technique behind business email compromise, phishing campaigns impersonating your brand, and executive impersonation attacks. SPF, DKIM, and DMARC are the three DNS-based email authentication standards that, when implemented correctly together, prevent unauthorized parties from sending email that passes as your domain. Google and Yahoo made DMARC a sending requirement for bulk senders in 2024; the bar for having no email authentication is rising. This guide covers implementation from DNS records through DMARC enforcement.
How Email Spoofing Works (and Why Authentication Fixes It)
The Simple Mail Transfer Protocol (SMTP) was designed in 1982 without authentication. Any mail server can claim to be sending from any domain — the 'From' header in an email is a field the sender fills in, not a verified identity. Email authentication protocols add DNS-based verification layers that receiving mail servers check before delivering email.
The SMTP trust problem
When a mail server receives an email claiming to be from ceo@yourcompany.com, SMTP provides no native mechanism to verify this claim. The receiving server accepts the delivery unless additional authentication protocols are in place.
Two envelope layers
Email has two 'From' fields: the envelope sender (Return-Path or MAIL FROM, used by servers for bounce handling) and the header From (the address displayed to the user). SPF authenticates the envelope sender; DKIM authenticates the message content and header; DMARC ties them to the visible header From. Understanding this distinction is essential for correct implementation.
SPF: Authorizing Which Servers Can Send for Your Domain
Sender Policy Framework (SPF) is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. Receiving mail servers check the envelope sender domain's SPF record against the sending server's IP address.
SPF record syntax
An SPF record is a DNS TXT record at your domain root. Example: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all. The v=spf1 identifies the record type; include: references third-party SPF records; ip4:/ip6: lists specific IP ranges; -all means reject email from servers not listed (hard fail).
SPF mechanisms and qualifiers
The final mechanism is the policy: -all (hard fail — reject unauthorized senders), ~all (soft fail — mark as suspect but deliver), ?all (neutral — no assertion), +all (pass all — effectively no SPF protection). Always use -all or ~all. Never use +all. -all is the stronger control but requires complete inventory of all authorized senders before enabling.
The 10 DNS lookup limit
SPF evaluation is limited to 10 DNS lookups. include: mechanisms each consume a lookup. Organizations with many email service providers (Salesforce, Marketo, SendGrid, Google, Microsoft) frequently hit this limit, causing SPF permerror. Solutions: flatten SPF records (replace include: with explicit IPs), use tools like dmarcian's SPF flattener, or use an SPF delegation service.
SPF does not protect the header From
SPF authenticates the envelope sender, not the visible From address. An attacker can pass SPF by sending from their own domain in the envelope while displaying your domain in the header From. This is why SPF alone is insufficient — DMARC alignment is required to tie SPF to the visible From address.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
DKIM: Cryptographic Message Signing
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing email. The private key is held by the sending mail server; the corresponding public key is published in DNS. Receiving servers verify the signature, confirming the message was sent by an authorized server and was not modified in transit.
How DKIM signing works
The sending mail server hashes specified email headers and the message body, signs the hash with the DKIM private key, and adds the signature as a DKIM-Signature header. The receiving server retrieves the public key from the sending domain's DNS (selector._domainkey.yourdomain.com), verifies the signature, and confirms message integrity.
DKIM selectors
Multiple DKIM keys can coexist for a domain using selectors (e.g., google._domainkey, s1._domainkey). This allows different email services (Google Workspace, SendGrid, Mailchimp) each to have their own DKIM signing key without conflict. Selectors also enable key rotation without disrupting other services.
Key size
Use 2048-bit RSA DKIM keys minimum. 1024-bit keys are factorizable with sufficient compute and are deprecated. Some DNS providers limit TXT record length; 2048-bit DKIM public keys may need to be split across multiple strings in the DNS record.
What DKIM does not do
DKIM verifies the message was signed by an authorized sender and was not modified in transit. It does not verify the visible From address — that alignment check is DMARC's job. A compromised email service with a valid DKIM key can still sign malicious email from your domain; DKIM signing authority must be guarded as tightly as any credential.
DMARC: Tying Authentication to the Visible From Address
DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM to establish policy for what receiving mail servers should do with email that fails authentication, and provides reporting on authentication results across all email claiming to come from your domain.
DMARC alignment requirement
DMARC requires 'alignment' between the authentication result and the visible header From address. For SPF alignment: the envelope sender domain must match the header From domain. For DKIM alignment: the d= tag in the DKIM signature must match the header From domain. This closes the SPF/DKIM bypass where attackers use their own domain to pass authentication while spoofing your visible From.
DMARC policy options
The p= tag sets the policy: p=none (monitor only — no action taken on failures, collect reports), p=quarantine (deliver failing email to spam), p=reject (block email that fails DMARC). Progression through these policies — none to quarantine to reject — is the standard implementation path.
DMARC reporting
DMARC generates two report types: aggregate reports (RUA — daily XML summaries of authentication results by sending source) and forensic reports (RUF — individual message-level reports for failures). Aggregate reports are essential for the p=none monitoring phase: they show all sources sending email from your domain and their authentication results. Set rua= to an email address you monitor or a DMARC reporting service (Postmark, dmarcian, Valimail).
DMARC record syntax
A DMARC record is a DNS TXT record at _dmarc.yourdomain.com. Example: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com; ruf=mailto:dmarc-forensics@yourcompany.com; pct=100; adkim=s; aspf=s. The adkim and aspf tags set strict vs. relaxed alignment (strict requires exact domain match; relaxed allows subdomain matches).
DMARC Policy Progression: From Monitoring to Enforcement
Jumping directly to p=reject without first inventorying all legitimate email sources will block legitimate email. The correct progression is none, then quarantine, then reject.
“p=reject is the only DMARC policy that stops spoofing. p=none and p=quarantine are monitoring phases, not security controls.”
CISA Email Authentication Guidance
Phase 1 — p=none (weeks 1-4+)
Deploy p=none with aggregate reporting enabled. Analyze aggregate reports for 2-4 weeks: identify every source sending email claiming your domain, check whether each source passes SPF and/or DKIM alignment, and identify sources that fail. Common failures: CRM systems, marketing platforms, ticketing systems, and third-party services that were not configured with your domain's DKIM key or are sending from IPs not in your SPF record.
Phase 2 — Fix authentication failures
For each failing legitimate source identified in aggregate reports: add it to the SPF record, configure DKIM signing for the service, or configure the service to use a subdomain with its own SPF/DKIM setup. Repeat until aggregate reports show near-100% pass rate for legitimate sources.
Phase 3 — p=quarantine
Once legitimate sources pass authentication, move to p=quarantine. Failing email is delivered to spam rather than rejected. Monitor for any new legitimate sources that begin failing and fix them. Run in quarantine for 2-4 weeks to confirm no legitimate email is being filtered.
Phase 4 — p=reject
The target state: email claiming to come from your domain that fails DMARC is rejected by receiving servers and never delivered. This is complete protection against your domain being spoofed in phishing. Maintain ongoing monitoring — new email services added to your environment must be authenticated before they can successfully send.
Subdomain Handling and Common Mistakes
Domain authentication must cover subdomains used for sending, and must prevent spoofing of subdomains that are not used for sending.
DMARC subdomain policy
The sp= tag in the DMARC record sets the policy for subdomains. If sp= is not set, subdomains inherit the parent domain's p= policy. Set sp=reject for subdomains that should never send email, regardless of the parent domain's policy.
Parked domain protection
Domains registered but not used for email (defensive registrations, legacy domains) should have SPF records with -all (no authorized senders) and DMARC records with p=reject. Attackers frequently spoof parked domains that organizations neglect to protect.
Common SPF mistakes
Using ~all instead of -all indefinitely (soft fail does not block spoofing); exceeding the 10-lookup limit (causes permerror, which typically results in DMARC failure); and having multiple SPF records (only one TXT record with v=spf1 is permitted — merge multiple records into one).
BIMI: The visual layer on top of DMARC
Brand Indicators for Message Identification (BIMI) allows organizations with p=quarantine or p=reject DMARC to display their brand logo in supporting email clients (Gmail, Apple Mail, Outlook). BIMI requires a Verified Mark Certificate (VMC) from a qualified certificate authority. It is a brand trust signal, not a security control, but it incentivizes reaching p=reject.
The bottom line
SPF, DKIM, and DMARC together prevent your domain from being used in phishing campaigns and business email compromise attacks. p=reject DMARC is the only configuration that provides complete spoofing protection — p=none is a monitoring phase, not a security control. The implementation path is straightforward: deploy with p=none and reporting, fix all legitimate sender authentication failures, move to quarantine, then reject. The organizations that skip this progression and jump to reject block their own legitimate email.
Frequently asked questions
What is the difference between SPF, DKIM, and DMARC?
SPF authorizes which mail servers can send email on behalf of your domain (DNS-based IP allowlist). DKIM adds a cryptographic signature to outgoing email that proves the message was sent by an authorized server and was not modified in transit. DMARC ties both together: it requires that either SPF or DKIM passes AND is aligned to the visible From address, and it specifies what receiving servers should do with email that fails (none/quarantine/reject). All three work together; each alone has significant gaps.
What does p=reject mean in DMARC?
p=reject is the DMARC policy that instructs receiving mail servers to block and reject email that fails DMARC authentication — email claiming to come from your domain that cannot be verified as sent by an authorized server. It is the only DMARC policy that completely prevents email spoofing of your domain. p=none is monitoring only (no action taken); p=quarantine delivers failing email to spam. p=reject is the target state for all domains.
Why is SPF alone not enough to prevent email spoofing?
SPF authenticates the envelope sender (the technical return-path address), not the visible From address shown to the email recipient. An attacker can pass SPF by sending from their own domain in the envelope while spoofing your domain in the visible header From — the address recipients actually see and trust. DMARC alignment closes this gap by requiring that the authenticated domain matches the visible From address.
What is the 10 DNS lookup limit in SPF and how do you fix it?
SPF record evaluation is limited to 10 DNS lookups total — each include: mechanism consumes one lookup. Organizations with many email service providers (Salesforce, Marketo, HubSpot, SendGrid, Google Workspace, Microsoft 365) frequently exceed this limit, causing permerror. Fix: flatten the SPF record by replacing include: references with the explicit IP addresses they resolve to, use an SPF macro-based delegation service (Valimail, AutoSPF), or consolidate email services to reduce the number of authorized senders.
How long should I stay at p=none before moving to p=quarantine?
Stay at p=none until aggregate reports show near-100% authentication pass rates for all legitimate email sources. This typically takes 2-6 weeks of monitoring and remediation. Common sources discovered during p=none monitoring: marketing platforms, CRM systems, HR software, ticketing systems, and third-party services that send email on your behalf. Each failing source must be fixed (DKIM configured, SPF updated) before advancing to quarantine. Moving to quarantine before fixing legitimate sources will send legitimate email to spam.
Do I need to protect parked and unused domains with DMARC?
Yes — attackers frequently spoof parked and legacy domains that organizations neglect to protect. A domain registered as a defensive registration or no longer actively used should have: an SPF record with -all (no authorized senders), a DMARC record with p=reject, and an MX record pointing to a non-existent host or with no MX record. Without these protections, attackers can use your parked domains in phishing campaigns with no authentication barriers.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.