Email Authentication for Fastmail: SPF, DKIM, DMARC Setup

15 May 2026 · 12 min read

Email authentication for Fastmail: SPF, DKIM and DMARC

Fastmail is one of the few independent mailbox providers that gives you a genuinely clean sending setup on your own domain. Outgoing mail is signed with DKIM keys that align to your domain by default, the SPF include is short and stable, and key rotation is handled for you through CNAME delegation. That combination means a Fastmail-hosted custom domain can reach p=reject without the alignment headaches you get with some big-tech providers.

This guide is specific to Fastmail. It covers the exact SPF include, the three DKIM CNAME records and what the fm1, fm2 and fm3 selectors actually do, how the return-path and From alignment behave when you send through Fastmail's servers, and the precise order of steps to move from p=none to enforcement without bouncing your own email. If you only want a plain-English overview of what DMARC is, read the DMARC requirements explainer first and come back here for the Fastmail mechanics.

What "email authentication" means in the Fastmail context

Three checks decide whether a receiver trusts mail claiming to be from your domain:

SPF verifies that the IP sending the message is allowed to use the domain in the SMTP envelope (the return-path / MAIL FROM).
DKIM verifies a cryptographic signature attached to the message, proving it was authorised by the signing domain and not altered in transit.
DMARC ties those checks back to the visible From: address. It passes only when SPF or DKIM passes and the passing domain aligns with the From: domain.

The word that matters most for Fastmail is alignment. SPF and DKIM can each pass on a domain that has nothing to do with your From: address, and that does you no good for DMARC. With Fastmail the good news is that DKIM alignment is the default and is rock solid, so you get a reliable path to DMARC pass even if SPF alignment is fiddly. We will come back to that.

If you want to see exactly what your domain publishes today, run it through the DMARC checker, the SPF checker and the DKIM checker before you change anything.

Two ways to run a domain on Fastmail

How you do DNS changes the work involved:

Fastmail hosts your DNS. You delegate the domain's nameservers to Fastmail. In this mode Fastmail writes the MX, SPF and DKIM records for you automatically and keeps them current. You barely touch DNS at all. You can still add a DMARC record yourself, and you should.
You host DNS elsewhere (Cloudflare, your registrar, Route 53, and so on). You add every record by hand. This is the common case for businesses that already manage their zone, and it is where the exact values below matter.

The records are identical either way. The difference is who types them. The rest of this guide assumes you are adding records manually, because that is where mistakes happen.

SPF for Fastmail: the exact include

Fastmail sends all of your outbound mail through its messagingengine.com infrastructure, so the SPF include is:

v=spf1 include:spf.messagingengine.com ~all

A few important specifics:

The include is spf.messagingengine.com. You will see some third-party guides quote _spf.fastmail.com. That is not the value Fastmail's own DNS instructions use. Use spf.messagingengine.com.
Use ~all, not ?all. Fastmail's automatically generated record historically used ?all (neutral), which tells receivers "I am not asserting anything about other senders". That gives you almost no SPF protection. Tighten it to ~all (softfail). Only move to -all (hardfail) once you are certain that every service sending as your domain is inside the record, because -all instructs receivers to treat anything else as a hard failure.
You may have only one SPF record per domain. This is the single most common SPF mistake. If you already send through, say, a marketing platform or a helpdesk, you do not add a second v=spf1 line. You merge the includes into one record:

v=spf1 include:spf.messagingengine.com include:servers.mcsv.net ~all

Watch the 10-lookup limit. SPF allows a maximum of 10 DNS lookups when it is evaluated. include:spf.messagingengine.com resolves to a small, well-behaved set, but if you stack several third-party includes you can blow the limit, at which point SPF returns permerror and effectively fails. If you are near the ceiling, flatten the record. Our SPF checker counts the lookups for you, and the hosted SPF product keeps a single flat record correct as upstreams change their IP ranges.

The host for the SPF record is the domain itself (the zone apex, often shown as @), as a TXT record.

DKIM for Fastmail: three CNAMEs and why there are three

This is where Fastmail's design is genuinely good. Instead of pasting a long public key into a TXT record that you have to rotate by hand, Fastmail uses CNAME delegation. You publish three CNAME records and Fastmail owns the keys behind them.

For a domain example.com, add these three CNAME records:

fm1._domainkey.example.com.  CNAME  fm1.example.com.dkim.fmhosted.com.
fm2._domainkey.example.com.  CNAME  fm2.example.com.dkim.fmhosted.com.
fm3._domainkey.example.com.  CNAME  fm3.example.com.dkim.fmhosted.com.

Read the structure carefully, because this is the part people get wrong:

The host (left side) is fmN._domainkey.yourdomain where fmN is the selector. So fm1._domainkey, fm2._domainkey, fm3._domainkey.
The target (right side) embeds your own domain: fmN.yourdomain.dkim.fmhosted.com. Note the yourdomain in the middle. A CNAME to fm1.dkim.fmhosted.com (without your domain) will not resolve to your key and DKIM will silently fail.
These are CNAMEs, not TXT records. If your DNS provider tries to wrap them in quotes or asks for a TXT value, you are in the wrong record type.

