SPF, DKIM and DMARC explained: how inboxes trust mail

Email was designed for a smaller, more trusting network. The protocol that moves mail between servers lets a sender write any address in the From line, and nothing in the message itself proves that address is real. That is how a forged invoice can arrive looking like it came from your own domain.

Receivers close that gap with three checks, each published as a DNS record on the sending domain: SPF, DKIM and DMARC. Gmail and Yahoo have required all three from bulk senders since February 2024, and mail from a domain without them is more likely to land in spam or be refused.

What each record checks

Each one answers a different question, and none of them alone stops a forged From line. The sections below take them one at a time.

SPF: who may send for your domain

SPF is a TXT record on your domain that lists the servers allowed to send its mail. A record for a company that sends through one service looks like this:

example.com.  TXT  "v=spf1 include:_spf.example.net ~all"

include: pulls in the servers your email service publishes, and the all at the end says what to make of everyone else. ~all asks receivers to treat other servers as suspicious, and -all asks them to fail the check.

The catch is which address SPF looks at. It checks the envelope sender, the return address servers use for bounces (also called the Return-Path), not the From line people see in their inbox. A forger can pass SPF for a domain they own while showing yours in From, so SPF on its own does not stop the forged invoice. DMARC does, further down.

The ten-lookup limit

Every include, a, mx, ptr, exists and redirect in your record costs the receiver a DNS lookup, and the standard caps a single check at ten. A record that needs more fails with a permanent error, which most receivers treat as having no SPF at all. It is easy to cross once your marketing, billing and support tools each add their own include, so count again whenever you add a sender.

SPF also breaks when mail is forwarded, because the forwarding server is not on your list. That is one reason DMARC never relies on SPF alone.

Every mechanism, both lookup limits and the fixes for forwarding are in our guide What is SPF?

DKIM: a signature that travels with the message

DKIM signs each message with a private key held by the sending service and adds the signature in a DKIM-Signature header. Two tags in that header matter here: d= names the signing domain, and s= names the selector, which tells the receiver where to look up the public key.

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

The receiver fetches that key, checks the signature and learns two things: the domain in d= really signed the message, and the signed headers and body were not changed in transit. Because the signature travels inside the message, DKIM usually survives forwarding, which SPF does not.

Use 2048-bit keys, which the current standard recommends over the older 1024-bit minimum. Give every service that sends for you its own selector, so you can rotate or revoke one key without touching the others.

The signature itself, tag by tag, is in our guide What is DKIM?

DMARC: the policy that ties them together

DMARC adds the rule the other two are missing. A message passes DMARC only when SPF or DKIM passes and the domain it passed for matches the domain in the visible From line. That match is called alignment. It is relaxed by default, so mail.example.com aligns with example.com, and a strict setting asks for the exact same name.

The record lives at _dmarc on your domain:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

p= is the policy for mail that fails:

• none changes nothing about delivery and only asks for reports.
• quarantine asks receivers to treat failing mail as spam.
• reject asks them to refuse it outright.

rua= is where receivers send aggregate reports, usually one XML file a day from each large mailbox provider. Each report lists the servers that sent as your domain and whether their mail passed. Those reports are how you find the forgotten newsletter tool or the office printer that still sends as you, before a strict policy starts throwing their mail away.

A forged message can pass SPF and DKIM for the forger's own domain. Only DMARC asks whether those passes belong to the domain in From.

Alignment, the reports and every tag of the record are in our guide What is DMARC?

A safe order for turning it on

Moving straight to p=reject is the classic way to lose real mail. This order avoids it:

1. List every service that sends as your domain: your mailbox provider, your email API, and your newsletter, billing and help desk tools.
2. Publish SPF with each of them included, and turn on DKIM signing in every one.
3. Publish DMARC at p=none with an rua address, and read the reports for two to four weeks.
4. Fix every legitimate sender that fails, usually by adding its include or turning on its signing.
5. Move to p=quarantine, watch the reports for a few more weeks, then move to p=reject.

A domain that never sends mail is the exception. Publish v=spf1 -all and a DMARC record at p=reject straight away, so nobody can send in its name.

Where Nextmail fits

When you add a domain to Nextmail, the domain page lists every record to publish and checks each one against what public DNS answers, with the usual reason when a record does not match. If the domain has no DMARC record of its own, you get a starter record at p=none with a reporting address already filled in, to copy into your DNS or write with a sync. Moving the policy to quarantine or reject stays your decision, made on the domain's DMARC tab.

To look at a domain you already run, the deliverability checker reads its SPF, DKIM, DMARC, BIMI and MX records from live DNS, and the DMARC record generator builds the next record in the rollout. The steps for adding a domain are in Connect a domain, and the starter record is described in DMARC policy.