Deliverability guide

SPF, DKIM and DMARC setup

Why use this

These three records are how a receiving mail server decides whether a message claiming to come from your domain really did. Get them wrong and your mail is filtered on arrival; get them right and you have done most of what is in your control about deliverability.

For example

Your password reset emails land in spam for every Gmail user, and nothing in your application logs says why — because the rejection happened at the receiving end, on evidence your app never sees.

What each one actually proves

SPF is a list of servers permitted to send for your domain, published as a TXT record. A receiver checks the connecting server against the list. It proves something about the connection, not about the message — and it breaks on forwarding, because the forwarding server is not on your list.

DKIM is a cryptographic signature over the message itself. Your sending platform signs with a private key; the receiver fetches the public key from a DNS record and verifies. It proves the message was authorised by whoever holds the key and has not been altered in transit, and unlike SPF it survives forwarding.

DMARC ties the other two to the domain a human actually sees. It is published at _dmarc.yourdomain.com and does two things: it tells receivers what to do with mail that fails, and it asks them to send you reports about mail claiming to be from you.

Alignment is the part that catches people

DMARC does not ask "did SPF or DKIM pass?". It asks whether either passed for the same domain the reader sees in the From header. That is alignment, and it is where a setup that looks correct still fails.

The classic case: your provider sends with its own return-path domain, so SPF passes — but it passes for their domain, not yours. SPF is valid and unaligned, which contributes nothing to DMARC. DKIM signed with a key published under your domain is aligned, and one aligned mechanism is enough. That is why DKIM is the one to get right first.

This is not hypothetical for us. Mail sent through this platform uses Amazon SES's default return path, so its SPF is valid and unaligned; DMARC passes on DKIM alignment, using keys published under your domain when you verify it.

Publish the records

Verify your domain and you are given the exact DKIM records to add — three CNAMEs, each pointing a selector at a key held by the sending infrastructure. Because they are CNAMEs, key rotation happens without you touching DNS again.

The one record nobody hands you is DMARC, because it is a policy decision rather than a piece of plumbing. Start in monitor mode:

# Start here. Monitor only: nothing is rejected, you just find out.
v=DMARC1; p=none; rua=mailto:dmarc-reports@acme.com

p=none changes nothing about how your mail is treated. It turns reporting on, which is the point: you will discover the systems sending as you that you had forgotten — the CRM, the ticketing tool, the server that sends cron failures. Tighten only once those are accounted for.

# Once the reports are clean, and not before.
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@acme.com

Going straight to p=reject on a domain you have not monitored is the fastest way to stop your own invoices reaching customers. Almost every organisation has at least one forgotten sender.

Check what actually resolves

Publishing a record and having the world see it are different events, separated by your DNS provider's propagation. Check from outside your own network:

# What the world can see for your domain
dig +short TXT acme.com                 # SPF lives here, on the apex
dig +short TXT _dmarc.acme.com          # DMARC policy
dig +short CNAME abc123._domainkey.acme.com   # a DKIM selector

Two failure modes worth knowing. Some registrars append the domain to whatever you type, so pasting a fully-qualified name produces selector._domainkey.acme.com.acme.com — the single most common reason a domain never verifies. And you may publish only one SPF record: two TXT records both starting v=spf1 is a permanent error, and the fix is to merge them into one with multiple include: terms.

What this platform checks for you

Domain verification polls the records and shows which are live, so you are not guessing at propagation. DMARC presence is checked too, but advisory only — a missing DMARC record never blocks verification, because it is your policy to set, not ours.

Verification is also not a one-way door. A verified domain is re-checked daily, and if a record disappears months later you are emailed rather than left with a green badge and silently failing mail. The full setup walkthrough is in Domains & DNS.