SPF, DKIM, and DMARC: Email Authentication Explained

The Problem: Email Spoofing

The original SMTP protocol has no built-in way to verify that the sender of an email is who they claim to be. Anyone can send an email claiming to be from ceo@yourcompany.com, and the receiving server has no way to tell it is fake. This design flaw enables phishing, business email compromise, and domain impersonation at scale.

SPF, DKIM, and DMARC are three complementary protocols that solve this problem. Each addresses a different aspect of email authentication, and together they form a complete defense against email spoofing.

SPF: Sender Policy Framework

SPF answers a simple question: is this server authorized to send email on behalf of this domain? Domain owners publish a list of authorized mail servers in a DNS TXT record. When a receiving server gets an email, it checks the sending server's IP address against this list.

SPF Record Syntax

An SPF record is a DNS TXT record on the domain's apex. It always starts with v=spf1 and ends with an all qualifier:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.0/24 -all

SPF Mechanisms

• ip4: / ip6: -- Authorize specific IP addresses or ranges.
• include: -- Include the SPF record of another domain. Used for third-party email services like Google Workspace, Mailgun, or SendGrid.
• a -- Authorize the IP addresses of the domain's A records.
• mx -- Authorize the IP addresses of the domain's MX records.

SPF Qualifiers

• + (Pass) -- Authorize the sender. This is the default if no qualifier is specified.
• - (Fail) -- Reject the email. Used in -all to hard-fail unauthorized senders.
• ~ (SoftFail) -- Accept but mark as suspicious. ~all is the most common ending, but -all is more secure.
• ? (Neutral) -- No opinion. Rarely useful.

Common SPF Mistakes

• Too many DNS lookups: SPF allows a maximum of 10 DNS lookups (includes, MX, A mechanisms). Exceeding this silently breaks SPF. Use tools to flatten your record if needed.
• Using +all: This authorizes the entire internet to send email as your domain. Always use -all or at minimum ~all.
• Forgetting third-party services: If you use a CRM, newsletter service, or transactional email provider, they need to be included in your SPF record.

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing emails. The sending server signs the message with a private key, and the receiving server verifies the signature using a public key published in DNS. This proves that the email was not altered in transit and that it originated from an authorized system.

How DKIM Works

1. The sending mail server generates a digital signature of the email headers and body using a private key.
2. The signature is added to the email as a DKIM-Signature header.
3. The receiving server extracts the selector and domain from the signature header.
4. It looks up the public key at <selector>._domainkey.<domain> in DNS.
5. It verifies the signature against the email content.

DKIM DNS Record

selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

• v=DKIM1: Version identifier.
• k=rsa: Key type (RSA is standard; Ed25519 is gaining adoption).
• p=: The base64-encoded public key.

DKIM vs SPF

SPF verifies the sending server; DKIM verifies the message content. SPF breaks when email is forwarded (because the forwarding server's IP is not in the original domain's SPF record). DKIM survives forwarding because the signature travels with the message. This is why both protocols are needed.

DMARC: Domain-based Message Authentication, Reporting, and Conformance

DMARC ties SPF and DKIM together and adds a policy layer. It tells receiving servers what to do when an email fails authentication, and it provides a reporting mechanism so domain owners can monitor abuse.

DMARC Record Syntax

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"

DMARC Policies

• p=none: Monitor only. No enforcement. Use this when first deploying DMARC to collect reports without impacting email delivery.
• p=quarantine: Send failing emails to the spam folder.
• p=reject: Reject failing emails outright. This is the strongest protection, but deploy it only after monitoring with p=none to avoid blocking legitimate email.

DMARC Alignment

DMARC introduces the concept of alignment: the domain in the visible From: header must match the domain used by SPF or DKIM. This prevents an attacker from passing SPF with their own domain while spoofing the From: header to show yours. An email passes DMARC if either SPF or DKIM passes and is aligned.

DMARC Reporting

The rua tag specifies an email address to receive aggregate reports. These XML reports show which servers are sending email using your domain and whether they pass or fail authentication. Analyzing these reports is essential before moving from p=none to p=reject.

Deployment Roadmap

Implementing email authentication is a staged process:

1. Publish an SPF record listing all authorized senders, ending with -all.
2. Enable DKIM signing on all outbound email services and publish the public keys in DNS.
3. Publish a DMARC record with p=none and a rua address for reports.
4. Monitor DMARC reports for 2-4 weeks to identify any legitimate services that fail authentication.
5. Fix alignment issues for any failing legitimate services.
6. Move to p=quarantine, then to p=reject once all legitimate email passes.

Check Your Configuration

Use our Domain Intelligence Dashboard to instantly check a domain's SPF, DKIM, and DMARC configuration. The DNS panel shows all TXT records and the email security section provides a grade with specific recommendations for improvement.