# Email Authentication: SPF, DKIM, and DMARC
Email authentication is the set of DNS-based protocols that allow receiving mail servers to verify whether a message claiming to come from your domain was actually sent by an authorized system. The three core protocols, SPF, DKIM, and DMARC, work as a layered stack. SPF confirms the sending server is permitted. DKIM confirms the message was not altered in transit. DMARC ties both together with an enforcement policy and a reporting mechanism. Without this stack, any actor on the internet can send email that appears to originate from your domain, enabling phishing campaigns, supplier fraud, and business email compromise at scale. These protocols exist because the original Simple Mail Transfer Protocol (SMTP) was designed without any sender verification whatsoever.
---
Email authentication, in the context of SPF, DKIM, and DMARC, refers to a coordinated set of DNS-published records and cryptographic controls that allow receiving mail servers to verify the legitimacy of inbound messages. Each protocol operates at a different layer of the email delivery chain and addresses a different attack surface.
SPF (Sender Policy Framework) is defined in RFC 7208. It operates at the envelope level, checking whether the IP address of the sending mail server appears on the list of authorized senders published in the domain's DNS TXT record. SPF alone cannot prevent header spoofing because it checks the envelope sender, not the visible "From" header.
DKIM (DomainKeys Identified Mail) is defined in RFC 6376. It operates at the message level, attaching a cryptographic signature to selected headers and the message body. The private key signs the message at the sending server; the public key is published in DNS so any receiving server can verify the signature. DKIM survives forwarding scenarios where SPF typically breaks.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is defined in RFC 7489. It requires alignment between the domain in the visible "From" header and the domains authenticated by SPF and DKIM. This is the critical distinction: DMARC closes the gap that makes header spoofing possible even when SPF and DKIM individually pass.
What this stack is NOT: it is not an anti-spam filter, not an encryption mechanism, and not a replacement for TLS. It does not protect against account compromise on legitimate sending systems. It does not prevent malicious content inside authenticated messages.
---
SPF: Envelope Authorization
When a message arrives at a receiving mail server, that server extracts the domain from the SMTP envelope sender (also called the "mail from" or "return-path" address). It then queries DNS for the TXT record at that domain. The SPF record contains a list of authorized IP addresses, IP ranges, and included records from third-party sending services. The receiving server checks whether the connecting IP matches any authorized entry. The result is "pass," "fail," "softfail," "neutral," or "permerror."
A typical SPF record looks like:
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net -allThe "-all" at the end is a hard fail instruction: any sending IP not covered by the record should be treated as unauthorized. "~all" is a softfail, meaning suspicious but not definitively blocked. Many organizations remain on "~all" indefinitely, which significantly reduces enforcement value.
SPF has a critical limitation: it breaks when email is forwarded. When a forwarding server relays the message, the sending IP changes to the forwarder's IP, which is not on the original domain's SPF record. This is one reason DKIM exists alongside SPF rather than replacing it.
DKIM: Cryptographic Message Integrity
At the sending mail server, DKIM signing happens before the message leaves the organization's infrastructure. The signing process selects specific headers (typically "From," "To," "Subject," and "Date") plus the message body, hashes them, and signs that hash with the domain's private DKIM key. The resulting signature is embedded in a DKIM-Signature header.
The receiving server extracts the selector and domain from the DKIM-Signature header, queries DNS for the public key at that selector, and verifies the signature. If the message was altered in transit (even a single character changed in a covered header), the signature verification fails.
A DNS query for a DKIM key looks like: selector._domainkey.example.com
Organizations running multiple mail platforms (transactional email, marketing platforms, CRM) typically need multiple DKIM selectors, one per platform.
DMARC: Alignment and Enforcement
DMARC introduces the concept of identifier alignment. For a message to pass DMARC, at least one of the following must be true: the domain authenticated by SPF must align with the domain in the visible "From" header, or the domain authenticated by DKIM must align with the domain in the visible "From" header. Alignment can be "relaxed" (subdomains are acceptable) or "strict" (exact match required).
The DMARC record is a DNS TXT record published at _dmarc.example.com. It specifies the policy and where to send aggregate and forensic reports.
A functional DMARC record at enforcement stage:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s;The p= tag defines the policy applied when authentication fails. p=none means no enforcement action, collect data only. p=quarantine means treat failed messages as suspicious (often routing to junk folders). p=reject means hard-reject failed messages at the SMTP level.
Subdomain Handling and Policy Inheritance
DMARC policy inheritance represents a common source of implementation confusion. A DMARC record published on the organizational domain (example.com) applies to all subdomains unless a subdomain publishes its own DMARC record. If marketing.example.com publishes its own DMARC record, it overrides the parent domain policy for that subdomain only.
This becomes operationally critical when different business units control different subdomains. The IT department may enforce p=reject on the primary domain, while the marketing department runs email campaigns from a subdomain with a less restrictive policy. DMARC reports show per-subdomain authentication results, but analysis requires understanding which subdomains are intentionally separate from the parent policy.
The Three-Protocol Interaction
A concrete example demonstrates how all three protocols function together. An organization publishes SPF, DKIM, and DMARC records. An attacker attempts to spoof the organization's domain from an unauthorized IP address. The receiving mail server performs this sequence:
p=reject, the message is discarded. If p=quarantine, it goes to junk. If p=none, it is delivered but the failure is recorded.Without DMARC, the message might be delivered even with SPF and DKIM failures, because many mail servers treat individual protocol failures as advisory rather than determinative.
Implementation Sequencing
The standard deployment sequence is: SPF first, then DKIM, then DMARC at p=none for monitoring, then policy advancement to p=quarantine or p=reject. This sequence exists because skipping to enforcement without baseline data causes legitimate mail delivery failures.
Organizations frequently discover unexpected sending sources during the monitoring phase. Third-party CRM platforms, automated invoice systems, and notification services often send email using the organization's domain without prior coordination with IT. DMARC aggregate reports identify these sources before enforcement breaks them.
---
Business email compromise (BEC) caused more than $2.9 billion in reported losses in the United States in 2023 according to the FBI Internet Crime Complaint Center. The majority of BEC attacks rely on domain spoofing or closely related techniques. Email authentication directly reduces the attack surface for this class of threat.
Without SPF, DKIM, and DMARC, any external actor can send email that appears, in the recipient's mail client, to come from a trusted domain. The message may display the correct logo, the correct sender name, and a legitimate-looking email address while originating from infrastructure the domain owner has never touched.
Real-World Attack Scenarios
A manufacturing company with 300 employees and multiple supplier relationships becomes a target for invoice fraud. Attackers study the company's public payment terms and typical supplier communications. They craft emails appearing to come from a known supplier, requesting updated payment information for an upcoming invoice. Without email authentication, these spoofed messages pass directly to the accounting department's inboxes. The accounting team processes the payment redirect, sending $450,000 to an attacker-controlled account.
This scenario repeats across industries with variations. Healthcare organizations face spoofed communications appearing to come from pharmaceutical suppliers. Construction companies receive fake change orders appearing to come from subcontractors. Financial services firms see spoofed messages appearing to come from correspondent banks or clearing houses.
The common factor is trust-based relationships conducted over email. When authentication is absent, attackers exploit the inherent trust between business partners. Recipients have no technical mechanism to verify that a message actually originated from the claimed sender.
The Vendor Ecosystem Problem
Organizations implementing email authentication often discover that their vendors, suppliers, and business partners lack proper authentication controls. A company may deploy robust DMARC at p=reject on its own domain while remaining vulnerable to spoofed communications impersonating vendor domains that have weak or nonexistent authentication.
This creates a asymmetric risk situation. The organization protects against impersonation of its own domain but remains exposed to attacks impersonating partner domains. A comprehensive email authentication strategy requires vendor risk assessments that include DMARC policy evaluation.
Common Misconceptions
The first misconception is that SPF alone is sufficient. SPF checks the envelope sender, not the visible "From" header. An attacker can pass SPF while displaying a completely different "From" address in the recipient's mail client. DMARC is required to enforce alignment between the envelope and the visible header.
The second misconception is that deploying DMARC at p=none constitutes protection. It does not. p=none is a monitoring posture only. It collects data but does not block any messages. Organizations that publish p=none and never advance to enforcement have the administrative overhead of email authentication without the security benefit.
The third misconception is that these protocols prevent all phishing. They prevent domain spoofing of your specific domain. They do not prevent look-alike domains (typosquatting), compromised legitimate accounts, or social engineering through authenticated channels.
Deliverability and Business Impact
Email authentication significantly impacts message deliverability. Major email providers (Gmail, Outlook, Yahoo) factor authentication status into spam filtering decisions. Messages from domains with strong authentication are more likely to reach inboxes. Messages from domains without authentication are more likely to be filtered as spam.
Google and Yahoo announced requirements in 2024 that bulk email senders must implement SPF, DKIM, and DMARC to maintain deliverability to their platforms. This shift makes email authentication a business necessity rather than a security-only consideration.
---
CDA approaches email authentication through the Planetary Defense Model (PDM) with domain assignment to DPS (Data Protection and Sovereignty). The governing methodology is the Sovereign Data Protocol (SDP), which holds that your data lives where you decide, on your infrastructure, under your control, subject to your policies, and not as a side effect of vendor defaults.
In practice, this means CDA does not treat email authentication as a one-time setup task completed by adding DNS records and forgetting them. The SDP framework treats email authentication as an ongoing operational control with three distinct phases: baseline establishment, continuous monitoring, and active enforcement.
Baseline establishment requires a complete inventory of all systems that send email using the organization's domain. This includes primary mail infrastructure, marketing platforms, transactional notification services, HR and payroll systems, third-party ticketing tools, and any customer-facing automation. CDA's baseline methodology requires that each sending source be documented with its IP ranges, DKIM selector, and ownership before any DMARC record is published.
Continuous monitoring means DMARC aggregate reports are parsed, normalized, and reviewed on a defined schedule. New unauthorized sources appearing in aggregate reports are treated as potential incidents, not as administrative noise. CDA integrates DMARC reporting into its operational monitoring cadence rather than routing reports to an unread mailbox.
Active enforcement means advancing DMARC policy to p=reject is a defined milestone with specific acceptance criteria: no legitimate sending sources failing authentication for a defined observation period. CDA treats p=quarantine as a transitional state, not a permanent destination.
What CDA does differently is connect email authentication status to vendor risk assessments. When evaluating a third-party vendor's security posture, CDA reviews their DMARC policy as a concrete indicator of their operational security maturity. A vendor domain with no DMARC record or a permanent p=none policy is flagged in the vendor risk register.
The SDP principle of data sovereignty extends to email authentication through domain ownership verification. CDA validates that organizations maintain authoritative control over their domain DNS records and are not dependent on external parties to publish or modify authentication records. Email authentication that can be disabled by a hosting provider or domain registrar without the organization's direct action violates data sovereignty principles.
---
p=reject on a defined timeline: Deploy at p=none to collect reports, analyze aggregate data for 30 to 60 days, cover all legitimate senders, move to p=quarantine, then move to p=reject. Leaving enforcement at p=none permanently eliminates the protection value.---
---