DKIM, DMARC, and SPF: Getting Email Deliverability Right in 2026

If your business emails keep landing in spam, the cause is rarely your content — it's your DNS. Gmail and Microsoft now effectively require authenticated email, and unauthenticated mail gets filtered or rejected outright. Three records fix it.

SPF: who may send for your domain

An SPF record lists the servers allowed to send mail as your domain. It lives in DNS as TXT:

v=spf1 a mx include:yourmailprovider.com -all

Common mistakes: multiple SPF records (only one is allowed — merge them), exceeding the 10-DNS-lookup limit by stacking includes, and ending with ?all (which politely asks filters to ignore the whole record).

DKIM: proof the message wasn't altered

DKIM cryptographically signs each outgoing message; receivers verify the signature against a public key in your DNS. Your mail server or provider generates the key pair — you publish the public half as a TXT record like selector._domainkey.yourdomain.com. Use 2048-bit keys, and rotate them when staff with mail-server access leave.

DMARC: the policy that ties it together

DMARC tells receivers what to do when SPF/DKIM fail — and sends you reports about who's sending as you:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100

Start at p=none to collect reports without breaking anything, review for a couple of weeks (you'll often discover forgotten systems sending legitimate mail), then move to quarantine and finally reject.

Verify your work

Send a message to a Gmail address, open it, and choose Show original — you want three green PASS results. Free checkers like MXToolbox will audit the records themselves.

On our hosting plans these records are configured correctly out of the box, because deliverability problems are miserable to debug after the fact. Wherever you host, spend the twenty minutes — the spam folder is no place for an invoice.