Email deliverability for small senders: what decides it

Deliverability is not delivery

Deliverability is the share of the mail you send that reaches the inbox of the person you addressed it to. Delivery, usually reported to you as a delivery rate, is the share that the receiving mail server accepted instead of bouncing. A message can be delivered and never seen: accepted at the door, filed straight into the spam folder, counted as a success by the sending side and read by nobody. The receiving provider does not tell you which folder it chose, and it will not.

What decides it, in rough order of weight for a sender with a small list: whether the receiving provider can prove the mail is from who it says it is, what it already knows about the reputation of the domain that signed it, how the people who received your last few sends behaved, how many of them pressed the spam button, and how many addresses you tried to reach that do not exist. Content matters too, but far less than the folklore about spam words suggests, and mostly as a tie-breaker once identity and reputation are settled.

The three records that say who you are

SPF, defined in RFC 7208, is a DNS record listing which servers are allowed to send mail for a domain. The receiving server takes the domain from the envelope sender, the address bounces are returned to, looks up its SPF record, and checks whether the connecting server is in it. Two consequences follow and both get missed: SPF checks the envelope domain rather than the From line a reader sees, and it breaks on forwarding, because the forwarding server is not in your record.

DKIM, defined in RFC 6376, is a cryptographic signature over the message headers and body, made with a private key held by whoever sends the mail and verified against a public key published in DNS under a selector. It survives forwarding, because the signature travels with the message, and it names a domain of its own in the signature. That domain is what accumulates reputation. If your provider signs with its own domain rather than yours, the reputation being built belongs to the provider and to every other sender in its pool.

DMARC, defined in RFC 7489, connects the other two to the thing the reader actually looks at. It requires that the domain in the visible From header align with a domain that passed SPF or DKIM, publishes what a receiver should do when nothing aligns, and asks for aggregate reports to be sent to an address of your choosing. A DMARC record at p=none changes no filtering decision by itself, but it is the only way to find out what is being sent under your name, including by you.

Alignment is the part that catches people out. Mail can pass SPF and pass DKIM and still fail DMARC, because both passes were on the provider’s domain and the From line was yours. That is the default state with a good many sending services until the domain setup is finished, and it looks identical to success everywhere except in a DMARC report. All three are a floor now, and none of them is optional.

The order to publish them in, on the subdomain you send from:

• SPF first, listing your sending provider and nothing you do not use.
• DKIM second, signed with your own domain rather than the provider’s, then a test message to confirm dkim=pass.
• DMARC last, at p=none with a report address you will read, and tightened only as the next two sections describe.

Read the reports for about two weeks before changing anything

Two weeks is the usual window and the reason is coverage rather than statistics: it takes that long for every system that sends mail under your name to have sent some. The list is always longer than expected. A helpdesk tool, an invoicing service, a form notifier, a calendar, a colleague’s client configured years ago, and a forwarding rule at a university that breaks SPF on every message it touches.

What you are looking for in the reports is mail that failed alignment and is yours, which is a configuration you have not finished, as against mail that failed and is not yours, which is either spoofing or a forwarder. The first kind has to be fixed before you tighten the policy. The second kind is the reason to tighten it.

Aggregate reports are readable by hand for a small sender, and there are free parsers if the volume gets annoying. Either way, read them rather than filing them. A policy moved to reject on top of an unread report is how a month of invoices stops arriving.

Move the policy to quarantine, then to reject

Once the reports show only mail you recognise passing and nothing of yours failing, change p=none to p=quarantine. Quarantined mail goes to the spam folder rather than being refused, so a mistake at this stage is visible and recoverable. Leave it there for a week or two and read the reports again.

Then move to p=reject, which is the point of the exercise: mail that claims your domain and cannot prove it is refused at the door. You can step there gradually with pct=, which applies the policy to a percentage of failing mail, though for a small sender the ramp buys less than it costs in confusion.

Nothing about the bulk sender rules requires reject. Google, Yahoo and Microsoft ask only that a DMARC record exist, and p=none satisfies all three. Reject is what stops other people sending as you, which is a separate benefit worth the two weeks it takes to get there safely.

What Google and Yahoo have required since February 2024

In late 2023 Google and Yahoo announced a set of sender requirements in near-identical language, with enforcement beginning in February 2024. It was the first time the two largest consumer mailbox operators had published the same list at the same time, and it moved a set of practices from advisable to load-bearing. Both publish their own version, and those two documents are the primary sources for this section. Microsoft applied SPF, DKIM and DMARC to high-volume senders at Outlook.com from May 2025; the guide to the bulk sender requirements sets out all three providers’ rules, and the CAN-SPAM law under them, one by one.

The headline items are three. Authenticate your mail with SPF and DKIM, both, and publish a DMARC record on the From domain. Offer one-click unsubscribe in the message headers, in the form RFC 8058 defines, and honour any unsubscribe request within two days. Keep your spam complaint rate low, with a threshold of 0.3% and a stated target of 0.1%.

