Email Authentication: SPF, DKIM, and DMARC Complete Guide

Email spoofing has been trivially easy since the protocol was designed in 1982. SMTP allows any sender to claim any From address, making phishing and business email compromise (BEC) attacks straightforward. The FBI's 2023 Internet Crime Report recorded $2.9 billion in losses from BEC alone — making it the single most costly cybercrime category. Three DNS-based protocols — SPF, DKIM, and DMARC — form the authentication stack that, when properly deployed together, dramatically reduces the effectiveness of email spoofing. This guide covers the technical mechanics of each, common deployment mistakes, and the tools to verify your configuration.

A spoofed email is one where the visible From address belongs to a domain the sender does not legitimately control. Without authentication, there is nothing to stop an attacker from sending email that appears to come from [email protected] to your CFO requesting a wire transfer. Receiving mail servers have no mechanism to verify the claim. SPF, DKIM, and DMARC provide that mechanism by answering three distinct questions: Was this email sent from a server authorized by the domain owner? Was the message content signed by the domain owner? And what should the receiver do if either check fails?

SPF works by publishing a DNS TXT record listing which IP addresses and mail servers are authorized to send email on behalf of your domain. When a receiving mail server receives a message claiming to be from [email protected], it queries the DNS TXT record at example.com for an SPF record and checks whether the sending IP matches any authorized source.

SPF Record Syntax

A typical SPF record:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

• v=spf1 — Version identifier, always present.
• include:_spf.google.com — Authorize all IPs listed in Google's SPF record (for Google Workspace users).
• include:sendgrid.net — Authorize SendGrid's sending IPs for transactional email.
• ip4:203.0.113.10 — Authorize a specific IPv4 address (your outbound mail server).
• ~all — Soft fail: messages from unauthorized sources should be marked suspicious but not rejected.
• -all — Hard fail: messages from unauthorized sources should be rejected. This is the recommended setting once you are confident your record is complete.

SPF Limitations

SPF checks the envelope sender (the MAIL FROM address used in the SMTP conversation), not the From header visible to users. An attacker can pass SPF by using a different, attacker-controlled domain in the envelope sender while still showing a spoofed From header. This is why SPF alone is insufficient — DMARC alignment is required to connect the SPF check to the visible From header. Additionally, SPF has a lookup limit of 10 DNS queries; exceeding this causes SPF to return a permanent error (PermError), which many receivers treat as a fail.

DKIM takes a cryptographic approach. The sending mail server signs outgoing messages with a private key, embedding a DKIM-Signature header in the email. The corresponding public key is published in DNS. Receiving servers verify the signature against the public key to confirm that the message content was signed by a party controlling the sending domain and has not been modified in transit.

How DKIM Signing Works

1. The outgoing mail server computes a hash of specified headers (From, To, Subject, Date) and the message body.
2. It signs the hash with the domain's private RSA or Ed25519 key.
3. The signature is embedded in a DKIM-Signature header along with the signing domain (d=), the selector (s=), and the list of signed headers (h=).
4. The receiving server looks up the public key at {selector}._domainkey.{domain} in DNS and verifies the signature.

DKIM DNS Record Format

default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

The selector (default in this example) allows a domain to publish multiple DKIM keys for different mail streams. The public key is base64-encoded in the p= field.

DKIM Best Practices

Use 2048-bit RSA keys or Ed25519 (more efficient, equally secure). Rotate signing keys annually or when key compromise is suspected. Use separate selectors for different mail streams (transactional, marketing, internal) so you can revoke a compromised key for one stream without affecting others. Sign at minimum the From, Subject, Date, To, and Message-ID headers; also sign the body. Include the l= (body length) parameter only if you have a specific need — it allows partial body modification without breaking the signature, which is generally undesirable.

DMARC is the policy layer that ties SPF and DKIM together and provides reporting. A DMARC policy tells receiving servers what to do when a message fails authentication (pass through, quarantine to spam, or reject), and specifies where to send aggregate and forensic reports. Critically, DMARC introduces alignment: the domain in the visible From header must match (or be a subdomain of) the domain that passed SPF or DKIM. This closes the gap that allows SPF-passing spoofed emails.

