SPF, DKIM and DMARC: how to check whether your domain’s email is authenticated (and fix it)

You have a domain, perhaps for your practice or small business, and some emails land in customers’ spam or bounce with an error about “authentication”. In the vast majority of cases the cause is one of the three DNS records that tell the world who may send on your behalf: SPF, DKIM and DMARC. Since February 2024 Gmail explicitly requires them, as its sender guidelines explain. This article shows how to read them, how to tell what is wrong and how to fix them without blocking your own mail.

What each record does

Record	Where it lives	What it says	What the receiver checks
SPF	TXT on the domain, e.g. example.com	Which servers may send for that domain	The IP address of the server delivering the message
DKIM	TXT on selector._domainkey.example.com	The public key used to verify the signature	That the message was not altered and is signed by the domain
DMARC	TXT on _dmarc.example.com	What to do if SPF and DKIM fail, and where to send reports	That at least one of the two passes and is aligned with the visible sender domain

The key concept is alignment. It is not enough for SPF or DKIM to pass: the verified domain must match the one the recipient sees in the “From:” field. A newsletter sent through an external service may pass SPF with the service’s domain but fail DMARC because that domain is not yours.

What Gmail requires

• All senders: SPF or DKIM, valid forward and reverse DNS (PTR) for sending servers, a TLS connection, reported spam rate below 0.3%.
• Senders of more than 5,000 messages a day to Gmail: SPF and DKIM, a published DMARC record (even just p=none), alignment of the “From:” domain, one-click unsubscribe for promotional messages.
• DKIM keys must be at least 1024 bits; Google recommends 2048.

Even if you send few emails, it pays to meet the stricter requirements: they decide whether you reach the inbox or spam with other providers too.

How to read the records from your PC

On Windows open Command Prompt; on Mac and Linux, Terminal. Replace example.com with your domain.

What	Windows	Mac and Linux
SPF	nslookup -type=txt example.com	dig +short TXT example.com
DMARC	nslookup -type=txt _dmarc.example.com	dig +short TXT _dmarc.example.com
DKIM	nslookup -type=txt selector._domainkey.example.com	dig +short TXT selector._domainkey.example.com
MX	nslookup -type=mx example.com	dig +short MX example.com

You cannot guess the DKIM selector: find it in your mail provider’s panel or in the header of a message you sent, in the DKIM-Signature field, after s=. To see a domain’s mail records and servers without the command line you can also use our DNS and email diagnostics, which shows the values actually observed and the source of each one.

Reading an SPF record

A typical example: v=spf1 include:_spf.google.com include:spf.newsletter-provider.com ip4:203.0.113.10 -all

• include: authorises another service’s servers (your mail provider, newsletter platform, the accounting software that sends invoices).
• ip4: and ip6: authorise specific addresses, such as your web server.
• mx and a authorise the servers listed in the domain’s MX and A records.
• At the end: -all rejects everything else, ~all marks it as suspicious. +all authorises anyone: never use it.

Two rules in the standard (RFC 7208) cause most problems: there must be only one SPF record per domain, and evaluation may not require more than 10 DNS lookups (every include, a and mx counts, including those nested inside includes). Above the limit the result is a permanent error and SPF fails for everyone.

Reading a DMARC record

Example: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

Field	Meaning	Values
p	What to do with failing messages	none (reports only), quarantine (spam), reject
rua	Where to receive daily aggregate reports	A dedicated mailbox
adkim, aspf	Relaxed or strict alignment	r accepts subdomains, s requires the exact domain
sp	Policy for subdomains	If missing, p applies

The most common mistakes

1. Two SPF records: happens when a new service is added by creating a new record instead of merging the include into the existing one.
2. Too many includes: more than 10 DNS lookups. Remove services you no longer use and, where possible, replace includes with your server’s ip4 addresses.
3. The website sending unauthorised email: contact forms, orders and notifications leave from the web server. Either authorise it in SPF or, better, route the site’s mail through an SMTP service with DKIM on your domain.
4. DKIM not switched on at the provider: many offer it but leave it off until you publish the CNAME or TXT record shown in the panel.
5. DMARC set straight to reject without reading the reports: legitimate mail from a forgotten service gets rejected.
6. Records with wrong characters: curly quotes, extra spaces, a DKIM record split badly into several strings by the registrar’s panel.

The safe path to p=reject

Phase	DMARC record	Duration	What to do
1. Observe	p=none; rua=mailto:...	2–4 weeks	Read the reports: which services send for your domain, which fail
2. Fix	p=none	As long as needed	Authorise in SPF or enable DKIM on every legitimate service
3. Quarantine	p=quarantine	2–4 weeks	Check that no legitimate mail ends up in spam
4. Reject	p=reject	Permanent	Anyone spoofing your domain is turned away

Aggregate reports are compressed XML files: free analysis services exist to read them, or open-source tools you can install on your own server. Use a dedicated mailbox, because dozens will arrive every day.

Final check: send yourself an email

Send a message from your domain to a Gmail address, open it and choose More > Show original. At the top Gmail shows the SPF, DKIM and DMARC results: all three must be PASS. Repeat the test from every service that sends on your behalf: the website, the accounting software, the newsletter platform.

Checklist

• One SPF record, listing every service that really sends, with fewer than 10 DNS lookups.
• DKIM active on every service, with a 2048-bit key where possible.
• DMARC published, with a mailbox for reports.
• A gradual move from p=none to p=reject.
• If the domain never sends email, protect it anyway: v=spf1 -all and v=DMARC1; p=reject.

Sources

• Google, Email sender guidelines.
• IETF, RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC).

Questo articolo è disponibile anche in italiano: leggi la versione italiana.