SPF record for Fastmail

Fastmail sends mail for your users on your own domain. Here is what to publish so it can do that as your domain, and what has to line up before DMARC will pass.

The SPF record

Add one mechanism to the SPF record on your sending domain:

In a complete record, alongside Google Workspace, that looks like:

Fastmail prints the whole record on its manual DNS page as v=spf1 include:spf.messagingengine.com ?all, and when I checked on 2026-09-04 that was still the published value. Take the include from it. Decide the ending separately.

?all is the neutral qualifier: it authorises Fastmail and asks receivers to do nothing about anybody else, so a forged message from any other address gets a neutral result too. If Fastmail carries all the mail for the domain, publish -all.

Then count your lookups. SPF allows ten DNS-querying mechanisms across the entire nested chain, and the eleventh turns the record into a permerror that authorises nothing. The record still reads correctly to a human while every check fails. Run the domain through the SPF checker after every change, because the number moves when your providers change their own records, not just when you change yours.

DKIM

Three CNAMEs, and Fastmail's page says to add all three:

Your domain appears twice in every target, once as the host and once in front of dkim.fmhosted.com. Fastmail holds the keys and rotates between the three, which is why two of them is not enough.

Domains hosted at Fastmail before 2018 also carry mesmtp._domainkey, which Fastmail's page marks deprecated. Leave it where it is unless Fastmail tells you to remove it.

DMARC alignment with Fastmail

DMARC passes when SPF or DKIM passes and the domain it authenticated matches the domain in your visible From address. A provider can pass both checks for its own domain and leave you failing. These are the Fastmail specifics:

• Mail your users send carries your domain in the envelope sender and in the signature, so SPF and DKIM both align without any extra work. Fastmail is one of the straightforward cases.
• An app or a device sending through Fastmail's SMTP with an app password is covered by the same records. One sending through your web host is not, and its addresses have to go in the record separately.
• A neutral ?all ending is not an SPF pass. DMARC needs a pass that aligns, so a record that ends there leaves DKIM as the only mechanism that can align.

The general case is covered in alignment, explained, and the header you read to prove it is on the dmarc=fail page.

Verify it

Substitute your domain, and run these after the TTL on anything you replaced has expired:

Then send one message through Fastmail to a Gmail address you control, open Show original, and look for dkim=pass with your domain in header.i. That single check is worth more than any number of DNS lookups, because it tests the thing receivers actually do.

Our SPF checker gives you the lookup count, the DKIM checker confirms a selector resolves and the key is long enough, and the DMARC checker reads your policy back to you. All three are free and none of them ask for an account.

Values here were checked against Fastmail's own documentation, at Fastmail help centre. Providers change DNS requirements without much announcement, so if their screen disagrees with this page, believe their screen and tell us.

A record can read correctly and still fail alignment once real mail moves through it. Receivers write that verdict into the reports they send. We read them for you, and paid plans email you the same day one names a new sender that failed, instead of holding it for Monday. See whether this sender passes. Your first domain is free.