What the three selectors are for

Fastmail publishes three selectors so it can rotate signing keys without ever asking you to edit DNS again. At any moment one selector is the active signing key; the others let Fastmail roll to a fresh key transparently. Because the CNAMEs point at Fastmail-controlled hostnames, a rotation happens entirely on their side. You set these once and never touch them. This is why CNAME delegation beats a hand-pasted TXT key for a managed mailbox provider: there is nothing to expire.

The crucial alignment fact

When you send a message with a From: address on your custom domain, Fastmail signs the message with a DKIM signature using your domain (via these selectors). That means the DKIM signing domain (d=example.com) matches your From: domain, so DKIM alignment passes. Fastmail also adds a second signature on messagingengine.com for its own reputation, but it is the signature on your domain that earns DMARC alignment.

This is the single most reliable route to DMARC compliance on Fastmail. Even if SPF alignment is awkward (next section), aligned DKIM alone satisfies DMARC. Confirm a live message is actually signing on your domain with the DKIM checker using selector fm1, fm2 or fm3, and confirm real delivered mail by reading the Authentication-Results header in a received copy.

MX records (only if Fastmail handles your inbound mail)

If Fastmail is also your inbox, point MX at the Fastmail inbound servers:

example.com.  MX  10  in1-smtp.messagingengine.com.
example.com.  MX  20  in2-smtp.messagingengine.com.

MX has nothing to do with whether your outbound authentication passes, but it matters for one thing that catches people out: DMARC reports. Aggregate (RUA) reports are emailed to whatever address you put in your DMARC record, so that mailbox has to actually receive mail. If you are routing inbound away from Fastmail, make sure the reporting mailbox still works, or point reports at a dedicated analysis address.

Return-path, From alignment and the SPF nuance

Here is the part the brief specifically asks about, and the part most generic guides get wrong.

DKIM in Fastmail aligns to your domain by default. SPF alignment depends on the return-path.

When a receiver evaluates SPF, it checks the domain in the SMTP envelope return-path (MAIL FROM), not the visible From:. For DMARC to count an SPF pass, that return-path domain must align with the From: domain.

What this means in practice for Fastmail:

Sending a normal message from a Fastmail address on your custom domain (composed in Fastmail webmail or via Fastmail SMTP with your custom-domain identity): Fastmail uses your domain context, SPF passes against spf.messagingengine.com, and because DKIM is signed on your domain you get aligned authentication regardless. DMARC passes.
The return-path is where it can drift. For bounce handling, providers sometimes set the envelope return-path to a provider-owned domain (a messagingengine.com-style bounce address). When that happens, SPF still passes but it is not aligned with your From: domain, so it does not contribute to DMARC. This is normal and is not a problem on Fastmail, because the aligned DKIM signature carries DMARC on its own. DMARC needs only one of SPF-aligned or DKIM-aligned to pass, and Fastmail gives you DKIM-aligned reliably.

The practical takeaway: do not rely on SPF alignment as your DMARC pass on Fastmail. Rely on DKIM. Make sure the three CNAMEs are live and resolving, confirm signed mail in a real Authentication-Results header, and SPF alignment becomes a bonus rather than a requirement. If you control the sending such that the return-path is on your own domain, you will get SPF alignment too, which is belt and braces, but it is not the thing to chase first.

One more From-address subtlety: if you send "as" an external address through Fastmail (an identity on a domain you do not authenticate via Fastmail), DMARC for that domain will not pass through Fastmail's signing. Only domains for which you have published the Fastmail DKIM CNAMEs get aligned signatures. Keep your authenticated sending to domains you have actually set up.

Publishing DMARC and reaching enforcement

Now the policy itself. Fastmail does not publish a DMARC policy on your behalf for user domains, so this record is entirely yours to own. Start in monitor-only mode:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1;"

p=none means observe and report, change nothing about delivery. Nothing gets quarantined or rejected yet.
rua= is the address that receives the daily aggregate XML reports. Use a mailbox you actually read, or feed it into the DMARC report analyzer so you are not parsing XML by hand.
fo=1 asks receivers to generate failure reports when either SPF or DKIM fails alignment, which helps you find stray senders.

Generate a syntactically clean record with the DMARC generator if you would rather not hand-write it.

Why you start at none

p=none is not a destination, it is a measurement phase. The whole point of starting here is to discover every service that sends as your domain before you start blocking. With Fastmail this is usually a short list, but you might also have:

a CRM or marketing platform,
a helpdesk or ticketing tool,
transactional email from an app or e-commerce store,
a finance or invoicing system.

Each of those needs its own SPF include and ideally its own aligned DKIM signature, or it will fail DMARC once you enforce. The aggregate reports tell you who they are.

The progression to reject

Sit at p=none for two to four weeks of report data, then tighten in stages:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com;

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com;

