Email Authentication: SPF, DKIM, and DMARC

The core SMTP protocol (designed in the 1970s) has no built-in sender authentication. Any mail server can claim to send email from any domain — a technique called email spoofing. Attackers exploit this to send phishing emails that appear to come from legitimate organizations (your bank, your CEO, a known vendor). Three DNS-based email authentication standards were developed to address this: SPF, DKIM, and DMARC. Each addresses a different aspect of the spoofing problem, and they work best when deployed together.

SPF is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of a domain. When a receiving mail server gets a message claiming to be from example.com, it looks up the SPF record for example.com and verifies that the sending server's IP address is listed. If the IP is not authorized, the message can be marked as spam or rejected. SPF checks the envelope From address (the SMTP MAIL FROM command), not the display From header visible to users.

SPF has two significant limitations. First, forwarding breaks SPF: when email is forwarded, the forwarding server's IP is not in the original domain's SPF record, causing SPF to fail on legitimate forwarded mail. Second, SPF only authenticates the envelope From (invisible to users), not the From header visible in email clients. Attackers can still spoof the visible From header while using an SPF-passing envelope From — this is why SPF alone is insufficient. DKIM and DMARC address these gaps.

DKIM adds a cryptographic signature to outgoing emails. The sending mail server uses a private key to sign specific email headers and the message body, adding a DKIM-Signature header. The public key is published as a DNS TXT record under a selector subdomain. Receiving servers retrieve the public key and verify the signature, confirming that the email was not tampered with in transit and that it originated from a server with access to the private key. Unlike SPF, DKIM signatures survive forwarding because they are carried in the email headers.

DKIM uses selectors to allow multiple simultaneous public keys for a domain — useful for running multiple mail services (Google Workspace + a marketing platform) or for key rotation without disruption. The selector name is included in the DKIM-Signature header so receiving servers know which DNS record to query. Organizations should rotate DKIM keys annually or when a key is suspected compromised. Key length: minimum 2048-bit RSA keys are recommended; 1024-bit keys are deprecated and breakable with modern compute.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM by adding: an alignment check (the domain in the visible From header must align with the SPF or DKIM authenticated domain) and a policy that tells receiving servers what to do when messages fail. DMARC policies are none (monitor only), quarantine (deliver to spam folder), or reject (do not deliver). DMARC also enables aggregate reports (RUA) and forensic reports (RUF) sent back to the domain owner for visibility into who is sending on your behalf.

Alignment is what makes DMARC powerful against header spoofing. For SPF alignment, the domain in the SMTP envelope From must match the domain in the visible From header. For DKIM alignment, the signing domain (d= in DKIM-Signature) must match the From header domain. In strict mode, domains must match exactly. In relaxed mode, subdomains are acceptable. An email passes DMARC if it passes SPF OR DKIM with proper alignment — it does not need to pass both. The combination closes the loophole that SPF alone leaves open for visible header spoofing.

Organizations should deploy DMARC progressively to avoid disrupting legitimate email. Stage 1: Deploy SPF and DKIM for all mail streams. Stage 2: Publish p=none DMARC record with RUA reporting. Analyze reports (tools: DMARC Analyzer, dmarcian) to discover all legitimate sending sources over 2-4 weeks. Stage 3: Move to p=quarantine; pct=10, gradually increasing pct to 100%. Stage 4: Move to p=reject once all legitimate streams pass. Rushing to reject before discovering all mail streams causes legitimate email to be rejected.

BIMI is an emerging standard that builds on DMARC. When a domain has a DMARC policy of quarantine or reject, email clients (Gmail, Apple Mail) can display the brand's verified logo next to the sender's name in the inbox. BIMI requires a Verified Mark Certificate (VMC) from an approved issuer confirming trademark ownership. While BIMI is not yet on the Security+ exam, it represents the direction of email authentication — making verified senders visually distinguishable from spoofed ones at a glance.

The three standards form a complete email authentication system. SPF verifies the sending server is authorized by the domain owner. DKIM verifies message integrity and that the sending organization holds the private key. DMARC ties both to the visible From header, enforces policy on failures, and provides reporting. No single standard is sufficient: SPF alone cannot prevent visible header spoofing; DKIM alone does not mandate rejection of failures; DMARC alone without SPF or DKIM has nothing to check against. All three must be deployed together for full protection against domain spoofing.

A practical defense-in-depth measure against phishing and BEC is adding an external email warning banner to every message that originates from outside the organization. This banner — typically inserted by the SEG — alerts employees that an email came from an external sender, even when the display name appears to be a colleague or executive. Banners are especially effective at flagging BEC attempts where the attacker uses a lookalike domain or display-name spoofing. The banner should be visually distinctive (colored header or footer) and should include instructions for reporting suspicious messages.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: SPF uses DNS TXT records to authorize sending IPs but only checks the envelope From, not the visible header, DKIM adds cryptographic signatures that verify message integrity and survive forwarding, and DMARC ties SPF and DKIM to the visible From header with alignment checks and an enforceable policy (none/quarantine/reject) plus reporting. Next up we explore secure email gateways and anti-spam controls.