The Rules That Decide If Your Email Reaches the Inbox

You send a shipping confirmation and a customer says it never arrived. You send a launch email to 900 people and open rates halve overnight for no reason you can see. The usual reaction is to blame the copy, because the copy is the part you can edit.

That reaction is nearly always wrong, and it is expensive because it sends you rewriting subject lines for a week while the actual fault sits in a DNS record you have never looked at. Here is the order in which your mail is judged, what each gate checks, and which of them you can fix this afternoon.

What actually decides whether your email reaches the inbox?

A sequence of checks, only the last of which reads the words. The figure below is the order, and the order is the useful part, because failing an early gate makes everything after it irrelevant.

Gate one is the connection: whether you speak TLS and whether the sending machine has sane forward and reverse DNS. Gate two is authentication, which asks whether the domain in the From line is one you can prove you control. Gate three is reputation, built from complaints, bounces and history. Gate four is the learned classifier that reads the message. Gate five is placement, which is not binary: mail can go to a tab, be delayed, or arrive with images stripped.

Small senders spend almost all of their attention on gate four and almost none on gates two and three, which is exactly backwards. Gates two and three are deterministic, documented and fixable. Gate four is a model whose behaviour you can influence but never read.

The rules the mailbox providers actually publish

They are unusually specific, which is a gift. Google's email sender guidelines set requirements that took effect on 1 February 2024 for anyone sending to personal Gmail accounts. Every sender, regardless of volume, needs SPF or DKIM set up for their sending domain, valid forward and reverse DNS records, a TLS connection, messages formatted per RFC 5322, and a spam rate kept below 0.3 percent as reported in Postmaster Tools.

Cross 5,000 messages a day to personal accounts and the requirements tighten. You need SPF and DKIM together rather than either, a DMARC record for the sending domain, and alignment, meaning the domain in your From header has to match either the SPF domain or the DKIM domain. Marketing and subscribed messages must support one click unsubscribe, with a visible unsubscribe link in the body as well. Google notes that DMARC enforcement can be set to none, which is worth knowing because the record is required and the strict policy is not.

Yahoo's sender best practices land in the same place with one addition that catches people: unsubscribe requests must be honoured within two days. It also states the list hygiene position plainly, asking senders to mail only people who specifically requested it and to avoid purchased lists and pre ticked opt in boxes.

Microsoft joined with its own threshold. As described in the Microsoft Q and A on Outlook's requirements for high volume senders, from 5 May 2025 senders of more than 5,000 messages a day to consumer Outlook, Hotmail and Live addresses need SPF, DKIM and DMARC with alignment, and non compliant mail is routed to Junk rather than rejected outright. The same thread makes a useful technical point: DMARC passes if either SPF or DKIM aligns, and a temporary DKIM lookup failure is ignored rather than treated as a failure.

The table is assembled from the three publishers, and the pattern in it is the finding: the three largest consumer inboxes have converged on one specification. That is genuinely good news for a small sender, because it means one afternoon of DNS work satisfies all of them rather than three separate projects.

Is one click unsubscribe just a link in the footer?

No, and this is the requirement most often assumed to be satisfied when it is not. The mechanism is defined in RFC 8058, and it works through headers rather than through the body of your message. The sender includes a List-Unsubscribe header carrying an HTTPS address and a List-Unsubscribe-Post header carrying a single value that signals one click support. The mailbox provider then shows its own unsubscribe control at the top of the message.

Three details in the specification matter operationally. The endpoint must accept a POST request without needing cookies or any other context, because the click comes from the mail client rather than from a browser session. Both headers must be covered by a valid DKIM signature. And redirects should be avoided, since the RFC notes that redirected POST actions have historically been unreliable.

The reason it is a POST rather than a plain link is worth understanding, because it explains a bug people have seen for years. Anti spam software and mail clients sometimes fetch the URLs found in headers, which with a simple link would unsubscribe people who never asked to leave. Requiring a POST separates a deliberate click from an automated fetch.

If your provider handles this for you, verify it rather than assume it. Send yourself a message at a Gmail address and look for the unsubscribe control next to the sender name. If it is absent, the headers are absent.

Where the machine learning part actually bites

At gate four, and mostly through behaviour rather than vocabulary. The old model of spam filtering, in which certain words condemned a message, has not been how these systems work for a long time. What a modern classifier weighs for a small sender is closer to how recipients treat your mail: whether it gets opened, replied to, moved out of spam, deleted unread or reported.

This has a practical consequence that runs against most email marketing advice. Sending more often to a list that does not engage actively damages the delivery of the mail you care about, including your order confirmations if they share a domain. A shop that blasts a weekly newsletter to 4,000 addresses of which 300 are interested is teaching the filter that its domain sends unwanted mail, and then wonders why receipts stop arriving.

The other place AI shows up is on your side of the wire, and it needs care. Generated copy tends to be long, uniform in shape and heavy on links, which is a pattern that correlates with bulk sending rather than personal correspondence. Our piece on where AI genuinely helps an email programme goes through which stages benefit and which do not, and the short version is that it helps most at the drafting stage and least at the sending decision.

How do you diagnose a deliverability problem?

