Email deliverability checklist

Reverse DNS, HELO, and the identity your server presents

Before a receiver looks at your headers it looks at where the connection came from. Three names should agree: the PTR record for the sending address, the forward A or AAAA record of the name that PTR returns, and the name the server uses in its EHLO greeting. When all three agree, a receiver has three independent confirmations of one identity. When they do not, it has none.

Google requires valid forward and reverse DNS for every sender, at any volume, and is explicit that the PTR hostname must itself resolve back to the sending address. That full-circle property is the one people miss: anyone can point a name at any address in reverse, and only the forward record proves the name's owner agrees. Our reverse DNS check reports the two conditions separately for this reason.

A reverse name that looks machine-generated — the kind a provider mints for a whole block, usually containing the address itself — is an older and weaker heuristic, but it is still live. It is worth changing where you can and not worth much anxiety where you cannot.

The reverse zone is almost never yours. It is delegated to whoever holds the address block, so this is a request to your hosting provider, cloud platform or ISP, not an edit in your own DNS. A whois lookup on the address names the organisation to ask. If a consumer ISP will not set it, that address should not be sending mail directly at all — relay through a provider instead.

If you send only through Google Workspace, Microsoft 365 or an email service provider, all of this is theirs and is already correct. Confirm it rather than configuring it.

dig +short -x 203.0.113.10
# -> mail.example.com

dig +short mail.example.com
# -> 203.0.113.10        both directions agree

# and the greeting the server actually uses:
openssl s_client -starttls smtp -connect mail.example.com:25 \
  -servername mail.example.com </dev/null 2>/dev/null | head -3
# the EHLO name your server announces should be mail.example.com too

Reputation: the address, the domain, and which one follows you

Mailbox providers keep a running opinion of you, and they keep it in two places.

IP reputation attaches to the address you send from. It is built from volume and how steady it is, complaint rate, spam-trap hits, bounce rate, and whether your authentication is consistent from one message to the next. It is left behind when you change servers, which cuts both ways: a bad reputation can be escaped and a good one has to be rebuilt.

Domain reputation attaches to the domain in your From header, and increasingly to the domains in your links as well. It follows you across servers, providers and address changes. It is the one that is slow to build and slow to repair, and it is why moving to a new sending platform does not reset a deliverability problem.

Shared and dedicated addresses trade one risk for the other. On a shared address your reputation is partly your neighbours', which is fine while the provider polices its customers and awful when it does not. On a dedicated address your reputation is entirely yours and starts at nothing, which is why the next section exists.

The only places you can see your own reputation as a provider computes it are the providers' own tools. Google Postmaster Tools shows Gmail's view, including the spam rate that Google publishes a threshold against, and requires verifying your domain. Microsoft's Smart Network Data Services shows per-address data for its consumer mailboxes. Both are free. Nothing outside those tools is the provider's opinion, however confidently a third-party dashboard presents a score.

It follows that reputation is not checkable from outside, and our scan does not claim to. It checks configuration — authentication, transport, reverse DNS, the blocklists we can query — and tells you which checks it could not run. It cannot tell you your spam rate at Gmail, and neither can anything else that is not Gmail.

Blocklists, and how much to care

A listing on a widely consulted blocklist stops delivery outright at any receiver that consults it, and it does so at the SMTP connection, before content is looked at. A listing on an obscure list often changes nothing at all. Telling the two apart is most of the work, and the guide on removing an IP from an email blacklist covers the reading, the causes and the delisting process for each major operator in detail.

For a checklist, four points.

• Check the addresses you actually send from, which are frequently neither your website's address nor your MX addresses. The Received line closest to the sender in a message you have sent names the right one.

• Some listings are not spam listings. Spamhaus's Policy Blocklist lists end-user and dynamic ranges by policy and says in as many words that the addresses in it are not necessarily bad, simply that they should never be sending mail. If you are listed there, the remedy is to relay through a provider, not to request removal.

• A list that did not answer is not a clean list. Timeouts, server failures and refusals because your resolver is not registered all look identical to not listed unless a tool deliberately keeps them apart. Ours does, and reports them as unanswered.

• Our blocklist check does not query Spamhaus, because its free feed is licensed for non-commercial use only and this is a commercial site. Spamhaus is the list most providers actually consult, so check it yourself, free, at check.spamhaus.org. Every run of our check says this rather than letting a narrow clean result read like a broad one.

Warming up a new sending IP or domain