Google defines a bulk sender as one sending close to 5,000 messages or more a day to Gmail addresses from the same domain, and applies the stricter requirements above that line. Below it, Google and Yahoo still ask every sender for SPF or DKIM, and since the same round of changes unauthenticated mail may be marked as spam or rejected, with a Gmail rejection carrying a 5.7.26 error. So the practical reading for a small sender is that the whole list applies, because you will cross the bulk line on a good month and because none of it is work you would want to do reactively.

What a spam complaint rate is, and why 0.1% is the number to aim at

A spam complaint rate is the count of people who pressed the spam or junk button on your mail, divided by the mail you got delivered to that provider, over a window the provider chooses. It is measured per provider and per sending domain, and the only way to see it is on the provider’s own dashboard: Gmail publishes yours in Postmaster Tools, and the other large operators have equivalents. Your sending tool cannot tell you this number, because nobody tells your sending tool.

Google and Yahoo both name 0.3% as the level to stay under, and Google names 0.1% as the level to aim at. The gap is not fussiness. 0.3% is where filtering starts to be applied to you; 0.1% is the headroom that means one bad send does not take you across it. Because these are rates, they behave worse the smaller you are: at a thousand delivered messages three complaints is already 0.3%, and at two hundred a single complaint is 0.5%. A small sender has no statistical cushion, only a structural one.

The structural one is worth spelling out, because complaints are not really about content. Somebody presses the spam button when they do not recognise the sender, cannot find a way out, or are surprised by what arrived. That points at four causes and none of them is a word in your subject line: an address added without the owner asking, a gap of weeks between signing up and the first send, a frequency or a subject that is not what was promised, and an unsubscribe that is hidden, slow or broken.

Hard bounces, soft bounces, and the suppression list

A hard bounce is a permanent refusal: the mailbox does not exist, the domain does not exist, the address has been disabled. A soft bounce is a temporary one: the mailbox is full, the server is greylisting you, you are being rate-limited. The distinction is carried in the SMTP response code, a 5xx for permanent and a 4xx for transient, and it dictates two completely different behaviours.

A hard bounce must be suppressed immediately and permanently, on the first occurrence. Not after three, not after a review. Continuing to send to an address you have been told does not exist is the clearest signal available to a receiving provider that a sender does not process its bounces, and not processing bounces is the operational signature of a bought or scraped list. It is also how you keep mailing a spam trap, which is an address that exists only to be mailed by people who should not have it.

A soft bounce is retried with backoff and then reclassified. There is no published figure for when one becomes permanent, because it depends on the reason code, but a common shape is to retry over a day or two and then treat somewhere between three and seven consecutive soft failures across a week or two as a hard bounce. A mailbox that has been full for a fortnight is not a reader.

The suppression list is the most valuable list you own and the one most often lost. It has to be permanent, it has to survive every re-import, and it has to be checked before a send rather than after. When someone exercises a right to erasure you still need to not mail them again, which is why a suppression list is usually kept as one-way hashes of addresses rather than as addresses; the GDPR guide takes that apart properly, and the guide to importing a list covers keeping suppressed addresses out of a re-import.

Shared or dedicated, and how a new domain is warmed

Two things get called a sending domain and only one of them is yours. The sending infrastructure, the IP addresses mail leaves from, is shared by default at every provider that serves small senders, and for a small sender that is the right choice: IP reputation is built by sustained volume, and a few hundred messages a morning is not enough volume to build any.

The domain in the DKIM signature and the From line, by contrast, is yours alone, and it is the identity that carries your reputation now that authentication is a floor. So the decision that matters is not shared against dedicated IPs. It is which of your domains does the sending. Use a subdomain reserved for it and keep the root domain for the mail humans send each other. A burned subdomain can be retired and replaced in an afternoon. A burned root domain takes your invoices, your password resets and your support replies with it, and cannot be replaced at all.

A new domain has no reputation, and mail from a domain with no reputation that suddenly arrives in volume looks exactly like mail from a domain registered this morning for a campaign. Warming is the practice of not looking like that, and the next section is how it is done.

Raise the volume on a ramp, not on a schedule

Neither Google nor Yahoo publishes a ramp. Google says only the general thing — start low, increase slowly and watch the signals as you go — and Yahoo says nothing about volume at all, so anyone quoting a daily table to three decimal places is quoting a habit rather than a rule. The shape below is that habit, written down honestly as a shape: a few hundred messages a day to the most engaged addresses, held for a couple of days, then roughly doubling every two to three days for as long as the numbers stay flat, reaching a steady state in something like two to four weeks.

What makes it a ramp rather than a schedule is that the next step is conditional on the last one. The volume does not double because three days have passed; it doubles because three days passed and nothing moved. That distinction is the entire technique, and it is the part that every published warm-up table leaves out.

Why open tracking is a poor signal and a real risk

