SPF, DKIM, and DMARC: The Complete Email Authentication Guide

Email authentication is one of the most important — and most frequently broken — areas of DNS configuration.

Three records control whether email from your domain is trusted by the world's mail servers: SPF, DKIM, and DMARC. Together, they determine whether your email reaches the inbox, goes to spam, or gets rejected entirely. They also determine whether your domain can be spoofed by someone sending phishing emails that appear to come from you.

Most domains have at least one of these misconfigured. Many have none of them correctly in place.

SPF — Sender Policy Framework

What it does

SPF answers the question: which servers are authorised to send email for this domain?

It's a DNS TXT record that lists the IP addresses and services permitted to send email claiming to be from your domain. When a receiving mail server gets an email from you, it checks your SPF record to see if the sending server is on the approved list.

What it looks like

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

• v=spf1 — Required. Identifies this as an SPF record.
• include:_spf.google.com — Authorise all IP addresses in Google's SPF record.
• include:sendgrid.net — Authorise SendGrid for transactional email.
• ip4:203.0.113.10 — Authorise a specific IP address.
• -all — Reject email from any server not explicitly listed.

The 10-lookup limit

SPF allows a maximum of 10 DNS lookups during evaluation. Each include:, a:, and mx: mechanism can trigger additional lookups. Exceeding 10 causes a PermError, which many receivers treat as an SPF failure.

This is one of the most common SPF problems for organisations using multiple email services. The fix is SPF flattening — replacing include: statements with explicit IP addresses, reducing the lookup count.

~all vs -all

• ~all (softfail) — Email from unauthorised servers is flagged but may still be delivered.
• -all (fail) — Email from unauthorised servers is rejected.
• ?all (neutral) — No assertion about unauthorised servers.

Use -all. Softfail provides reduced protection and is treated inconsistently by different mail servers.

Only one SPF record

You can only have one TXT record beginning with v=spf1. If you have multiple, SPF evaluation fails with a PermError. If you need to authorise multiple sources, combine them into a single record.

DKIM — DomainKeys Identified Mail

What it does

DKIM answers the question: has this email been tampered with, and was it sent by a server authorised to sign for this domain?

Your mail server adds a cryptographic signature to outgoing email. The signature is generated using a private key. The corresponding public key is published in your DNS. Receiving servers look up the public key and use it to verify the signature.

What it looks like in DNS

DKIM records live at <selector>._domainkey.<domain>. The selector is typically defined by your email platform.

google._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Key length

DKIM keys should be at least 1024 bits. 2048 bits is now strongly recommended — some mail platforms reject email signed with shorter keys.

DKIM doesn't protect the From: address

DKIM signs the message and verifies the signing domain (d= in the DKIM-Signature header). The signing domain doesn't have to match the From: address. DMARC enforces alignment between the two — this is why DMARC is necessary for complete protection.

DMARC — Domain-based Message Authentication, Reporting & Conformance

What it does

DMARC does three things:

• Policy — Tells receiving servers what to do with email that fails SPF and DKIM alignment.
• Alignment — Requires the domain in the From: header to align with the domain that passed SPF or DKIM.
• Reporting — Sends aggregate reports back to you, showing authentication results for email claiming to be from your domain.

What it looks like

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

DMARC alignment

DMARC requires the From: domain to align with the authenticated domain. This is what prevents attackers from passing SPF on their own domain while spoofing yours in the From: header.

• Strict alignment (aspf=s, adkim=s) — The domains must match exactly.
• Relaxed alignment (aspf=r, adkim=r) — Subdomains of the authenticated domain are accepted. This is the default and is usually appropriate.

How SPF, DKIM, and DMARC work together

Think of them as three layers:

• Layer 1 — SPF controls which servers can send email for your domain.
• Layer 2 — DKIM verifies that email hasn't been tampered with and was signed by an authorised server.
• Layer 3 — DMARC ties them together: requires at least one to align with the From: domain, and specifies what happens when they don't.

An email passes DMARC if:

• SPF passes and the SPF-authenticated domain aligns with the From: domain, OR
• DKIM passes and the DKIM signing domain aligns with the From: domain

If neither aligns, DMARC fails — and your policy determines what happens next.

Setting up email authentication: recommended order

1. Set up SPF first — List all your legitimate sending sources. End with -all.
2. Set up DKIM — Configure signing in your email platform. Publish the public key in DNS.
3. Set up DMARC at p=none with a reporting address — Collect data before enforcing.
4. Review aggregate reports — Confirm all legitimate senders are covered by SPF and DKIM.
5. Move to p=quarantine — Gradually (start with pct=10).
6. Move to p=reject — Full enforcement. Your domain is now spoofing-resistant.