Fastmail Sender Requirements

Fastmail is a paid, privacy-respecting mailbox provider (Australia-based) that sells inboxes to individuals and businesses rather than monetizing scanned mail. Its published sender surface is deliberately small. There is no bulk-volume threshold, no spam-rate number, and no complaint feedback loop. What Fastmail does document is the classic operator hygiene any well-run receiver expects - forward-confirmed reverse DNS, a HELO that matches that reverse DNS, and SPF/DKIM/DMARC - plus an unusually candid statement of how it actually uses authentication results.

Scope: this page is about sending mail to Fastmail-hosted recipients (fastmail.com, fastmail.fm, and the many custom domains Fastmail hosts). The same pages also tell Fastmail’s own customers how to set up sending, which doubles as a clear statement of what Fastmail values in a sender.

The 60-second version

• Authentication shifts a score, it does not gate delivery. “Passing or failing these checks only alters a message’s spam score; we do not outright reject mail, only mark it as more or less suspicious.” Fastmail adds an Authentication-Results header to all inbound mail.
• FCrDNS and a matching HELO are the headline infrastructure asks. Forward and reverse DNS must match (RFC 1912), and your HELO/EHLO string should be that reverse-DNS fully-qualified hostname (RFC 5321, historically RFC 2821).
• SPF, DKIM, DMARC are all expected - Fastmail checks all of them (plus ARC) on inbound mail and strongly recommends them for any sender.
• No published bulk threshold, no spam-rate ceiling, no FBL. None of these exist in Fastmail’s public documentation.
• Misconfiguration can get you bounced. “If a sending server is not set up properly, we may bounce mail that’s sent from it.” This is the narrow exception to “we do not outright reject.”
• Abuse is reported to abuse@fastmail.com (or via in-product Report Phishing / Report Spam buttons).

How Fastmail uses authentication (the candid part)

Most providers tell you to authenticate and leave the consequences vague. Fastmail is explicit:

“Fastmail checks SPF, DKIM, DMARC, and ARC on all inbound mail. Passing or failing these checks only alters a message’s spam score; we do not outright reject mail, only mark it as more or less suspicious. We add a standard Authentication-Results header to all received mail explaining the results of the authentication checks.”

Two practical takeaways:

1. A DMARC p=reject on your domain does not mean Fastmail will reject your failing mail. Fastmail treats the result as a scoring input. (That is Fastmail-as-receiver behavior; it does not change what other receivers do with your p=reject.)
2. The Authentication-Results header is always present, so if you control or can read a Fastmail test inbox, you get a clean readout of exactly how your SPF/DKIM/DMARC/ARC evaluated.

This is a low-drama, score-based posture - consistent with a provider whose users pay for the service and whose volume is small relative to the consumer giants.

Infrastructure: FCrDNS and a matching HELO

Fastmail’s “Best practices for SMTP servers” page is the closest thing it has to a sender-requirements document. Its load-bearing points:

• Forward-confirmed reverse DNS (FCrDNS). “Having valid and matching forward and reverse DNS is one of the first recommendations in RFC 1912 (‘Make sure your PTR and A records match’). It’s a sign that the system administrator understands at least the basic RFCs, and it also helps to avoid spoofing.”
• HELO string = reverse-DNS name. “When an SMTP server sends email, it has to announce its name in the HELO or EHLO command. If DNS is set up correctly with [the] fully-qualified domain name (the reverse DNS name), the sender can follow RFC 2821 and use it as their HELO/EHLO string.”
• Do not use Sender Address Verification (SAV / callout verification). Fastmail explicitly discourages it: it is easy for spammers to work around, and aggressive callouts make your server “look like it’s attempting to attack other systems.”
• Misconfiguration risks a bounce. “If a sending server is not set up properly, we may bounce mail that’s sent from it.” The guidelines exist “to avoid common misconfigurations that may cause us to bounce mail.”

Note what is absent: no published TLS mandate, no PTR-naming rule beyond FCrDNS, no connection or rate limits, no recipients-per-message cap. If Fastmail enforces such limits internally, it does not publish them - flag this as unverifiable rather than assuming a number.

SPF, DKIM, DMARC (what Fastmail recommends)

Fastmail’s authentication pages double as a recommendation set for any sender. For its own customers’ domains it documents exact records, which reveal what it considers correct:

• SPF: a single TXT record. Fastmail’s own customers publish v=spf1 include:spf.messagingengine.com ?all. The mechanism is what matters for senders generally: publish SPF that authorizes your real sending hosts.
• DKIM: Fastmail customers add three _domainkey CNAMEs (fm1, fm2, fm3) pointing at fmhosted.com, enabling rotating keys. The general lesson: DKIM-sign everything. Fastmail itself “DKIM-sign[s] all outbound mail from our domains.”
• DMARC: Fastmail-hosted domains “have a DMARC policy of p=none… This allows users to send mail using our domains from anywhere, for legacy reasons.” Customers can move to p=quarantine or p=reject by replacing the auto-generated record. Fastmail points to dmarc.org for record tooling.

