← All articles

The bulk sender checklist: what large mailbox providers now require

Authentication, one-click unsubscribe and a spam-complaint ceiling are no longer best practice — they are entry requirements. Here is the checklist, and how to verify each line.

The large mailbox providers have converged on a common set of requirements for anyone sending mail at volume. The details differ slightly between them, but the shape is the same everywhere, and it is no longer advisory: mail from senders who do not meet it gets throttled, filtered or rejected.

Here is the checklist, with how to verify each line rather than assume it.

1. SPF and DKIM, both, on every message

Not one or the other. Both, on everything you send, including the transactional mail your application generates.

Verify: check the records, then send a real message and confirm both pass in the report. A published DKIM key that is never used to sign is a common and invisible failure — the DNS looks perfect and no message carries a signature.

2. A DMARC record, at minimum p=none

The bar is a valid, published DMARC record. p=none clears it. Enforcement is better, and it is where you should be heading.

Verify: the DMARC fixer reads yours, validates every tag, and tells you what each problem actually means. A record with a typo in a tag name is treated by receivers as no record at all.

3. Alignment between your From domain and what authenticates

This is the requirement most often missed, because it is invisible unless you know to look. Your message must pass DMARC, which means SPF or DKIM must authenticate a domain that aligns with the From address the recipient sees — not just any domain.

Sending through an ESP whose bounce domain passes SPF while your From domain is unrelated does not clear this bar. It has never been enough, but it used to go unpunished.

Verify: the deliverability report resolves alignment the way a receiver does, and says which of SPF and DKIM aligned.

4. One-click unsubscribe that works

Bulk mail needs a List-Unsubscribe header, and a List-Unsubscribe-Post header supporting one-click. The requirement is not just that the headers exist: the unsubscribe must be honoured promptly — the published expectation is within two days — and it must not require the recipient to log in, confirm on a landing page, or answer a survey.

Verify: our report checks for the headers on any message you send us. Whether your backend honours them is a question only your own test can answer — unsubscribe from your own list and see what happens.

5. A spam-complaint rate below the threshold

The commonly stated ceiling is 0.3%, with an ambition of staying under 0.1%. That is three complaints per thousand delivered messages — a low bar to trip if you are mailing a purchased list or an address that has ignored you for two years.

Verify: your ESP reports this. If it does not, that is worth more attention than any other item here. Also enrol in the feedback loops the major providers offer, which report complaints back to you directly.

6. Valid forward and reverse DNS on your sending host

The IP you send from needs a PTR record, and that PTR must resolve back to the same IP. The hostname you announce in HELO/EHLO must be a real, resolvable name — not localhost, not a bare IP, not the generic string your hosting provider assigned.

Verify: the deliverability report checks the PTR, the forward confirmation and the HELO name from the actual connection your message arrived on.

7. TLS on the connection

Mail should be sent over an encrypted connection. This is table stakes now and most modern mail software does it by default — but a hand-rolled SMTP client in an application somewhere may not.

8. Don't send to addresses that never asked

Explicit consent, a real unsubscribe, and no purchased lists. Every technical item above is undone by a list that generates complaints. This is the part that no tool can check for you and the part that decides your outcome.

Working through it

The technical half of this list is checkable in about five minutes:

  1. Run the DNS checker — covers items 1, 2 and part of 3, without sending anything.
  2. Run the DMARC fixer — covers item 2 in detail, and generates the record to publish.
  3. Send one real message to a test address — covers 1, 3, 4, 6 and 7 as a receiver actually sees them, and adds blocklist and content checks on top.

The remaining items — complaint rate and consent — are questions about your list, not your configuration. They are also the ones that matter most in the long run.