SPF, DKIM and DMARC: your domain sends mail whether you do or not

Why every website domain needs email authentication records, how SPF, DKIM and DMARC fit together, and how to roll out a reject policy without losing your own mail.

Infrastructure · Published: 30 September 2026 · 6 min read · Анна Ковалёва

"We don't send email" is one of the most common answers when a scan flags a missing SPF or DMARC record. It is also beside the point. Anyone on the internet can put your domain in the From line of a message. The only thing that decides whether Gmail or Outlook believes it is a handful of TXT records in your DNS — and if they are missing, nobody is speaking for your domain.

Why a website owner should care

Spoofing and phishing. Without a DMARC policy, receiving servers have no instruction from you about what to do with mail that claims to be from your domain and fails checks. Fake invoices and "password reset" messages from support@yourdomain are cheap to send and damage trust in the real site.

Your own notifications. Contact forms, order confirmations, password resets — even a "static" site usually sends something. A form handler that calls PHP mail() from the web server, with the visitor's address in From, fails every check and lands in spam or nowhere at all.

Mailbox provider requirements. Since February 2024 Gmail and Yahoo require all senders to have SPF or DKIM, and bulk senders to have both, plus a DMARC record (p=none is the minimum) and a From domain aligned with one of them. Other providers have been moving the same way. Mail that does not meet the rules is increasingly rejected, not just filtered.

SPF: who may send

SPF is a TXT record on the domain itself listing the servers allowed to send for it:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Rules that trip people up:

• One record only. Two TXT records starting with v=spf1 is not "both apply" — it is a permanent error, and receivers treat SPF as broken. Merge them into one.
• Ten DNS lookups. include, a, mx, exists, redirect and ptr each cost a lookup, and nested includes count too. Past ten, evaluation fails. Remove services you no longer use before adding new ones.
• The ending matters. -all says everything else fails; ~all is a soft fail, a reasonable setting while you are still inventorying senders; +all authorises the entire internet and is worse than having no record.

SPF checks the envelope sender (the bounce address), not the From header the user sees. That is why it is not enough on its own.

DKIM: a signature on every message

DKIM signs outgoing mail with a private key; the public key is published in DNS under a selector:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Each sending service — your mailbox provider, the newsletter tool, the transactional mail API — gives you its own selector and key, or a CNAME pointing to one it manages. Use 2048-bit RSA keys where the provider allows, and remove selectors for services you have dropped. Unlike SPF, a DKIM signature survives forwarding, which makes it the more reliable of the two.

DMARC: the policy that ties them together

DMARC lives at _dmarc and tells receivers what to do when a message fails, and where to send reports:

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

A message passes DMARC when SPF or DKIM passes and the domain it passed for is aligned with the domain in From. SPF passing for your email provider's bounce domain does not count; a DKIM signature with d=example.com does.

Roll it out in stages:

1. p=none with rua reports. Nothing is blocked; you get daily aggregate XML reports showing every server sending as your domain. Use a report parser or service rather than reading XML by hand.
2. Fix every legitimate sender that fails: add it to SPF, set up DKIM, make sure From uses your domain.
3. p=quarantine, optionally with pct= to apply it to a share of failing mail first.
4. p=reject. Spoofed mail is refused at the door.

p=none is a monitoring mode, not protection. Staying there for years means you collected the data and never acted on it.

Domains that send no mail

Parked domains, redirect-only domains and old brand names are favourite spoofing targets because nobody watches them. Close them completely:

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject"

A null MX record (example.net. MX 0 .) additionally tells other servers the domain does not accept mail.

How to check

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT s1._domainkey.example.com

The first should return exactly one v=spf1 string. For DKIM you need the selector: open a message you sent, look at the DKIM-Signature header and take the value of s=. The Authentication-Results header of a received message shows SPF, DKIM and DMARC verdicts in one place.

A SiteScan report checks the DNS side for you: it flags a missing SPF record, multiple SPF records, an overly permissive +all, a missing DMARC record and a DMARC policy left at p=none. It does not check DKIM — selectors cannot be discovered from DNS without knowing their names — so verify that with a real message.

Check-list

1. Exactly one SPF record, under ten lookups, ending in ~all or -all.
2. DKIM is set up for every service that sends as your domain.
3. Site notifications go through an authenticated provider, From your domain, with the visitor in Reply-To.
4. DMARC exists with rua reports and is moving from p=none towards p=reject.
5. Domains that send no mail have v=spf1 -all and p=reject.