A sending address with no history that starts sending thousands of messages on its first day looks exactly like a compromised host, because that is what compromised hosts do. A domain registered last week has no history at all and additionally has the shape of a throwaway phishing domain. Warm-up is the process of giving a provider a reason to form a good opinion before you ask it to accept volume.

Be clear about what is and is not published here. No mailbox provider publishes a warm-up schedule. Google's guidance, in its own words, is to start with a low sending volume to engaged users and slowly increase the volume over time, while monitoring how recipients respond. That is the whole of it. The tables of exact daily figures that circulate are vendor conventions, sometimes sensible ones, but they are not provider requirements and should not be presented to anyone as though they were.

What does follow from how providers actually judge senders:

• Send to your most engaged recipients first. Opens and replies from people who want your mail are the signal you are trying to generate; sending the cold half of your list first generates the opposite one.

• Ramp per provider, not in aggregate. Each mailbox provider forms its own opinion, so a ramp that looks gentle across your whole list can be steep at one of them.

• Watch complaint and bounce rates at each step and stop increasing the moment either moves. The ramp is a feedback loop, not a calendar.

• Keep the volume steady rather than spiky once you arrive. An address that sends nothing for three weeks and then sends a campaign has, for practical purposes, gone cold again.

Two things must be right before day one: authentication complete and verified, and reverse DNS in place. Warming a misconfigured sender only teaches providers about a misconfigured sender, and you will have to start again once you fix it.

A new domain deserves the same treatment for the same reasons, and there is no volume small enough to skip it. If you are moving to a new sending domain, keep the old one sending its normal traffic while the new one ramps rather than cutting over in one step.

List hygiene and bounce handling

This is the part of deliverability that no configuration change reaches, and it is the part that ends most senders who lose delivery.

Bounces first, because they are unambiguous. A permanent failure — an SMTP 5.x.x reply — means the address does not exist or will never accept your mail. Remove it on the first occurrence, permanently, and do not retry. Continuing to send to addresses that have hard-bounced is the clearest possible signal to a provider that you do not process bounces, which is one of the few things it can measure directly.

A transient failure, a 4.x.x reply, means try later. Retry with a limit and a backoff, and move the address to suppression after a defined number of consecutive failures rather than retrying indefinitely.

The suppression list has to be global across every system that sends as your domain. An address removed from the marketing platform and still present in the invoicing system is not removed, and the second system will hit it. This is the commonest way a supposedly clean list keeps generating bounces.

Then the list itself. Never send to a purchased, scraped or rented list; there is no version of this that works, and the reason is spam traps. Providers and blocklist operators seed addresses that have never been published, and recycle long-dead addresses into traps as well. Hitting either is a fast route onto a blocklist, and a recycled trap is specifically designed to catch senders who never remove people who stopped engaging.

For the same reason, retire dormant subscribers. Run a re-engagement message to people who have not opened anything in a long period, and remove the ones who do not respond. That feels like deleting your list; it is deleting the part of your list that is generating the complaint and trap risk while never producing a response.

Confirmed opt-in, where a subscriber has to click a link in a confirmation message before they are added, is what makes all of the above rare rather than routine. It costs you some sign-ups and removes almost all of the addresses that would have damaged you.

Complaint feedback loops

A feedback loop is a provider telling you that a recipient pressed the spam button, so that you can suppress that address before they press it again. Reports are delivered in the Abuse Reporting Format defined by RFC 5965, which most sending platforms can ingest directly.

As of September 2026, read from each provider's own documentation:

• Microsoft. Smart Network Data Services shows per-address data for its consumer mailboxes, and the Junk Mail Reporting Program forwards copies of messages that recipients marked as junk. Both are free. Enrolment is keyed to an address you control and, in practice, to a dedicated sending address, because the point is to return complaints to the operator of the address the mail came from. Register for Smart Network Data Services first; the reporting feeds are created from within that account.

• Yahoo. Its Complaint Feedback Loop is domain-based rather than address-based, and enrolment requires that your outbound mail is DKIM-signed so Yahoo can identify the actual sender. Once enrolled it sends reports in Abuse Reporting Format so the recipient can be suppressed from further campaigns. It is reached from Yahoo's own sender hub; several widely linked enrolment pages are out of date.

