What Is Email Security? SPF, DKIM, and DMARC Explained

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

Frequently Asked Questions

What is the difference between SPF, DKIM, and DMARC?

SPF (Sender Policy Framework) specifies which mail servers are authorized to send email for a domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature that proves the email was sent by an authorized party and not modified in transit. DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on both SPF and DKIM to define what receiving servers should do with messages that fail authentication — and provides reporting that shows the domain owner who is sending email claiming to be from their domain.

What does DMARC p=reject actually do?

DMARC p=reject instructs receiving mail servers to refuse delivery of messages claiming to come from your domain that fail both SPF and DKIM authentication. With p=reject enforced, attackers cannot send spoofed email from your exact domain to any recipient whose mail server respects DMARC — which includes essentially all major email providers. p=reject is the configuration that actually prevents domain spoofing. p=none and p=quarantine are intermediate states that provide reporting and partial protection respectively.

Why do organizations stall at DMARC p=none?

Moving from p=none to p=reject requires identifying and authorizing every legitimate source that sends email using the organization's domain — marketing automation platforms, CRMs, HR systems, ticketing systems, third-party services, and shadow IT. Each must be added to SPF records or configured to sign with DKIM. Without complete inventorying, p=reject will block legitimate email and create operational disruption. Most organizations underestimate the discovery work required, deploy DMARC with p=none for reporting, and never advance to enforcement.

What is BIMI and why does it matter?

Brand Indicators for Message Identification (BIMI) is a standard that displays a verified brand logo next to authenticated emails in supporting email clients (Gmail, Yahoo, Apple Mail). It requires DMARC at p=quarantine or p=reject, plus a Verified Mark Certificate (VMC) issued by an authority. BIMI provides a visible authentication signal that helps recipients distinguish legitimate brand email from spoofed phishing — a meaningful anti-phishing benefit beyond the protocol-level enforcement that DMARC provides.

Can SPF, DKIM, and DMARC stop all phishing?

No. These protocols prevent direct spoofing of the protected domain. They do not stop phishing from lookalike domains (c1oudskope.com instead of cloudskope.com), display name spoofing ("CEO Name <random@gmail.com>"), homograph attacks using Unicode characters that visually resemble Latin letters, or phishing sent from completely unrelated domains. Email authentication is necessary but not sufficient — it must be combined with anti-impersonation technology, user awareness training, and out-of-band verification for high-risk actions.

What are the leading email security platforms?

Microsoft Defender for Office 365 is built into most enterprise Microsoft 365 subscriptions and provides anti-phishing, anti-impersonation, attachment sandboxing, and link rewriting capabilities. Proofpoint and Mimecast are the established enterprise secure email gateway leaders. Abnormal Security, Tessian, and Material Security represent the newer behavioral-AI category that focuses on detecting impersonation and account compromise patterns. Selection depends on whether the priority is integration with Microsoft, advanced threat protection, or behavioral analysis.

How long does DMARC deployment take?

For a typical mid-market organization, DMARC deployment from initial planning to p=reject enforcement is typically 4 to 9 months. The first phase — implementing SPF, DKIM, and DMARC at p=none with reporting — can be completed in a few weeks. The longer work is the inventorying of legitimate sending sources, configuring each to authenticate properly, monitoring DMARC reports, and progressively tightening the policy through p=quarantine to p=reject. Organizations with cleaner email infrastructure and centralized email administration deploy faster.

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.