Email authentication
Fastmail setup checker
Compare a domain’s MX, SPF and all three DKIM CNAMEs with the exact values Fastmail documents.
Free, no accountLive check
Result
The verdict appears here once you press Check Fastmail records.
What this is
This fastmail setup checker reads what a domain publishes and lines it up against the values on Fastmail’s own manual DNS page - and because every one of those values is computable from the domain itself, each row comes back exactly right or exactly wrong rather than merely present.
Fastmail is the unusual mail host whose whole record set can be worked out from the domain name: two fixed mail servers, one fixed SPF include, and three DKIM CNAME targets with the domain embedded in the middle of each. Nothing is minted per account, so there is no dashboard value to copy and no part of the set that has to be taken on trust.
That is why this check does not stop at “a DKIM record is there”. A CNAME at fm2._domainkey pointing at another domain’s target, at a half-edited hostname, or at something left behind by a previous Fastmail domain resolves perfectly well and still verifies no signature for the domain it sits under. Comparing the target against the computed one is the only thing that catches it.
How to read the result
The table pairs each of the six documented values with what the domain actually answers, and marks every row exactly right, exactly wrong, or nothing published. A row that is wrong carries the value that belongs there, ready to paste over whatever is live.
Underneath, SPF, DKIM and DMARC go through the same full checks their own tools run, so a record that matches Fastmail precisely and still has a fault of its own - a weak key, two SPF records at once, no DMARC policy at all - is reported rather than waved through on the strength of matching.
This checker only covers Fastmail’s own fixed SPF include and three DKIM CNAMEs. For how SPF, DKIM and DMARC fit together, what order to fix them in, and what to do once one fails, see our guide How SPF, DKIM and DMARC work together, and what to do when one fails.
Common mistakes
What goes wrong most often, and how to tell.
- Carrying a DKIM CNAME over from another domainThe three targets differ only by the domain embedded in them, which is what makes a copied one easy to miss: fm1.olddomain.com.dkim.fmhosted.com sitting at fm1._domainkey.newdomain.com has the shape of a correct Fastmail record and authenticates nothing for the domain it is published under.
- Reading “the CNAME resolves” as “DKIM works”A CNAME pointing at any hostname that exists will resolve, and a lookup through it may even return a key. The signature a receiver checks is the one made for this domain’s selector, so the target has to be this domain’s computed target rather than any target that happens to answer.
- Publishing the two MX records at the wrong prioritiesFastmail documents in1-smtp at 10 and in2-smtp at 20. Swapping them, or giving both the same number, leaves delivery working often enough to look fine while sending a share of the mail to the server meant to be second in line.
- Leaving a previous host’s MX record alongside Fastmail’sAn extra MX record is not ignored - it is another place mail can legitimately be delivered. A forgotten record from the host the domain used before Fastmail quietly keeps receiving some of it, which is why this check expects those two records and nothing else.
Questions
What people ask about this tool.
- Because every value Fastmail documents can be computed from the domain name, so there is one correct answer for each of them. A record that exists but does not match that answer is not a half-finished setup - it is a record that cannot do its job, and calling it “present” would hide exactly that.
- Yes. Fastmail signs outgoing mail with whichever of the three selectors it is rotating through, so a message can arrive signed under any one of them. If the matching CNAME is not published, that message’s signature has nothing in DNS to be checked against.
- No. Everything on this page comes from public DNS, while Fastmail’s own verification state lives in your account. A domain whose six records are all exactly right can still be sitting unverified in Fastmail’s settings, which is the one thing a DNS check can never see.
- That is the qualifier on Fastmail’s own page, and a neutral one: it takes no position on senders the record does not list. This page reports what you publish against that honestly, so matching Fastmail is marked as matching and the separate question of strictness is raised by the SPF check below.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- Fastmail, “Manual DNS configuration” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.