An open is not an event email can observe. What is measured is the loading of a tiny image, usually a one-pixel file on a tracking host, treated as a proxy for a human having looked at the message. That proxy is broken from both ends. Gmail fetches and caches remote images through its own servers, so a load can happen without a reader. Apple’s Mail Privacy Protection fetches images on the reader’s behalf whether or not they open the message. Any client with images off registers nothing at all.

So an open rate contains both false positives and false negatives, in proportions that differ by provider and change without notice, and a sender who prunes a list by open rate is pruning partly at random. The reputational objection is separate: the pixel puts a third-party host into every message, adds a remote image load and often a redirect domain, and tracking infrastructure is itself something filters weigh. There is a privacy objection too, since an invisible pixel reporting a reader’s behaviour is processing personal data and has to be disclosed and justified like any other processing.

The signals worth keeping are the ones that require a decision by a person. A click, on a link you host on your own domain, is a decision. A reply is a stronger one. A confirmation click is the strongest single signal an address will ever give you. Reaching the last day of a course is a behaviour rather than an inference.

List hygiene, and the control underneath all of it

Hygiene is the unglamorous half of deliverability: keeping the list to addresses that exist and belong to people who still want the mail. It is mostly four habits. Suppress hard bounces on the first failure. Stop sending to addresses that have shown no click or reply in a long window. Catch typos at the form rather than at the mail server. Never re-import an address you have already suppressed.

A sunset window is the one that needs a number, and the honest answer is a range: most senders stop after somewhere between three and six months with no measurable engagement, and a course sender can be stricter than a newsletter, because a course either gets finished or it does not. What matters more than the exact window is that there is one and that it applies automatically.

Which brings it back to the root control. Confirmed opt-in, the step where an address receives exactly one message and joins the list only if somebody clicks, is the only mechanism that removes the typos, the borrowed addresses, the reluctant and the automated before any of them count against you. Every other item in this guide is maintenance. That one is the design decision: the guide to single and double opt-in weighs it, and the confirmation email template writes out the one message it sends.

What to watch, and where it is visible

When mail has already gone missing, the guide to why emails go to spam is the checklist to work through in order. Before that, deliverability work is mostly watching four or five numbers and reacting to a change in any of them, because a change is legible long before an absolute value is alarming. None of these needs a paid tool, and the most important of them cannot be bought: it is on the provider’s own dashboard, free, for whoever proves they control the domain. Check on a fixed schedule rather than when something feels wrong; weekly is enough for a small sender, and you are looking for a trend against your own history, per provider.

The short list, in the order a change in one should worry you:

• Spam complaint rate per provider, from the provider’s postmaster dashboard. Under 0.1% is the target Google’s guidelines state, and a move from 0.02% to 0.08% is a warning even though both are inside the threshold.
• Hard bounce rate per send. A jump means either a list you did not confirm or a suppression list that is not being applied.
• DMARC aggregate reports, read rather than collected. They are the only place you learn that some fraction of your mail is failing alignment, and the only place you see mail sent under your domain that is not yours.
• Click rate on a domain you control, as the engagement signal, with replies beside it. Not opens.

When to send: whose clock matters more than which hour

Timing questions divide into three, and only one of them is usually asked. Which hour, which day, and in whose time zone. The third is the one with a real answer and the one most often decided by accident, because the default in most tools is the sender’s clock, or the server’s, and a server clock is generally UTC.

Send in the reader’s local time. A message sent at nine in the morning your time reaches a reader eight hours west at one in the morning, which is not a subtle penalty: it arrives at the bottom of a pile that accumulates overnight, and by the time that person looks at their mail it is under everything that arrived after it. Where local time is genuinely unknown, the least bad default is the time zone most of the list is in, stated as a decision rather than inherited from a server.

That is also the only timing choice with a mechanism behind it rather than a correlation. Nobody has to believe a study to accept that a message which arrives while somebody is asleep is read later, further down, alongside more competition.

For a course, the weekday question dissolves entirely

Best-day-of-the-week advice assumes a broadcast: one message, everybody at once, one calendar day to choose. A sequence counted from each person’s own start does not work that way. Somebody who confirms on a Thursday gets day two on Friday and day five on Monday; somebody who confirms on Saturday gets an entirely different overlay of the sequence onto the week. There is no single weekday to optimise, because every subscriber is on their own.

This has a pleasant side effect for deliverability. A broadcast concentrates a month of volume into one hour, which is the pattern that looks least like ordinary mail to a receiving provider; a sequence fans out one message per subscriber per day, spread across whichever days people happened to sign up. The volume smooths itself without anybody configuring a throttle.

What replaces the weekday question is a cadence question, and that one is worth thinking about. One message a day is what a five-day course promises, and it is the cadence a reader agreed to when they signed up. Skipping a day to avoid a weekend breaks the promise more expensively than a weekend send breaks anything, because the reader counted.