SPF, DKIM, and DMARC Explained: Email Authentication for Developers

Anyone on the internet can send an email claiming to be from your domain. Without authentication records in your DNS, there's nothing technically stopping a scammer from forging your From address and phishing your users or partners. SPF, DKIM, and DMARC are the three DNS-based standards that change this — together, they prove an email is genuinely from you, and tell receiving servers what to do when it isn't.

How Email Spoofing Works (Without Authentication)

SMTP, the protocol email runs on, was designed in 1982. It has no authentication built in. When a server connects to another and says "I have a message from [email protected]," the receiving server has historically had no way to verify that claim. It either accepts or rejects based on IP reputation heuristics — a blunt instrument that attackers have exploited for decades.

Authentication records give receiving mail servers a way to check: "Does the DNS for yourcompany.com authorize this server to send on its behalf?"

SPF: Which Servers May Send Mail

Sender Policy Framework is a TXT record published in your DNS that lists every server authorized to send email from your domain.

SPF Record Syntax

v=spf1 mx ip4:203.0.113.42 include:_spf.google.com ~all

Part	Meaning
v=spf1	Protocol version — always this
mx	Authorize the mail servers in your MX records
ip4:203.0.113.42	Authorize a specific IPv4 address
ip6:2001:db8::/32	Authorize an IPv6 range
include:_spf.google.com	Include another domain's SPF (for Google Workspace, Mailchimp, etc.)
~all	Softfail — mark unauthorized senders as suspicious
-all	Hardfail — reject unauthorized senders
?all	Neutral — no policy (essentially useless)

Common qualifier meanings:

• ~all — Softfail: accept but mark as spam. Good starting point.
• -all — Hardfail: reject outright. Use once you've verified all legitimate senders.
• +all — Accept any sender (defeats the purpose — never use this).

SPF Limits

SPF has a 10 DNS lookup limit. Every include:, mx, a, and exists mechanism that requires a DNS lookup counts toward this limit. Exceeding it causes an SPF permerror, which some receivers treat as a failure. If you use many email services (transactional email, CRM, marketing), monitor your lookup count.

DKIM: Cryptographic Email Signing

DomainKeys Identified Mail attaches a cryptographic signature to every outgoing email. The receiving server fetches your public key from DNS and verifies the signature — proving the email was sent by someone with your private key and that the message wasn't altered in transit.

How DKIM Works

1. Your sending server generates a key pair (private + public).
2. The private key is stored on your mail server.
3. The public key is published as a DNS TXT record under selector._domainkey.yourdomain.com.
4. When sending, the server signs the email headers and body with the private key and adds a DKIM-Signature header.
5. The receiving server fetches the public key from DNS and verifies the signature.

DKIM DNS Record

selector._domainkey.yourdomain.com  TXT
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

The selector is a label you choose (e.g. google, mail, s1) — it lets you publish multiple DKIM keys for different senders.

What DKIM Protects

DKIM signs the message content and selected headers. A matching DKIM signature proves:

• The message originated from a server with your private key
• The signed headers and body haven't been modified since signing

DKIM does not protect the From header against display-name spoofing in all cases — that's what DMARC adds.

DMARC: Policy and Reporting

Domain-based Message Authentication, Reporting, and Conformance ties SPF and DKIM together by adding:

1. Alignment — the domain in From must align with the domain that passed SPF or DKIM
2. Policy — tells receivers what to do when alignment fails (nothing, quarantine, or reject)
3. Reporting — receives aggregate and forensic reports from receivers about messages using your domain

DMARC Record Syntax

_dmarc.yourdomain.com  TXT
v=DMARC1; p=quarantine; sp=reject; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r

Tag	Meaning
v=DMARC1	Protocol version
p=none|quarantine|reject	Policy for the root domain
sp=none|quarantine|reject	Policy for subdomains
rua=mailto:...	Address to receive aggregate reports (XML, daily)
ruf=mailto:...	Address to receive forensic reports (individual failures)
pct=100	Percentage of messages the policy applies to (100 = all)
adkim=r|s	DKIM alignment: r = relaxed, s = strict
aspf=r|s	SPF alignment: r = relaxed, s = strict

Alignment modes:

• Relaxed (r) — the organizational domains match (e.g. mail.yourdomain.com aligns with yourdomain.com)
• Strict (s) — the exact domains must match

DMARC Policy Progression

Start permissive and tighten once you understand your email traffic:

1. p=none — Monitor-only. Messages pass regardless. Use this while reviewing rua reports to identify all legitimate senders.
2. p=quarantine — Messages that fail go to spam. Use this once you're confident your legitimate senders all pass.
3. p=reject — Messages that fail are rejected outright. Full protection. Use this when your reports confirm no legitimate email is failing.

Jumping straight to p=reject without understanding your mail flows will cause legitimate email to be dropped.

The Three Records Working Together

DMARC requires that a message passes at least one of:

• SPF alignment — passes SPF AND the SPF domain aligns with From
• DKIM alignment — passes DKIM AND the DKIM d= domain aligns with From

SPF alone is insufficient for DMARC because SPF checks the MAIL FROM (envelope sender), not the From header. A spammer can set MAIL FROM to their own domain (which passes SPF) while showing your domain in From. DKIM alignment is what closes this gap.

Common Mistakes

Publishing -all in SPF before discovering all senders — Start with ~all. Run with p=none in DMARC until aggregate reports confirm all legitimate sources are covered, then tighten.

No DKIM for third-party senders — Every service that sends email on your behalf (Mailchimp, HubSpot, Zendesk, transactional email providers) needs either its own DKIM setup or needs to be listed in your SPF record. Check your provider's documentation for their DKIM setup instructions.

Sending DMARC reports to an unmonitored address — Aggregate reports are the only feedback loop you have. Set up a mailbox and review them weekly when you're deploying, or use a DMARC monitoring service.

Subdomain policy — By default, sp inherits p. Set sp=reject explicitly once subdomains are covered, or attackers will target subdomains you didn't think to protect.

Tools

Build a syntactically correct SPF record with the SPF Record Builder, which lets you add include mechanisms, IP ranges, and choose your fail policy interactively. Configure all DMARC tags and generate a ready-to-publish record with the DMARC Record Builder. Once published, verify your records are live with a DNS lookup tool.