v=DMARC1; p=reject; rua=mailto:dmarc@example.com;

Move to p=quarantine only once reports show your legitimate mail, Fastmail included, passing with alignment.
Use pct= to ramp gradually. pct=25 applies the policy to a quarter of failing mail so you can watch the effect before applying it to everything.
p=reject is the goal. At reject, anything failing DMARC for your domain is refused outright, which is what actually stops exact-domain spoofing.

A note on the alignment-mode tags aspf and adkim. The defaults are relaxed (r), which is correct for Fastmail and almost everyone. Relaxed alignment lets a subdomain in the authenticated domain align with the organisational domain in From:. Do not set adkim=s (strict) unless you are certain every signature exactly matches the From: domain, because strict mode rejects perfectly legitimate aligned mail that relaxed mode would accept. For a typical Fastmail setup, leave both relaxed.

Why DKIM-first matters for the journey

Because Fastmail's DKIM signature is aligned to your domain by default, the moment your three CNAMEs are live and verified you already have the strongest single requirement for DMARC pass in place. That is what makes Fastmail a comparatively low-risk provider to push to p=reject: you are not depending on a return-path quirk to carry alignment. Verify, then enforce.

A complete worked example

Here is the full set of records for example.com on Fastmail, hosting DNS elsewhere, sending and receiving through Fastmail, with one extra sender (a marketing platform) folded into SPF:

; Inbound mail
example.com.            MX     10  in1-smtp.messagingengine.com.
example.com.            MX     20  in2-smtp.messagingengine.com.

; SPF (Fastmail + one extra sender, single record, softfail)
example.com.            TXT    "v=spf1 include:spf.messagingengine.com include:servers.mcsv.net ~all"

; DKIM (three Fastmail CNAMEs)
fm1._domainkey.example.com.  CNAME  fm1.example.com.dkim.fmhosted.com.
fm2._domainkey.example.com.  CNAME  fm2.example.com.dkim.fmhosted.com.
fm3._domainkey.example.com.  CNAME  fm3.example.com.dkim.fmhosted.com.

; DMARC (start in monitor mode)
_dmarc.example.com.     TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1;"

Once you have validated everything and DMARC reports look clean, the only line that changes is the DMARC record, walked up through quarantine to p=reject.

Verification checklist

Work through these in order. Each has a tool so you are not guessing:

SPF resolves and is a single record with the messagingengine.com include and ~all. Check with the SPF checker and confirm the lookup count is under 10.
All three DKIM CNAMEs resolve. Query fm1._domainkey.example.com and confirm it chains through to fmhosted.com. Then send yourself a real message and confirm dkim=pass with d=example.com (not just d=messagingengine.com) in the DKIM checker and in the received Authentication-Results header.
DMARC record is published and parseable with a working rua mailbox, via the DMARC checker.
Aggregate reports show aligned pass for your Fastmail mail and every other legitimate sender. Feed the XML into the DMARC report analyzer.
Only then raise the policy.

If you also want encryption-in-transit hardening and a verified logo in inboxes once you are at enforcement, set up MTA-STS and BIMI afterwards. BIMI in particular requires p=quarantine or p=reject first, so it is a natural follow-on to this work.

Common Fastmail-specific mistakes

Wrong SPF include. Using _spf.fastmail.com instead of spf.messagingengine.com. Use the latter.
Leaving ?all in place. Fastmail's auto-generated record may use a neutral ?all that gives no protection. Change it to ~all.
A second SPF record. Adding a separate v=spf1 line for another sender instead of merging includes. Two SPF records is itself an SPF failure.
Dropping your domain out of the DKIM target. A CNAME to fm1.dkim.fmhosted.com instead of fm1.example.com.dkim.fmhosted.com. The middle segment must be your domain.
Only adding one or two DKIM CNAMEs. All three are needed so rotation never breaks signing.
Chasing SPF alignment. On Fastmail, DKIM is your aligned channel. If SPF is not aligned because of the bounce return-path, that is fine; verify DKIM and move on.
Jumping straight to p=reject before reports prove every legitimate sender aligns. Spend the monitoring weeks.

The takeaway

Fastmail gives you an unusually clean authentication setup: one stable SPF include (spf.messagingengine.com, softfailed with ~all), three CNAME-delegated DKIM selectors (fm1, fm2, fm3) that sign on your own domain and rotate themselves, and full freedom to publish your own DMARC policy. Because the DKIM signature aligns to your domain by default, you have a reliable path to p=reject that does not depend on the SPF return-path. Set the records, verify with real delivered mail, watch the aggregate reports, and walk the policy up in stages.

If you would rather not babysit DNS, parse XML, and time each policy step yourself, that is exactly what we do. The done-for-you DMARC service takes a Fastmail domain from p=none to p=reject safely, with continuous monitoring and change alerts so a future DNS edit never silently breaks your authentication. Start by running your domain through the DMARC checker and see where you stand today.

Email authentication for Fastmail: SPF, DKIM and DMARC