How to improve email deliverability, in order of impact

Most deliverability advice is ordered by how easy it is to write, not by how much it moves the needle. To improve email deliverability, work in the order mailbox providers actually evaluate your mail: pass authentication, fix reverse DNS, keep your user-reported spam rate under Gmail's published 0.10% target, ramp sending volume gradually and then keep it consistent, and clean your list. Those five items carry more weight than every content tweak combined, because filters check who you are and how you behave before they ever read what you wrote.

Why this order: filters judge reputation before content

Spam filtering is not one decision — it is a sequence of gates, each cheaper than the next. Microsoft states the ordering plainly: "Microsoft 365 rejects spam based on the reputation of the source email server. If a message passes source IP inspection, it continues through spam filtering" (Microsoft Learn). At the SMTP handshake the receiver knows only your IP, its PTR record and your HELO string — and it can reject right there, before your subject line exists (Gmail SMTP error codes). Authentication is checked at the envelope stage; content classifiers only run on mail that survived both.

The practical formulation: reputation sets your baseline probability of reaching the inbox and decides whether your content is evaluated at all; content adds variance around that baseline. That is why this checklist front-loads infrastructure and behaviour and leaves copy for last. If your mail is already in the spam folder and you want to diagnose which layer caught it, start with why emails go to spam.

1. Pass authentication — it is a gate, not a bonus

Since 2024, Gmail rejects unauthenticated mail outright with 550 5.7.26: "Gmail requires all senders to authenticate with either SPF or DKIM" (Gmail SMTP error codes). Al Iverson's January 2026 assessment is blunter: it is now "no auth, no entry" at Gmail, Yahoo and Microsoft alike (Spam Resource). Publish SPF, sign with DKIM, and publish a DMARC record that aligns with your visible From domain.

Weak policy is itself penalised: Microsoft's composite authentication emits reason code 001 for domains that published no records or "a weaker failure policy (SPF ~all or ?all, or a DMARC policy of p=none)" (Microsoft anti-spam headers). Once your DMARC reports show clean alignment, move to enforcement — and be aware that most staged-rollout guides are stale as of August 2026, because the old pct= percentage mechanism was removed when DMARC was standardized as RFC 9989 in May 2026.

How to verify: send a message to a Gmail account you control, open "Show original", and confirm spf=pass, dkim=pass and dmarc=pass in the Authentication-Results header. Then check the compliance dashboard in Google Postmaster Tools, which grades eleven requirements — SPF, DKIM, DMARC policy and DMARC alignment among them — as COMPLIANT or NEEDS_WORK (Postmaster Tools v2 API).

2. Verify reverse DNS — the current top rejection cause

As of August 2026, this is the highest-value single check most senders have never run. When Google began including SMTP rejection data in DMARC aggregate reports in mid-2025, the surprise finding was that "the largest single driver of rejections was infrastructure. In particular, sending IPs with broken or missing PTR records" — and that "Gmail alone rejected tens of millions of messages for this reason in a matter of weeks" (Spam Resource, Jan 2026). The matching Gmail error is 550-5.7.25 (Spam Resource).

The requirement is forward-confirmed reverse DNS: the sending IP's PTR must resolve to a hostname whose A record points back to the same IP. If you send through a reputable ESP's shared pool (Resend, Postmark, SendGrid), the PTR belongs to the ESP and is almost certainly correct — verify once, then stop worrying. If you run your own MTA or a dedicated IP, this is the thing most likely to be silently broken. Full explanation in what a PTR record is.

How to verify: run dig +short -x <your-sending-IP>, then dig +short A <the-hostname-it-returned>. The round trip must land back on the same IP. Anything else counts as no PTR at all.

3. Keep the user-reported spam rate under 0.10%

