SPF, DKIM and DMARC: get your email out of spam

A practical guide to the three DNS records that decide whether business email reaches the inbox, with example records, tests and the mistakes I fix most.

If your invoices, order confirmations or newsletters land in spam, the cause is almost always the same: your domain isn't proving that the email really came from you. Three DNS records do that proving: SPF, DKIM and DMARC. I set these up across every domain I manage, from academic publishers to e-commerce stores. Here's how they work and how to get them right.

What each record does

• SPF (Sender Policy Framework) lists which servers are allowed to send email for your domain.
• DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message, so receivers can check it wasn't forged or changed.
• DMARC tells receivers what to do when a message fails SPF or DKIM, and sends you reports about who is sending as your domain.

Since 2024, Google and Yahoo require all three for bulk senders. Even small senders get far better inbox placement with them in place.

SPF: one record, every sender

SPF is a single TXT record on your root domain. Include every service that sends as you: your mailbox provider, your email marketing tool and your transactional mail service.

example.com.  TXT  "v=spf1 include:_spf.google.com include:mailgun.org ~all"

• Only one SPF record per domain. Two SPF records means both fail. Merge them into one.
• SPF allows a maximum of 10 DNS lookups. Too many include: entries will break it silently.
• Start with ~all (soft fail). Move to -all once you're sure every sender is listed.

DKIM: let each platform sign your mail

Each sending platform (Google Workspace, Brevo, Mailchimp, Moosend, Mailgun) generates its own DKIM key. You publish it as a TXT or CNAME record under a selector:

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The most common gap I find: the mailbox is signed, but the email marketing platform was never authenticated. Every tool you send campaigns from needs its own domain authentication step completed.

DMARC: start gently, then enforce

DMARC lives at _dmarc on your domain. Begin in monitoring mode so nothing gets blocked while you learn who sends as you:

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

Read the reports for a few weeks, fix any legitimate senders that fail, then tighten to p=quarantine and finally p=reject. Jumping straight to reject is how businesses accidentally block their own invoices.

Don't forget the website's own email

WordPress and WooCommerce often send through PHP's basic mail function from the web server. That's unauthenticated and regularly lands in spam. The fix is to send site email through proper SMTP (your mailbox provider, Mailgun or Brevo), from a real address on your domain covered by SPF and DKIM.

How to test it

1. Check the records from a terminal: dig +short TXT example.com and dig +short TXT _dmarc.example.com.
2. Send a message to a Gmail account, open it and choose Show original. You want SPF: PASS, DKIM: PASS, DMARC: PASS.
3. Use a mail-testing service to score a sample message and flag missing records.

The mistakes I fix most often

• Two SPF records, or an SPF record with more than 10 lookups.
• Marketing platforms sending without their DKIM being set up.
• DMARC set straight to p=reject before reports were checked.
• Mail-related DNS records proxied through a CDN. MX records and mail hostnames should be DNS-only.
• Website forms sending from the web server instead of authenticated SMTP.

If your email is landing in spam, send me your domain and I'll tell you exactly which record is missing. See also my email deliverability service.