• Google. There is no per-message complaint forwarding, and expecting one is a common mistake. Gmail's Feedback Loop is aimed at large-volume senders and at email service providers detecting abuse of their own platforms. It requires a Feedback-ID header in the shape a:b:c:SenderId, where SenderId is required and is between five and fifteen characters, and it reports aggregated complaint rates per identifier in the Postmaster Tools dashboard — and only where an identifier appears in enough mail and enough distinct spam reports on a given day to be reported at all.

Enrolling changes nothing by itself. The value is in two things: suppressing a complainer immediately, on the first complaint, and in the Gmail case being able to see which campaign or which segment generated the complaints rather than only that complaints happened.

Feedback-ID: campaign-2026-09:newsletter:segment-engaged:a1b2c3d4e5

# a:b:c:SenderId - the first three fields are yours to define
# (campaign, message type, segment are the usual choices)
# SenderId is required, 5-15 characters, and identifies you

One-click unsubscribe and the bulk-sender rules

Google, Yahoo and Microsoft each publish their own requirements for people who send them mail, with different thresholds and some genuine differences in scope; the guide on Gmail and Yahoo sender requirements sets those side by side. The mechanism they share is one-click unsubscribe, and it is the one most often implemented incorrectly.

It is not a link in the footer. It is two header fields that let the mailbox provider present its own unsubscribe control and act on it without the recipient visiting your site at all. RFC 8058 defines them.

The requirements are specific. The List-Unsubscribe field must contain one HTTPS URI. The List-Unsubscribe-Post field must contain the single key and value pair List-Unsubscribe=One-Click. The provider unsubscribes by sending an HTTPS POST to that URI with that pair as the request body. The sender must not return an HTTPS redirect, because redirected POST actions have historically not worked reliably. And the whole process has to work without manual intervention, and in particular without any software having to interpret the contents of a confirmation page.

Three failures account for nearly all of it. A URL that returns a confirmation page with a button instead of unsubscribing on the POST — correct-looking to a human, failing to the automated check. An HTTP URL rather than HTTPS. And a mailto: entry on its own: it is permitted alongside the HTTPS URI and does not satisfy the requirement by itself.

RFC 8058 also recommends that the URL carry an opaque, hard-to-forge component and that your server verify it, so that the unsubscribe endpoint cannot be used to unsubscribe people at random by guessing addresses.

Keep the visible unsubscribe link in the message as well. The header requirement is in addition to it, not a replacement, and both should act on the same suppression list. A recipient who cannot find an unsubscribe control uses the spam button instead, and that is the one that counts against you.

List-Unsubscribe: <https://example.com/u/8f3a2b1c9d>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

# the HTTPS URI must unsubscribe on a bare POST, with no confirmation
# page, no login and no redirect
# the mailto: is optional and does not satisfy the requirement alone
# 8f3a2b1c9d is the opaque, hard-to-forge part your server verifies

Message content and structure

Conformance to RFC 5322 is a stated requirement at more than one provider, and it is not a formality: a malformed message is cheap for a filter to reject and expensive for you to diagnose, because nothing about it looks wrong in your own sending tool.

• One From address, well-formed, in a domain you authenticate. A display name that contains an address, a From field with two addresses, or a From domain that does not match anything you have authenticated will each cause problems at different providers.

• A Date field, and a Message-ID that is globally unique. Duplicate Message-IDs across a campaign are a common bulk-sending bug and some receivers deduplicate on them, which silently loses messages.

• Declare your encoding. Eight-bit content sent without a correct Content-Transfer-Encoding is a classic source of mangled mail and of filter suspicion.

• Send a plain-text alternative alongside the HTML. An HTML-only message, and especially one that is a single image with no text, is one of the oldest spam shapes there is.

• Links should point at domains you control and that are consistent with your From domain. A public link shortener hides the destination from a filter, which is exactly why filters treat it badly, and a link to a domain with a poor reputation drags the message down regardless of how good yours is. This is also how a URI blocklist listing reaches your mail through a domain that is not yours.

• Do not send bulk mail with a free mailbox provider's domain in the From header. Those domains publish enforcing DMARC policies, so the mail is rejected outright rather than filtered, and no amount of configuration on your side changes it.

• Use a From address that can receive replies. A reply is a strong positive signal, and a no-reply address that bounces incoming mail is a small negative one that costs you nothing to remove.

TLS in transit

Google lists using a TLS connection for transmitting mail among its requirements for every sender, at any volume, so this is no longer only a privacy question.

Outbound, your sending server should offer and use TLS opportunistically. Any current MTA does this by default and every email service provider does it; the case where it is missing is usually an old appliance or an application sending directly through a library with TLS disabled.