Complaints are the one reputation input every major provider publishes a number for. Google: keep spam rates "below 0.10%" and "avoid ever reaching a spam rate of 0.30% or higher" (Google sender guidelines). Yahoo publishes the same 0.3% ceiling (Yahoo Sender Hub). Crossing it carries a time-based penalty: bulk senders above 0.3% are ineligible for mitigation until they have stayed below it for 7 consecutive days (Google FAQ).

At small volume the arithmetic is brutal: 0.3% is three complaints per 1,000 delivered messages, so at 50 messages a day a single complaint blows the entire budget. That cuts both ways — target carefully, and don't over-interpret one bad day on a tiny sample. What actually moves complaints is list provenance and unsubscribe handling, not copy: Gmail's compliance checks explicitly grade one-click unsubscribe support and whether you honour it (Postmaster Tools v2 API).

How to verify: the spam-rate dashboard in Postmaster Tools, which is calculated daily (Google FAQ), plus Yahoo's complaint feedback loop — the one major FBL that is domain-keyed, so it works even from a shared IP pool.

4. Ramp volume gradually, then keep it consistent

A new domain has no reputation, and unknown is treated like bad. M3AAWG: "Reputation usually starts as unknown, which makes it similar to bad" (M3AAWG Sending Domains BCP); Spamhaus: "unknown reputations begin as 'poor' by default" (Spamhaus DBL). Worse, "messages from newly created domains attempting to disguise low-volume spam within legitimate traffic" is an attack pattern Gmail's ML models were explicitly built to catch (Google Workspace blog).

The only cure is a track record. M3AAWG's guidance: "Start low and slow; increase sending volume slowly (consider 6 weeks of warm-up as an average)" (M3AAWG). After the ramp, consistency matters as much as the ramp itself — Google: "Send email at a consistent rate. Avoid sending email in bursts" (sender guidelines), and rate-limit errors like 421 4.7.28 are keyed to unusual rate, meaning deviation from your own history (Gmail SMTP error codes). This is the one checklist item that cannot be done in an afternoon — it is the part WarmEnvelopes automates, sending a steady, logged ramp of warm-up mail from your domain through your own Resend account so the daily consistency actually happens.

How to verify: watch delivery errors in Postmaster Tools, and treat 421 4.7.0 / 421 4.7.28 deferrals in your ESP logs as the early warning that you are moving faster than your history supports.

5. Clean the list — bounces are a live signal, not just a metric

Unknown-user rejections happen during the SMTP conversation, while the receiver is watching. M3AAWG: "The volume of permanent failures is one indicator used by receivers to build a reputation about a sender" (M3AAWG Sender BCP). No provider publishes a bounce threshold; practitioner consensus clusters around under 2% acceptable and above 3% damaging — treat those as convention, not provider fact.

How to verify: your ESP's bounce log. Remove hard bounces immediately and never re-mail an unknown user; if your hard-bounce rate is above low single digits, the list — not the filter — is the problem.

6. Finish the DNS foundations beyond authentication

Three records quietly matter after SPF, DKIM, DMARC and PTR:

Record	Why it matters
MX on the sending domain	Not a documented Gmail requirement, but a domain with no MX cannot receive bounces or replies — the shape of a throwaway, and a spam-score contributor at some receivers (Suped)
Custom Return-Path (MAIL FROM) domain	SPF validates the Return-Path domain, not the From domain. On ESP defaults, SPF passes for the ESP's domain and contributes nothing to your DMARC; aligning it gives DMARC two independent paths to pass (DMARCPal)
A record with a real page behind it	URL-reputation systems fetch and classify what lives at domains they see in mail; a parked page or NXDOMAIN classifies differently than a real site

How to verify: run your domain through the free domain checker, then send yourself a message and confirm the Return-Path: header sits on your own organisational domain.

7. Separate mail streams on subdomains — if you can feed them

