Guide

SPF, DKIM, and DMARC, explained without the jargon

Three DNS records that decide whether Gmail and Outlook trust mail claiming to be from your domain.

All three are DNS records — text entries attached to your domain, not settings inside your email client — that tell receiving mail servers whether an email claiming to be from your domain is legitimate. None of them affect what your email says; all three affect whether it’s believed.

SPF: who’s allowed to send

Sender Policy Framework lists which mail servers are authorized to send on your domain’s behalf — your own mail provider, plus any tool you’ve connected (a CRM, a sending platform). A receiving server checks the sending IP against this list; mail from an unlisted server looks forged, whether it actually is or not.

DKIM: a signature that proves nothing changed

DomainKeys Identified Mail attaches a cryptographic signature to each outgoing message, generated with a private key only your sending server holds. The receiving server checks it against a public key published in your DNS. If the message was altered in transit — or never actually came from your server — the signature won’t match.

DMARC: what to do when the first two disagree

Domain-based Message Authentication tells receivers what to do if SPF or DKIM fails: let it through anyway (none), quarantine it (usually spam), or reject it outright. It also tells receivers where to send aggregate reports about who’s sending mail claiming to be from your domain — including anyone spoofing it.

Why one missing record hurts everything

Gmail and Outlook both weigh authentication heavily when deciding inbox versus spam versus nowhere. Missing any one of the three makes your outbound mail look more suspect to them — regardless of how clean and verified your recipient list is. Deliverability is the product of both: authentication gets the message considered, list quality (see verifying before you send) keeps your domain’s reputation intact so the next message gets considered too.

Where the records actually live

All three are DNS TXT records (DKIM on a selector hostname, DMARC on _dmarc). They are not Gmail settings, not Instantly toggles, not "a checkbox in HubSpot." If your nameservers are at Cloudflare, you edit Cloudflare even when mailboxes are at Google.

Look up what you have today with the SPF / DKIM / DMARC checker. Draft missing SPF with the SPF generator. Draft a first DMARC with the DMARC generator. Click-by-click for twenty hosts is under /dns.

SPF, more carefully

SPF answers: "is this sending IP allowed to use this domain?" The receiving server takes the envelope sender (often the Return-Path, not always the From: you see), looks up TXT, and evaluates include: and ip4: mechanisms.

The famous failure modes:

Two SPF records. Merge them.
Too many DNS lookups. The spec caps the lookup graph. Old ESPs you forgot to remove are the usual cause.
Wrong domain. SPF on www does not protect @company.com.

~all vs -all: start with soft fail unless you are sure nothing legitimate sends from elsewhere.

DKIM, more carefully

Your sending host signs the message with a private key. DNS publishes the public key at selector._domainkey.domain. Receivers verify the signature.

If you rotate providers, you rotate keys. A leftover DKIM selector is harmless; a missing current selector is not. This site's checker probes common selectors. Custom ESP selectors may need a manual lookup.

DMARC, more carefully

DMARC requires alignment: SPF or DKIM must pass and line up with the visible From: domain (relaxed vs strict). Then p= says what to do on failure.

Start at p=none with rua= reports. Read them. Then quarantine. Then reject. Skipping to reject is how you filter your own invoice mail.

A week-one setup for a new outbound domain

Buy or pick a domain you will only send outbound from — not the corporate apex if you can avoid it.
Point MX if that domain must receive replies (it should).
Publish SPF for the actual sending hosts (Google, Microsoft, plus the sequencer).
Enable DKIM in that host.
Publish DMARC p=none.
Check the deliverability tool.
Warm up. Verify recipients first.

What these records do not fix

They do not verify Jane Doe's mailbox. They do not stop you hard-bouncing a guessed list. They do not replace a warmup. They are necessary and not sufficient — the other half is list quality.

Related glossary

SPF, DKIM, DMARC, MX record.

Check your records

Paste a sending domain. We look up SPF, DKIM and DMARC from live DNS — no account, no credits.