Inbound, on the servers your MX records point at, the requirement is STARTTLS with a certificate that is currently valid, covers the MX hostname, and chains to a publicly trusted root. Our SMTP TLS check opens a real connection and tests each of those separately, because advertising STARTTLS and completing a working handshake are different things.

Understand what plain opportunistic STARTTLS does and does not give you. It protects against passive eavesdropping. It does not protect against an active attacker, because nothing in it obliges a sender to check the certificate before delivering, and a stripped STARTTLS advertisement simply results in a plaintext delivery. MTA-STS and DANE exist to close that gap by telling senders the certificate must validate, and TLS-RPT makes the resulting failures visible; the guide on MTA-STS and TLS-RPT covers the rollout.

One specific way this costs you mail rather than privacy: an MTA-STS policy at enforce, combined with a certificate that does not cover the MX hostname, causes conforming senders to fail delivery rather than fall back. That failure is invisible in your own logs, because the message never arrives. Publish the policy at testing, read the TLS-RPT reports, and only then move to enforce.

openssl s_client -starttls smtp -connect mail.example.com:25 \
  -servername mail.example.com -verify_return_error

# check three things in the output:
#   Verify return code: 0 (ok)        -> chains to a trusted root
#   subject / subjectAltName covers   -> mail.example.com
#   Protocol : TLSv1.3 (or TLSv1.2)   -> not 1.0 or 1.1

The monitoring loop

Everything above is a state that decays. The loop that keeps it from decaying silently has four inputs, and none of them is a one-off check.

• Provider dashboards. Google Postmaster Tools and Microsoft Smart Network Data Services are the only view of how those providers actually see you, and the spam rate in Postmaster Tools is the one metric with a published threshold. If you send meaningful volume to Gmail and have not set it up, do that before anything else on this page.

• DMARC aggregate reports. They tell you when a new sending source appears, when an old one starts failing, and when somebody is forging your domain. They are also the earliest warning that a platform has rotated a DKIM key without telling you.

• TLS-RPT reports, if you have published a TLS-RPT record. They are the only way inbound encryption failures become visible to you rather than to the sender.

• Your own bounce and complaint rates, per provider, from your sending system. A rate that is fine in aggregate can be bad at one provider, and providers judge you separately.

When delivery drops, the first question is whether it dropped at one provider or at all of them. One provider points at reputation or at a rule specific to that provider. All providers at once points at a configuration change on your side — an expired DKIM key, a second SPF record added when a platform was onboarded, a certificate that stopped renewing, a DNS change — and the change is usually recent and usually findable.

Build the same checks into change control. Every new tool that will send as your domain goes through the same sequence: add it to the sender inventory, give it DKIM with its own selector, add it to SPF only if it needs to be there and the budget allows, warm it if it sends volume, and confirm it in an aggregate report before trusting it.

Then run the whole set on a schedule — quarterly, or after any change to sending infrastructure. Our domain health check covers the configuration half of this in one pass, including MX, SPF, DKIM, DMARC, reverse DNS, SMTP TLS and the blocklists we can query, and says which checks it could not run rather than scoring them as passes. It cannot tell you your spam rate or your reputation; nothing outside the mailbox provider can.

What commonly goes wrong

• Treating a green authentication result as deliverability. SPF, DKIM and DMARC prove who sent the message; they say nothing about whether the recipient wanted it, and the requirements with actual thresholds are the ones no checker can measure.

• Sending volume from a brand-new address or domain on day one. It is indistinguishable from a compromised host, and the reputation damage takes far longer to repair than the ramp would have taken.

• Not processing bounces globally. An address suppressed in one sending system and still live in another keeps hard-bouncing, which is one of the few negative signals a provider can measure directly.

• An unsubscribe URL that returns a confirmation page instead of unsubscribing on the POST. It looks correct to a human and fails the automated requirement, and RFC 8058 also rules out answering that POST with a redirect.

• Keeping long-dormant subscribers because the list looks bigger. Recycled spam traps are built from exactly those addresses, and hitting one is a fast route onto a blocklist.

• Publishing an MTA-STS policy at enforce with a certificate that does not cover the MX hostname. Conforming senders stop delivering entirely, and because the mail never arrives there is nothing in your logs to find.

• Assuming a reputation score from a third-party dashboard is what the provider thinks. Only Postmaster Tools and Smart Network Data Services report the provider's own view, and only for their own mailboxes.