M3AAWG strongly recommends "a separate subdomain of the main domain name for each distinct sending purpose" (M3AAWG) — newsletters on news.example.com, transactional on notify.example.com — so a complaint-prone stream doesn't blend its reputation into your password resets. Two caveats most summaries skip. First, segmentation "requires sufficient and relatively consistent traffic volume": splitting low volume across subdomains turns one identifier with a usable signal into several with none. Second, a subdomain is a compartment, not a firewall — Gmail counts subdomain traffic toward the parent domain's 5,000-messages-per-day bulk-sender threshold (Google FAQ), and no provider has ever confirmed that a parent domain is insulated from a bad subdomain.

How to verify: check the DKIM d= in each stream's headers points at the intended subdomain, and only split a stream that sends meaningful, steady volume on its own.

8. Then — and only then — tune content

The content signals with documented weight, from SpamAssassin's published rule scores (50_scores.cf) and Microsoft's Advanced Spam Filter list (ASF settings):

• Include a plain-text alternative. HTML with no text part (MIME_HTML_ONLY) costs up to 2.2 points against SpamAssassin's default 5.0 threshold (SpamAssassin config docs). Cheap fix, measurable effect.
• No forms, iframes, scripts or embeds in HTML. Microsoft's ASF marks each of these high confidence spam when an admin enables it.
• Watch which domains you link to. Link-domain reputation carries some of the heaviest content weights (URIBL_DBL_SPAM scores 2.5), and Gmail throttles senders for "unsolicited email containing one of your URL domains" (Gmail SMTP error codes). URL shorteners share their reputation with every other user of the shortener.
• Keep a sane image-to-text ratio. Image-heavy, text-poor HTML scores 0.3–2.8 points across the HTML_IMAGE_ONLY_* rule family.

How to verify: send to a mailbox behind a SpamAssassin or Rspamd gateway (many corporate and self-hosted receivers) and read the X-Spam-Status header — it lists every rule that fired and its running total.

What does not meaningfully help

This is where most deliverability effort actually goes, and it is mostly wasted.

Rewriting copy to dodge "spam trigger words." The heavy scores sit on reputation lookups and statistical classification, not vocabulary: the classic ALL-CAPS subject line is worth 0.5 points against a 5.0 threshold (50_scores.cf), and a Bayesian filter has no built-in opinion about the word "free" — only an empirical one, learned per installation and increasingly per user. Laura Atkins: "Filters just don't work that way. They maybe, sorta, kinda used to, but we've gotten way past that now" (Word to the Wise). Litmus, citing Gmail's own anti-spam team, calls trigger words "mostly an email deliverability myth" (Litmus). The honest caveat: when reputation is already marginal, small content signals become the tiebreak — but the fix is still the reputation.

Checking your domain reputation dashboard in Postmaster Tools. You can't. Google retired the Domain and IP Reputation dashboards with Postmaster Tools v1 in late 2025 (Google), and most guides still tell you to look there. The observables that remain: the daily spam rate, the compliance-status checks, and delivery errors.

Reading your SCL at Microsoft. Microsoft's own documentation, current as of August 2026, says the SCL value "no longer holds the same meaning in cloud organizations" and "doesn't determine the action taken on the message" — read the CAT field in X-Forefront-Antispam-Report instead (Microsoft SCL doc).

Letting a domain "age" without sending. Waiting clears the fresh-domain blocklists — Spamhaus ZRD lists every newly registered domain for its first 24 hours (Spamhaus ZRD FAQ), and Al Iverson recommends 30 days of age before commercial warm-up (Spam Resource) — but age builds nothing by itself. The reputation clock starts on your first send, not at registration.

Spreading the same template across more domains. Providers cluster campaigns by content fingerprint — Google's stated rationale for its clustering systems is that spammers vary each message slightly, so it detects the campaign rather than the message (Google Cloud blog). Forty domains sending one template is one cluster with forty IPs attached.

Panicking about the Promotions tab. Promotions is a categorisation of mail that already passed spam filtering; messages there are delivered and "do not count as spam" (Mailgun). Treating it as a filtering failure leads to changes that make things genuinely worse.