Email Authentication: SPF, DKIM, and DMARC

This article has three layers:

1. Layer 1: The Intuition: Why email is so easy to spoof
2. Layer 2: Real-World Use: BEC scams, 2024 Gmail and Yahoo new requirements, anti-phishing codes
3. Layer 3: Principles and engineering key points: Detailed breakdown of the three DNS records, "alignment," and the transition from p=none to reject

Layer 1: The Intuition

1.1 The sender on the envelope can be anything

When sending a physical letter, you can write any sender address on the envelope, and the post office will not check it. Early email protocols (SMTP) worked the same way: the sender address was just a line of text that could be filled in arbitrarily.

1.2 Three patches

Layer 2: Real-World Use

• Business Email Compromise (BEC): Impersonating a boss or supplier to send emails requesting finance departments to "urgently pay to a new account." The FBI's Internet Crime Complaint Center (IC3) annual reports show that BEC causes billions of dollars in losses every year, consistently ranking among the top types of cybercrime losses.
• Gmail and Yahoo New Requirements (February 2024): Domains sending large volumes of mail to them must configure SPF, DKIM, and DMARC, otherwise emails will be rejected or sent to spam. This has turned DMARC from a "suggestion" into a de facto barrier.
• Anti-phishing codes: Many exchanges allow users to set a custom phrase, which is displayed on all official emails and pages. Any email that does not show this phrase is treated as fake. This is another manual line of defense outside of DMARC, because attackers may use a domain that looks very similar (which is not protected by your DMARC) to send mail.
• No actionable links in emails: Security-sensitive notifications only say "Please visit the official website yourself to check," fundamentally cutting off the path of "click email link → enter fake website."

Layer 3: Principles and Engineering

3.1 SPF

Add a TXT record in your DNS:

example.com.  TXT  "v=spf1 include:_spf.some-email-service.com -all"

The receiving server checks: Does the domain of the email's envelope sender (Return-Path) allow the sending server's IP to send mail? -all means all other servers are not allowed.

Limitations: SPF only checks the envelope sender, while users see the From: in their email client; the two can be different. Therefore, SPF alone cannot prevent impersonation and requires DMARC "alignment." Once expanded, an SPF record can have a maximum of 10 DNS lookups; having too many integrated sending services will exceed this limit.

3.2 DKIM

The sending server uses a private key to sign key email headers and the body, placing the signature in the DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=sel1; h=from:to:subject:date; bh=...; b=...

The receiving server uses the s= (selector) and d= (domain) to look up the sel1._domainkey.example.com in DNS to verify the signature with the public key. The signature algorithm is typically RSA (see "RSA and Euler's Theorem"), but Ed25519 is also supported.

The advantage of DKIM is that it can survive forwarding: as long as the signed parts are not modified, the signature can still be verified after forwarding.

3.3 DMARC and "Alignment"

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:[email protected]"

The core rule of DMARC: At least one of SPF or DKIM must pass, and the domain used by the passing mechanism must be aligned with the From: domain seen by the user (r relaxed alignment allows subdomains, while s strict alignment requires an exact match).

rua= specifies the address for receiving aggregate reports. Major email providers will tell you every day: "How many emails were sent in your name, how many passed, and how many failed."

3.4 Steps for tightening security

1. First, clearly list all channels sending mail on your behalf (marketing emails, transaction notifications, customer service systems, personal email);
2. Configure SPF and DKIM for each channel;
3. Use p=none for DMARC first to collect reports for a period of time to ensure all legitimate emails pass;
4. Change to p=quarantine and observe further;
5. Finally change to p=reject.

Skipping step 1 and tightening immediately most commonly results in your own legitimate emails (such as a forgotten system notification) being sent entirely to the spam folder.

3.5 What DMARC cannot control

• Similar domains: examp1e.com and example-support.com are not your domain, so your DMARC cannot control them;
• Display name spoofing: From: "Example Official" <[email protected]>; many mobile email clients only display the name.

These can only be mitigated through user education, anti-phishing codes, and "not putting actionable links in emails."

Summary