DMARC Record Format

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

• p=reject — Policy: none (monitor only), quarantine (mark as spam), or reject (refuse delivery). Start with none, graduate to quarantine, then reject.
• rua=mailto:... — Aggregate report destination. You will receive daily XML reports from every participating receiver summarizing which IPs are sending mail for your domain and whether they pass authentication.
• ruf=mailto:... — Forensic report destination. Redacted copies of individual failing messages. Not universally implemented by receivers.
• pct=100 — Apply the policy to 100% of messages. During rollout, use lower percentages (pct=10) to test before full enforcement.
• adkim=r — Relaxed DKIM alignment (subdomains of the signing domain match). Use s for strict alignment.
• aspf=r — Relaxed SPF alignment.

DMARC Deployment Sequence

1. Publish SPF and ensure all legitimate mail sources are covered.
2. Enable DKIM signing on all outbound mail streams.
3. Publish DMARC with p=none and a reporting address.
4. Analyze aggregate reports for 2–4 weeks to identify legitimate mail sources not yet covered by SPF/DKIM.
5. Fix gaps, then move to p=quarantine; pct=10, gradually increasing pct.
6. Move to p=reject once confident all legitimate mail passes authentication.

• Permissive SPF forever: Leaving ~all (soft fail) instead of graduating to -all means DMARC's quarantine/reject policy still applies, but some receivers may not enforce SPF soft fails.
• Not rotating DKIM keys: A signing key that is never rotated becomes a long-term target. Compromised signing keys allow attackers to create perfectly signed phishing emails.
• DMARC stuck at p=none forever: The monitoring phase is valuable but should not last indefinitely. An organization with p=none provides no anti-spoofing protection to email recipients despite having published a DMARC record.
• Ignoring DMARC aggregate reports: Reports are only useful if someone reads them. Use a DMARC report analyzer (Postmark DMARC, dmarcian, Proofpoint Email Fraud Defense) to parse and visualize the XML reports.
• Exceeding SPF lookup limit: Every include: directive causes DNS lookups. Chains of includes can quickly exceed the 10-lookup limit. Use SPF flattening tools or macros to compress the record.

BIMI (Brand Indicators for Message Identification) allows organizations that have reached DMARC p=quarantine or p=reject to display their logo in supporting email clients (Gmail, Apple Mail, Yahoo). It requires a DNS TXT record pointing to an SVG logo file and (for most clients) a Verified Mark Certificate (VMC) from an approved CA. BIMI increases brand trust and phishing detectability for end users.

MTA-STS (Mail Transfer Agent Strict Transport Security) and DANE (DNS-based Authentication of Named Entities) protect the SMTP transport layer — ensuring that email in transit between mail servers is encrypted and that the certificate is valid. MTA-STS is implemented via a policy file hosted at a well-known HTTPS URL and a DNS TXT record. It prevents downgrade attacks that force opportunistic TLS connections to fall back to plaintext.

• MXToolbox — SPF, DKIM, DMARC record lookups and validation.
• mail-tester.com — Send a test email to a disposable address and receive a detailed authentication report.
• Google Postmaster Tools — If your domain sends significant volume to Gmail, this dashboard shows your domain reputation and authentication pass rates.
• DMARC Analyzer / dmarcian — DMARC aggregate report visualization and alerting.

SPF, DKIM, and DMARC are complementary and mutually reinforcing. SPF restricts which servers can send as your domain. DKIM cryptographically signs messages to prove authenticity. DMARC aligns the two checks against the visible From header and enforces a policy on failures. Deploying all three at strict settings is the minimum acceptable email authentication posture for any organization that cares about protecting its domain reputation and its users from phishing. The deployment process takes weeks of analysis and gradual rollout, but the long-term protection is substantial and the tools to monitor and verify your configuration are freely available.