In this order, and stop as soon as something fails, because a failure at an early gate explains everything downstream.

1. Check authentication on a real message. Send to an address you control at each of the three big providers and inspect the received headers for SPF, DKIM and DMARC results. This takes ten minutes and settles most cases.
2. Check alignment, not just presence. A passing SPF record for your provider's domain does nothing if your From address is your own domain and nothing aligns. Alignment is the requirement, and it is where correctly configured looking setups fail.
3. Look at the complaint rate. Register with the postmaster tooling each provider offers. A rate above the published threshold explains a sudden drop better than any content theory.
4. Check the unsubscribe headers. Present, signed, pointing at an endpoint that accepts a POST.
5. Only then look at the content. And when you do, look at link count, image to text ratio and whether the sending pattern changed, before you look at the words.

What breaks a setup that used to work?

Change, almost always, and usually change you made for another reason. Adding a new tool that sends on your behalf, a booking system, a review request service, a helpdesk, introduces a new sending source that your SPF record does not authorise. Moving email providers changes the DKIM keys. A website migration can drop DNS records nobody remembered were load bearing.

The failure is often partial, which makes it harder to spot: the new tool's mail fails while everything else works, so the shop concludes that particular tool is broken. Keeping a written list of every service permitted to send as your domain, updated when you add one, is the cheapest prevention available. It belongs in the same place as the rest of your operational documentation, which we argued for in the piece on writing standard operating procedures before you automate.

Seasonal volume is the other trigger. A domain that sends 200 messages a day and then sends 6,000 on the morning of a sale looks, to a filter, exactly like a compromised account. Warming a list up over several days is not superstition, it is the difference between a delivered campaign and a suppressed one.

Why does a filter treat a small sender differently?

Because it has almost no history to go on, and that cuts both ways. A domain sending fifty messages a day generates too little signal for a provider to build a confident reputation, so decisions lean harder on authentication and on the reputation of the shared infrastructure you send through. That is why two shops using the same email platform can have very different experiences: they inherit different neighbours.

The practical implication is that authentication matters more at small volume rather than less, which inverts the usual reading of the bulk sender thresholds. Nobody is going to reject your mail for lacking DMARC at fifty messages a day. What happens instead is that a filter with no reputation to consult and no authentication to verify falls back on the content model, and the content model is the least predictable gate in the sequence.

It also means consistency is a genuine asset. Sending from the same domain, with the same From name, at a steady cadence, builds the history that eventually lets you send a large campaign without being treated as an anomaly. A shop that mails from three different addresses depending on which tool sent it is spreading thin signal across three reputations instead of building one.

Replies, and the metric nobody watches

A reply is the strongest positive signal a recipient can send about your mail, and most shop email is designed to make replying impossible. No reply addresses, unmonitored inboxes and reply to fields pointing at a platform all remove the one behaviour a filter reads as unambiguous interest.

Microsoft's guidance for senders makes the point directly by asking that the From or Reply To address be valid, reflect the real sending domain, and be able to receive replies. It is stated as a courtesy requirement and it is also a deliverability one. For a small shop, an inbox that a person actually reads is not an overhead, it is the cheapest reputation building tool available.

There is a customer service argument on top of the technical one. People reply to shipping notifications with genuine questions, and those replies vanishing into an unmonitored address produces support tickets somewhere more expensive later. Which messages deserve a human first is a triage question we worked through in the piece on which support tickets to automate first.

What to do after a drop

Slow down before you change anything. The instinct after a bad campaign is to send a corrective mail to the same list, which adds volume at exactly the moment your reputation is under review. The better sequence is to pause non essential sending, confirm the transactional path still works, and let the complaint rate settle before resuming.

Then narrow the audience rather than the frequency alone. Sending only to people who opened something in the last ninety days rebuilds engagement signal faster than any content change, and it costs you nothing you were actually going to earn. Widen again gradually once placement recovers, and treat the recovery period in weeks rather than days.

Keep a note of what changed and when, because deliverability problems are almost always caused by a change and almost never diagnosed without one. A two line entry each time you add a sending tool or edit a DNS record turns a week of guessing into a five minute look.

What a small shop should actually do

Four things, in an afternoon, and then leave it alone. Publish SPF, DKIM and DMARC for your sending domain even if you are far below any bulk threshold, because the records cost nothing and the requirements only move in one direction. Split transactional and marketing sending onto separate subdomains. Confirm one click unsubscribe is really present in the headers. Register for the postmaster tools so that when something changes you find out from data rather than from a customer.

Then treat list quality as the ongoing work, since it is the only input to gate three you control. Remove addresses that have not opened anything in a year rather than mailing them harder. Never buy a list. Use a real confirmation step at signup, which Yahoo explicitly recommends and which also gives you a cleaner picture of who actually wants to hear from you.

One structural note to finish. Email deliverability depends on domain records, sending history and a reply address that works, all of which are attached to infrastructure you should be able to move. A shop whose store, domain and sending setup are spread across services it cannot export from will pay for that the first time it needs to change providers. Keeping the storefront itself in your own hands is the same argument, and it is why our AI ecommerce store builder writes the code to a repository you own rather than to a runtime you rent.