SPF vs DKIM vs DMARC

Three protocols that work together to prevent email spoofing. Each solves a different part of the problem. You need all three.

Quick Comparison

Feature	SPF	DKIM	DMARC
What it does	Authorizes which IPs can send for your domain	Cryptographically signs message headers and body	Enforces policy based on SPF and DKIM alignment
How it works	Receiving server checks sender IP against DNS TXT record	Receiving server verifies signature using public key in DNS	Receiving server checks that SPF or DKIM pass and align with the From header
DNS record type	TXT on domain	TXT on selector._domainkey subdomain	TXT on _dmarc subdomain
Protects against	Unauthorized servers sending as your domain	Message tampering and forged sender domains	From header spoofing (what users actually see)
Can stand alone?	Partially. Only checks envelope sender.	Partially. Only checks signing domain.	No. Requires SPF or DKIM to function.
Requires the others?	No, but limited without DMARC	No, but limited without DMARC	Yes, needs at least one of SPF or DKIM

SPF (Sender Policy Framework)

SPF lets a domain owner publish a list of IP addresses and hostnames authorized to send email on behalf of that domain. The record is a DNS TXT entry on the domain itself. When a receiving mail server gets a message, it looks up the SPF record for the envelope sender domain (the MAIL FROM address) and checks whether the sending server's IP is in the authorized list.

An SPF record looks like this: v=spf1 include:_spf.google.com ip4:203.0.113.5 -all. The include: mechanism pulls in another domain's SPF record (useful for SaaS providers). The trailing -all means "reject everything not listed." A softer ~all means "mark as suspicious but don't reject."

SPF has two significant limitations. First, it checks the envelope sender (MAIL FROM), not the From header that users see in their email client. An attacker can pass SPF while still spoofing the visible From address. Second, SPF breaks when messages are forwarded, because the forwarding server's IP is not in the original domain's SPF record. These gaps are why SPF alone is not enough.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing messages. The sending server signs selected headers and the message body using a private key, then adds a DKIM-Signature header to the message. The corresponding public key is published as a DNS TXT record under a selector subdomain, like s1._domainkey.example.com.

When a receiving server sees a DKIM signature, it fetches the public key from DNS and verifies the signature. A valid signature proves two things: the message was authorized by the domain that signed it, and the signed portions of the message have not been modified in transit.

DKIM survives forwarding because the signature travels with the message (as long as the forwarding server does not modify the signed headers or body). However, DKIM by itself does not tell the receiving server what to do if verification fails. It also does not require that the signing domain match the From header. A spammer can sign a message with their own domain while forging someone else's From address.

DMARC (Domain-based Message Authentication)

DMARC closes the gaps left by SPF and DKIM. It introduces the concept of alignment: either the SPF-authenticated domain or the DKIM-signing domain must match (or be a subdomain of) the domain in the From header. This prevents attackers from passing SPF or DKIM with their own domain while spoofing someone else's From address.

A DMARC record is published as a DNS TXT entry at _dmarc.example.com. The key field is the policy (p=), which tells receiving servers what to do when a message fails alignment: none (monitor only, take no action), quarantine (send to spam), or reject (drop the message entirely).

DMARC also provides a reporting mechanism. The rua tag specifies where to send aggregate reports (daily XML summaries of authentication results). The ruf tag specifies where to send forensic reports (details about individual failures). These reports are essential for understanding who is sending email as your domain before moving to an enforcement policy.

How They Work Together

When a message arrives, the receiving server runs through the full authentication flow. First, it checks SPF by comparing the sending IP against the envelope sender's SPF record. Second, it checks DKIM by verifying any cryptographic signatures on the message. Third, it looks up the DMARC record for the From header domain and checks alignment: does the SPF-authenticated domain or the DKIM-signing domain match the From domain? If at least one passes with alignment, DMARC passes. If neither does, the server applies the DMARC policy (none, quarantine, or reject).

This layered approach means SPF handles IP authorization, DKIM handles message integrity, and DMARC ties them both to the domain that users actually see. No single protocol covers all three concerns.

Common Mistakes

• Deploying SPF without DMARC. SPF alone does not prevent From header spoofing. Without DMARC, there is no policy enforcement and no reporting.
• Leaving p=none indefinitely. The monitoring phase is important, but p=none does not block any spoofed messages. Set a timeline to move to quarantine and then reject.
• Forgetting to include all senders in SPF. Marketing platforms, transactional email services, CRM tools, and helpdesk software all send email as your domain. Miss one and legitimate mail gets rejected.
• Not rotating DKIM keys. DKIM private keys should be rotated periodically (at least annually). If a key is compromised, an attacker can sign messages that pass DKIM verification.
• DMARC breaking mailing lists. Mailing lists typically modify the subject or body, which breaks DKIM. They also change the envelope sender, which breaks SPF alignment. Use p=quarantine or p=reject carefully and monitor rua reports for false positives from list traffic.