Separate authentication from a mail migration
Fastmail's domain wizard can change more than outgoing authentication. Its website question influences whether it recommends changing only MX records or moving nameservers. Before beginning, decide whether you are migrating inbound mail, delegating DNS administration, or only fixing authentication for an already configured domain. Inventory the website, existing mailboxes, aliases and other services that depend on the zone.
Start with the domain setup workflow in your own Fastmail account and confirm the registrar it detects. The wizard offers express setup for a simple single-user arrangement and individual address setup for multiple users or addresses. Prepare the intended recipient addresses before directing inbound mail to the service. Authentication does not create missing mailboxes.
Choose the DNS ownership model deliberately
The wizard documents that answering Yes to having a website leads to MX-only instructions; answering No leads to nameserver instructions. The instructions can be changed later in the wizard. Do not choose No merely to get a shorter setup if an existing website or other DNS-dependent service must stay available.
Changing nameservers transfers authoritative DNS responsibility. Before making that change, preserve all required records and arrange a rollback with the domain owner. If you keep your existing DNS host, publish the required mail authentication records there. A record entered in a control panel that is not authoritative does not affect receiving servers.
MX records route inbound mail. They do not, by themselves, establish aligned DKIM or authorize every outbound sender. Keep a migration's inbound-delivery acceptance separate from its authentication checks. Fastmail notes that mail which never reaches its servers cannot be recovered by Fastmail.
Publish the current DKIM delegation set
Fastmail's manual DNS documentation requires all three current CNAME records. The selector labels are fm1._domainkey, fm2._domainkey and fm3._domainkey. Their targets contain the customer's actual domain and end in dkim.fmhosted.com. Copy the exact values from your domain instructions rather than substituting the literal placeholder in a documentation example.
The older mesmtp selector is explicitly marked deprecated for legacy domains. Do not adopt it as the new configuration simply because an old tutorial or historical zone export contains it. Conversely, do not delete a legacy record without checking whether the service still depends on it. Publish the current set and verify actual signing before retiring old trust.
Check how your DNS editor handles relative owner names and fully qualified targets. A target with an accidentally appended copy of your domain is a different name. Check for an existing record at each owner before adding a CNAME, since a conflicting record can prevent a valid delegation.
Reconcile SPF and DMARC with existing senders
The provider's published SPF example authorizes spf.messagingengine.com. Use the current account instructions and integrate the authorization into one existing SPF policy where appropriate. Do not blindly replace a policy used by other applications. SPF has DNS-lookup limits, and authorization should match the actual envelope identity rather than assumptions about the visible address.
Fastmail's manual page also shows a monitoring DMARC policy. Treat it as an example, not a direction to downgrade an existing enforcement policy. Keep the domain's approved policy and reporting arrangements unless a separately reviewed change is justified. DMARC needs an aligned successful SPF or DKIM path; a passing SPF result for some unrelated domain is insufficient.
Test outgoing and incoming mail independently
Send a controlled message from the custom-domain address using the intended Fastmail route. Preserve its original headers and identify the visible From, envelope domain, DKIM signing domain and selector, and trusted receiver results. Check that a passing authentication identity aligns under the domain's applicable mode. Do not treat the existence of all three DNS records as proof that a particular message was signed correctly.
Illustrative case, not a measured Fastmail result: From is person@example.com and a valid DKIM signature uses d=example.com. This gives exact DKIM alignment. A later application sending from the same visible address through another relay needs its own test; it does not inherit the result of the mailbox test.
If inbound mail was moved, test each required address and alias from an external sender as well. Keep those outcomes separate from the outgoing authentication record. Website availability also needs its own check after any nameserver move.
Complete with evidence, not a green assumption
When validation fails, query the authoritative owner names and compare values before waiting on caches. Check the route used by the test message and whether a client sent through a different SMTP service. Preserve previous records and maintain an approved recovery plan until the migration is accepted. This is a documentary guide with a synthetic example; no live DNS, mailbox migration or message delivery was executed. Human approval and production evidence remain pending.
Treat a partial selector set as incomplete configuration
Written case FM-01 assumes fm1 and fm2 are published correctly for example.com, but fm3 is missing. A hypothetical message signed with fm1 could validate while the documented three-record configuration is still incomplete. The message result does not prove future selector rotation coverage. Obtain the actual third target from the domain instructions and verify all three owners before closing configuration. If an existing website must remain available, retain its DNS dependencies and choose the supported records-only route unless a separate migration is approved. No record lookup, message verification or migration occurred for this case.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.