To authenticate a custom domain in Fastmail, add the domain to your account, publish its three DKIM CNAME records, and include spf.messagingengine.com in the domain's single SPF TXT record. Keep any established DMARC policy. Then check public DNS and a message delivered through Fastmail. Moving your nameservers or incoming mail is a separate decision. Fastmail manual DNS reference.
Choose the right domain setup
This guide covers custom-domain mail sent through Fastmail, including webmail and clients submitting through Fastmail. It does not configure another provider merely because you read that provider's mail inside Fastmail. You need account-administrator access; Fastmail says at least one account administrator must have a non-Basic subscription to use custom domains. Check legacy-plan entitlements before planning a migration. Custom-domain requirements.
Decide which of these arrangements you actually want:
- Fastmail hosts DNS: Fastmail manages its authentication records automatically. Review the existing zone before delegating nameservers; a careless move can disconnect a website or other services.
- DNS stays elsewhere, incoming mail moves to Fastmail: Publish authentication at the existing DNS host. Treat the MX migration as a separate, coordinated change.
- Neither nameservers nor MX point to Fastmail: A filtering gateway may deliver onward to Fastmail. Use the documented no-NS/MX route rather than changing working inbound routing just to clear a warning.
The third arrangement can remain Inactive in Fastmail even when deliberately configured. That status alone cannot diagnose outgoing authentication. Fastmail's no-NS/MX instructions.
Before editing, record the intended From address, current nameservers, existing SPF and DMARC, every sending service, and the person who can restore DNS. Save an export or exact previous values. A record visible in a registrar's panel has no effect if another company serves the authoritative zone.
Get the domain-specific instructions
In Settings → Domains, choose Add or buy domain → Use a domain you already own. Enter the domain and follow the setup prompts. For an existing domain, open it and select Get instructions. Use the instructions for your chosen arrangement, not every record in a generic DNS reference. Fastmail MX-only setup.
For example, a request to authenticate example.com does not authorize replacing the website's www CNAME or its MX records. Likewise, adding team.example.com as a sender requires examining that specific name. Do not assume authentication records at the parent automatically cover a separately configured sending subdomain.
Ensure the address you intend to use exists in Fastmail's address settings. Authentication verifies a domain's use on messages; it does not create a mailbox, alias, or receiving route by itself. Keep account access, address provisioning and DNS publication as distinct checklist items so the right administrator handles each.
Publish all three Fastmail DKIM CNAMEs
For the illustrative domain example.com, Fastmail's current pattern is:
fm1._domainkey.example.com— CNAME tofm1.example.com.dkim.fmhosted.com.fm2._domainkey.example.com— CNAME tofm2.example.com.dkim.fmhosted.com.fm3._domainkey.example.com— CNAME tofm3.example.com.dkim.fmhosted.com.
Replace the example domain with yours and compare every target with the account instructions. Publish all three, not only the selector observed in one message. The older mesmtp selector is marked deprecated for pre-2018 configurations; do not substitute it for the current set or remove an existing key before checking its use. Current and legacy selector reference.
If the editor automatically appends example.com, enter fm1._domainkey in its name field. If it requires a full owner name, use the complete name. Preview the saved result: fm1._domainkey.example.com.example.com is wrong. A CNAME target is a hostname, not a URL; do not add https:// or a path.
For an issued signing domain such as news.example.com, a full owner fm1._domainkey.news.example.com is fm1._domainkey.news relative to the parent example.com zone, or fm1._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is fm1. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names. Apply the same placement rules to fm2 and fm3, with their distinct issued targets.
Do not put a TXT key, an A record or another CNAME at the same owner. Investigate an existing conflict before replacing it. Other providers' selectors can coexist at different names. Fastmail holds the private signing keys; an unrelated DKIM generator cannot supply matching keys for this hosted service.
On Cloudflare, Fastmail specifically instructs customers not to flatten these CNAMEs. Check each record's Flatten setting and any zone-wide flattening configuration. Keep authentication CNAMEs DNS-only, not behind an HTTP proxy. Review broader setting changes with the DNS owner rather than modifying unrelated website behavior. Fastmail's Cloudflare procedure.
For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.
Add Fastmail to the existing SPF policy
Fastmail documents this standalone example at the domain apex, as type TXT:
v=spf1 include:spf.messagingengine.com ?all
If SPF already exists, add the Fastmail include to that policy before its final all, preserving legitimate senders and the existing policy decision. Do not publish a second v=spf1 record. The documented ?all means unmatched senders receive a neutral result; it does not make authorized Fastmail matches neutral or disable SPF. Do not change an established -all or ~all just to copy an example. SPF setup and combining records.
SPF evaluates the SMTP envelope sender, not automatically the address displayed in From. Its maximum is 10 evaluated DNS-lookup-causing mechanisms and modifiers, including nested includes and redirects, not ten vendors or ten TXT strings. Check the complete evaluation path before adding another authorization. Splitting one policy across several TXT strings does not reset that budget. SPF specification.
If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.
A domain can have unrelated TXT verification records; only multiple SPF policies at the same owner are the problem. If another team manages a hosted SPF service, have that team add Fastmail through its existing management process rather than replacing the published record.
Keep the existing DMARC protection
Look up TXT at _dmarc.example.com. For a From domain such as team.example.com, also examine _dmarc.team.example.com and the applicable parent policy. An absent subdomain record is not proof of no policy. Preserve reporting destinations, alignment settings and inherited protection; adding a local p=none record can weaken an existing parent policy.
DMARC passes when either SPF passes and aligns, or a valid DKIM signature aligns with the visible From domain. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. RFC 9989 replaces RFC 7489 and removes the former pct tag. Do not use percentage sampling as the rollout mechanism. Current DMARC specification.
Only where no established direct or inherited policy applies should you consider a new monitoring policy, with an approved report destination and a plan to review legitimate senders before enforcement. A vendor's example p=none is not an instruction to downgrade a protected domain.
For that first-time case only, publish one TXT record at _dmarc.example.com with the minimal value v=DMARC1; p=none. Use _dmarc in an editor that appends example.com, or the full owner where required. This minimal record requests no reports. For monitoring, append ; rua=mailto:YOUR-APPROVED-REPORT-ADDRESS, replacing the placeholder with the real approved destination before saving. An external report domain may require its owner to publish reporting authorization. Follow RFC 9990 reporting requirements. Edit an existing applicable policy instead of creating a duplicate. Requery the TXT owner after saving and confirm the intended value, then review real-message results.
Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.
For a separately approved first policy for From team.example.com, the full TXT owner is _dmarc.team.example.com: use _dmarc.team in the parent example.com zone or _dmarc in a separately delegated team.example.com zone. Preserve any applicable inherited policy instead of creating a monitoring override.
Verify DNS and a delivered Fastmail message
Replace example.com below. These are reader-side checks, not results from a test performed for this article:
dig +short NS example.com
dig +short TXT example.com
dig +short CNAME fm1._domainkey.example.com
dig +short CNAME fm2._domainkey.example.com
dig +short CNAME fm3._domainkey.example.com
dig +short TXT fm1.example.com.dkim.fmhosted.com
dig +short TXT _dmarc.example.com
Expect one SPF policy and three exact CNAME targets. Resolve the TXT public key behind each target, repeating the last DKIM query for fm2 and fm3. Empty output is not a pass. Compare the authoritative nameserver's answers with public recursive resolvers when caches disagree. Record the owner, type, answer and time, not just a screenshot saying “DNS updated.”
Return to Settings → Domains and use Recheck DNS where available. Fastmail documents this check for its Cloudflare/MX arrangement. Do not apply that arrangement's expected Active status to the intentional no-NS/MX exception.
Next send from each real custom-domain workflow to a controlled external mailbox. Fastmail documents an outbound messagingengine.com signature and, when possible, an additional signature for the sending address's domain. A passing provider-domain signature alone does not establish alignment for your custom From domain. Fastmail message processing.
In the received source, inspect the receiving service's trusted Authentication-Results: SPF result and smtp.mailfrom; DKIM result, signing header.d and selector; DMARC result and header.from. Match these against the actual From and DKIM-Signature fields. Do not trust an arbitrary sender-inserted header with that name. Require a valid aligned result, not merely the presence of a signature. Authentication-Results trust boundaries.
Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.
Complete this branded-DKIM setup only when the intended provider signature has trusted dkim=pass, its actual d= aligns with the intended visible From under the effective adkim mode, and the trusted receiver reports dmarc=pass for that From. DMARC success through SPF alone does not establish that this DKIM deployment works; neither does an unnoticed provider-domain From rewrite. Diagnose SPF independently at the actual smtp.mailfrom: fail or softfail calls for checking sender authorization, temperror indicates a transient evaluation failure such as DNS availability, and permerror calls for checking invalid syntax, duplicate policies and lookup limits. Investigate these even if aligned DKIM supplies DMARC pass; a passing but unaligned provider envelope is a different outcome. DMARC alignment, SPF result meanings.
Troubleshoot the failing layer
Fastmail says Needs attention: Reopen Get instructions and compare the complete saved owner and target for each selector. If DNS is external, fixing only Fastmail's local view will not publish the record. Fastmail DKIM troubleshooting.
Only one selector resolves: Complete the full delegation set. A single successfully signed message tests the key used for that message, not the readiness of every configured selector.
DNS looks right but DKIM fails: Confirm the actual outbound service, then compare a direct message with one forwarded through a gateway. A message modified after signing can fail even when its public key is correct. Preserve the original source for diagnosis rather than repeatedly rotating DNS values.
SPF passes but DMARC fails: Compare domains. A pass for a different envelope identity does not authenticate your visible From. Check whether a custom-domain DKIM signature is present and valid.
Authentication passes but mail reaches spam: Investigate the recipient response, sender reputation and message practices separately. Passing authentication does not guarantee acceptance or inbox placement.