So Fastmail’s own posture is p=none for flexibility, while it checks (and scores on) DMARC for inbound mail. It does not require senders to publish any particular p= value.

Spam handling

Fastmail assigns every inbound message a spam score and moves high-scoring mail to the Spam folder; users tune sensitivity in Spam Protection settings. Two documented mechanics matter to senders:

• Connection-time blocking of known bots. Fastmail states it pre-emptively detects and blocks spam bots at connection time, “without rejecting any legitimate mail.” Legitimate, well-configured senders are not the target of this.
• User feedback trains personal filters. Recipients use Report Spam / Not spam (and a separate Report Phishing) to train their own filter and Fastmail’s systems. There is no sender-facing complaint feed exposing these - they feed Fastmail’s filtering, not an FBL you can subscribe to.

Forwarded mail is explicitly called out as harder to score accurately, because Fastmail loses sender context; this is a receiver-side note, but it reinforces why ARC matters when you forward.

Abuse reporting

Fastmail publishes clear abuse channels, even though it has no bulk-sender program:

• In-product: Report Phishing and Report Spam in the More menu (web and mobile). Phishing reports carry heavier consequences than spam reports and can result in Fastmail removing the message from its systems and locking compromised sending accounts.
• By email: if you believe a Fastmail user is violating the Terms of Service through spamming or phishing and cannot use the in-product buttons, “file a report by sending mail to abuse@fastmail.com.”
• Law-enforcement / data requests: legal-requests@fastmailteam.com (with support@fastmail.com CC for exigent requests). These are not sender-deliverability channels, but they confirm the separation Fastmail draws between abuse handling and legal process.

There is no documented “postmaster” deliverability portal or sender-support queue equivalent to Google Postmaster Tools or Yahoo’s Sender Hub. Flag: if such a channel exists for large senders, Fastmail does not publish it.

What Fastmail does NOT publish (be honest about the surface)

• No bulk-volume threshold. Nothing equivalent to Gmail/Outlook’s 5,000/day.
• No spam-complaint-rate number. No published ceiling at all.
• No feedback loop. Complaints train Fastmail’s filters and users’ personal filters; there is no ARF feed for senders.
• No reputation dashboard or sender portal.
• No published rate/connection limits, TLS mandate, or one-click-unsubscribe (RFC 8058) requirement in its sender-facing pages.

This thin surface is a feature of Fastmail’s model, not an oversight: it is a paid mailbox host, not a free consumer platform fighting industrial-scale abuse, so it leans on standard hygiene and scoring rather than a published rulebook.

Common mistakes

• Assuming p=reject gets your failing mail refused at Fastmail. It does not - Fastmail scores on the result and rarely rejects.
• Sending with a mismatched or generic HELO. Fastmail wants the HELO/EHLO to be your reverse-DNS FQDN; a mismatch reads as misconfiguration.
• Skipping FCrDNS. Missing or non-matching forward/reverse DNS is the first thing Fastmail flags as a misconfiguration that can get mail bounced.
• Using Sender Address Verification toward Fastmail. Explicitly discouraged and can make your server look like an attacker.
• Waiting for complaint data. There is no FBL; infer reputation from bounces, the Authentication-Results header on test mail, and engagement.

What Egressif does

We meet Fastmail’s published bar as baseline configuration, not firefighting: forward-confirmed reverse DNS with matching records, a HELO/EHLO string that equals the sending host’s reverse-DNS FQDN, SPF and DKIM published and DKIM-signing every message, and a real DMARC policy. Because Fastmail scores on authentication rather than rejecting, we treat the Authentication-Results header on a Fastmail test inbox as a free, precise readout of how our SPF/DKIM/DMARC/ARC actually evaluated, and we fix anything that scores against us. We do not run Sender Address Verification, we keep lists clean so we are never the connection-time-blocked bot pattern, and we keep abuse handling tight so we never become the subject of an abuse@fastmail.com report. Since Fastmail publishes no thresholds, dashboard, or feedback loop, we do not pretend to read signals that do not exist - we rely on bounces, authentication results, and engagement, and we make no inbox guarantee, because with a scoring receiver the score is what decides placement.

See the cross-provider provider rule tracker for how Fastmail compares, DMARC in 2026 for the authentication detail Fastmail scores on, and the reputation overview for the signals that matter when a provider publishes no threshold.