What is Email Security? SPF, DKIM, and DMARC Explained
Email security uses SPF, DKIM, and DMARC to authenticate email and prevent domain spoofing.
SPF, DKIM, and DMARC Explained
SPF: Sender Policy Framework
SPF is a DNS record that specifies which mail servers are authorized to send email on behalf of a domain. When a receiving mail server receives an email claiming to be from example.com, it checks the SPF DNS record to verify that the sending server's IP address is on the authorized list. If not, the message fails SPF. SPF prevents attackers from sending email using forged return paths from unauthorized servers.
DKIM: DomainKeys Identified Mail
DKIM adds a cryptographic signature to outgoing emails signed with a private key held by the sending organization. The corresponding public key is published in DNS. Receiving mail servers verify the signature, confirming the email was sent by an authorized party and has not been modified in transit. DKIM signatures survive forwarding, providing authentication that SPF cannot maintain through email forwarding chains.
DMARC: Domain-based Message Authentication, Reporting, and Conformance
DMARC builds on SPF and DKIM by defining what receiving servers should do with messages that fail authentication — nothing (p=none), quarantine (spam folder), or reject (block entirely) — and by providing reporting that shows domain owners who is sending email claiming to be from their domain. DMARC with a reject policy eliminates the ability to send spoofed email from a protected domain.
DMARC Deployment Reality
A DMARC policy of p=none provides no protection — it only generates reports. Organizations that display DMARC in compliance questionnaires but have p=none policies have not implemented any actual protection against domain spoofing. Moving to p=reject requires inventorying and authorizing all legitimate email sending sources — marketing automation, CRMs, customer support tools, HR systems, payroll services — so enforcement does not block legitimate outbound email. This process causes many organizations to stall at p=none indefinitely.
Implementing Email Authentication
Deployment of SPF, DKIM, and DMARC for an organization's email infrastructure is a multi-step process that requires DNS configuration changes, email infrastructure adjustments, and a monitoring period before full enforcement. Most mid-market organizations have SPF and DKIM configured but DMARC either absent or in monitoring mode without enforcement — a configuration that provides reporting visibility but does not actually block spoofed messages. Moving from p=none monitoring to p=reject enforcement is the gap that most organizations have not closed.
Related Reading
- Business Email Compromise (BEC) — the attack pattern these protocols defend against
- Spear Phishing — targeted phishing that frequently spoofs sender identity
- DNS Security — the DNS layer SPF/DKIM/DMARC depend on
Real-World Example: DMARC Blocks NHS Spoofing Campaign
During the COVID-19 pandemic, NHS domains were targeted by spoofing campaigns sending phishing emails appearing to come from nhs.gov.uk addresses. The NHS had implemented DMARC with a reject policy, meaning spoofed emails using NHS domains were rejected at receiving mail servers before delivery. The campaign was significantly less effective against recipients whose organizations enforced DMARC, demonstrating that DMARC enforcement provides real-world protection against domain spoofing attacks at scale.
Phishing emails sent daily globally — the overwhelming majority of which are blocked by email authentication protocols when properly configured. DMARC with a reject policy eliminates domain spoofing attacks entirely for protected domains.
.png)