Email deliverability for small senders: authentication and reputation

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. The step-by-step version, with the records written out, is a separate guide in this cluster; the thing to take from here is that all three are a floor and none of them is optional any more.

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.

The headline items are three. Authenticate your mail with SPF and DKIM, 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. The authentication floor applies to everyone: unauthenticated mail has been refused rather than filtered, with Gmail returning a 5.7.26 error, since the same round of changes. 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 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 guide on the GDPR in this cluster takes that apart properly.

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. Both providers’ guidance says the same thing in general terms: increase volume gradually and watch the signals as you go. The specific ramp is not a published figure, and anyone quoting one to three decimal places is quoting a habit.

The shape most senders use is to begin with a few hundred messages a day to the addresses most likely to engage, hold for two or three days, then roughly double every two to three days as long as complaint and soft bounce rates stay flat, reaching a steady state in something like two to four weeks. If a rate moves, you hold rather than push through. A course sender gets part of this for free, because a course fans out one message per subscriber per day rather than one blast to everyone.

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, and there is a guide on it, and on the confirmation email itself, in this cluster.

What to watch, and where it is visible

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 the bulk sender rules 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.