DMARC, DKIM, and SPF Implementation Guide for Security Teams
SPF, DKIM, and DMARC are three complementary email authentication protocols that work together to prevent unauthorized parties from sending email that appears to come from your domain. Without them, any attacker can craft a phishing email that passes all header checks and displays your domain name as the sender — convincing recipients that the message is legitimate.
Since February 2024, Google and Yahoo require that bulk email senders (more than 5,000 messages per day to Gmail or Yahoo accounts) have DMARC configured with at least p=none. This has accelerated adoption, but understanding how to progress from monitoring mode to enforcement mode is where most organizations get stuck. This guide covers the technical implementation and the safe policy progression.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts — distilled for practitioners. 50,000+ subscribers. No noise.
SPF: Authorizing Sending IP Addresses
Sender Policy Framework (SPF) is a DNS TXT record that lists which IP addresses and mail servers are authorized to send email for your domain. When a receiving mail server gets a message from your domain, it checks whether the sending IP is listed in your SPF record. If it is not, the message fails SPF.
SPF record syntax: `v=spf1 [mechanisms] [all]`. Common mechanisms: `ip4:` and `ip6:` for specific IP ranges, `include:` to reference another domain's SPF record (used for SaaS senders like Google Workspace, Salesforce, Mailchimp), `a:` to authorize the domain's A record, `mx:` to authorize the domain's MX records. The `all` qualifier at the end sets the default action: `-all` (hard fail — reject unauthorized senders), `~all` (soft fail — mark as spam), `?all` (neutral — no recommendation).
Example: `v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all`
Critical SPF limitations: SPF only checks the envelope sender (the 'MAIL FROM' address used in the SMTP session), not the 'From' header visible to the recipient. This means SPF alone does not prevent header-From spoofing. SPF also breaks when email is forwarded, because the forwarding server's IP is not in the original domain's SPF record. These limitations are why DMARC is required.
DKIM: Cryptographic Sender Authentication
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outbound email. The sending mail server signs the message with a private key, and the signature is embedded in a DKIM-Signature header. Receiving servers retrieve the corresponding public key from a DNS TXT record and verify the signature — confirming that the message originated from an authorized server and that the signed portions have not been tampered with in transit.
DKIM DNS record format: published at `[selector]._domainkey.[domain]`. Example: `mail._domainkey.example.com`. The record contains the public key (`p=`) and signing algorithm (`k=rsa` or `k=ed25519`). Use 2048-bit RSA or Ed25519 keys — 1024-bit RSA is deprecated and should not be used.
DKIM implementation for common platforms: Google Workspace (Admin console > Apps > Google Workspace > Gmail > Authenticate email), Microsoft 365 (Microsoft 365 Defender portal > Policies > DKIM), Sendgrid and Mailchimp (each provide instructions for adding their DKIM DNS records). Every email sending service your organization uses must have its own DKIM configuration — a message from Salesforce must be DKIM-signed with a key from your domain (not Salesforce's domain) to pass DMARC alignment.
DMARC: Policy Enforcement and Reporting
DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM by adding a policy that instructs receiving servers what to do with messages that fail authentication, and a reporting mechanism that sends you aggregate data about all email claiming to come from your domain.
DMARC requires alignment: the domain in the 'From' header must align with either the domain that passed SPF (envelope sender) or the domain in the DKIM signature. This is the mechanism that closes the header-From spoofing gap that SPF alone cannot close.
DMARC DNS record: `_dmarc.[domain]` TXT record. Example: `v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-failures@example.com; fo=1`
Policy values: `p=none` (monitor only — do not change mail delivery, just report), `p=quarantine` (deliver to spam folder for failures), `p=reject` (block delivery of failing messages). Start at `p=none`, analyze reports for 4–8 weeks to identify all legitimate sending sources, then progress to `p=quarantine`, then to `p=reject` after confirming all legitimate senders are authenticating correctly.
DMARC Report Analysis and Policy Progression
DMARC aggregate reports (sent to the address in the `rua=` tag) are XML files delivered daily by major mailbox providers. They show every IP address that sent email claiming your domain, whether those messages passed SPF and DKIM, and whether they passed DMARC alignment. Without a report analysis tool, these XML files are nearly unreadable at scale.
Free DMARC report analysis tools: MXToolbox DMARC report analyzer, dmarcian's trial tier, EasyDMARC's free tier. These tools parse the XML and present it as a human-readable dashboard showing authorized vs. unauthorized senders, authentication pass rates, and messages failing DMARC.
Policy progression checklist: (1) Deploy p=none with rua= reporting and collect 4 weeks of data. (2) Identify all legitimate sending services that appear in reports — ESP, marketing automation, CRM, HR systems, ticketing tools. (3) Ensure every legitimate sender is configured with DKIM and SPF for your domain (not the vendor's domain). (4) Confirm 95%+ of your legitimate mail volume passes DMARC alignment. (5) Move to p=quarantine and monitor for 2–4 weeks for any legitimate mail entering spam. (6) Resolve any remaining misses. (7) Move to p=reject. Subdomains require separate DMARC records or a `sp=reject` tag on the root domain policy.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, remediation steps, and every daily briefing.
The bottom line
DMARC p=reject is the only configuration that fully prevents unauthorized parties from sending email that impersonates your domain. The path from p=none to p=reject takes 8–12 weeks of report analysis and sender cleanup for most organizations. The investment protects your domain reputation, reduces phishing attack surface for your customers and partners, and is now a requirement for bulk email senders under Google and Yahoo's sender policies.
Frequently asked questions
What is the difference between SPF, DKIM, and DMARC?
SPF authorizes which IP addresses can send email for your domain (envelope-level check). DKIM adds a cryptographic signature that proves the message came from an authorized server and was not tampered with in transit. DMARC uses the results of SPF and DKIM checks to enforce a policy (quarantine or reject) on failing messages and sends reports of all email claiming your domain to a specified address. SPF and DKIM are authentication mechanisms; DMARC is the policy and reporting layer that makes them enforceable.
Will DMARC p=reject break my email?
DMARC p=reject will block any email claiming your domain that is not properly authenticated via SPF or DKIM with alignment. If you have email sending services that are not yet configured for authentication (marketing platforms, HR systems, ticketing tools), p=reject will block those messages. This is why the policy progression from p=none (reporting only) through p=quarantine to p=reject exists — to give you time to identify and fix all legitimate senders before enforcement.
What is BIMI and how does it relate to DMARC?
Brand Indicators for Message Identification (BIMI) is a standard that allows organizations to display a verified logo in the email client inbox view next to authenticated messages. BIMI requires DMARC at p=quarantine or p=reject, a Verified Mark Certificate (VMC) from an authorized certification authority, and a BIMI DNS record pointing to your logo. It is the primary business incentive beyond security for reaching DMARC enforcement — Google, Apple Mail, and Yahoo all support BIMI logo display for verified senders.
How do I handle DMARC for email forwarding?
Email forwarding breaks SPF alignment because the forwarding server's IP is not in the original sender's SPF record. DKIM typically survives forwarding (unless the forwarder modifies the message body) and can maintain DMARC alignment on its own. For organizations with significant forwarding (alumni email, distribution lists), ARC (Authenticated Received Chain) is the emerging solution — it allows trusted intermediaries to vouch that the original message passed authentication before forwarding. Major email platforms are implementing ARC support.
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.