Email Deliverability Is a Reputation, Not a Setting
When email stops arriving, the first response is almost always to look for a setting. Something must be switched off. Something must be misconfigured. And often something is — but treating deliverability as a configuration problem explains why so many businesses fix the configuration and still land in spam.
Deliverability is better understood as a reputation held by your sending domain, evaluated continuously by receiving mail systems, and only partly under your control. Configuration is how you become eligible for a good reputation. It is not the reputation itself.
The problem the standards were built to solve
The reason any of this exists is a design decision made when email was small and trusting. The protocol places no restriction on what a sending machine claims to be. As the specification for Sender Policy Framework puts it plainly, "Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the 'MAIL FROM' of a message or the domain given on the SMTP HELO/EHLO commands" [1].
That is worth sitting with. By default, anyone can send mail claiming to be from your domain, and nothing in the original protocol stops them. Every deliverability mechanism since is an attempt to bolt an answer onto that gap without breaking the mail that already works.
SPF is the first layer: a published list of the machines allowed to send on your behalf. DKIM is the second: a signature proving a message really came from where it says. DMARC is the third, and it is the one that turns the first two from information into policy — a mechanism "by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling" [2].
Note what DMARC actually gives you, because it is routinely misdescribed. It does not make your mail arrive. It tells receivers what you would like done with mail that fails the checks, and — this is the underused half — it asks them to report back on what they saw. Those reports are the only direct visibility most senders will ever have into what the rest of the internet thinks of their domain.
Why correct configuration is not sufficient
You can have all three records published correctly and still land in spam, and this is the point at which most guidance runs out.
Authentication answers "is this really from them". It does not answer "do recipients want this". Receiving systems care about the second question at least as much, and they answer it with signals you do not control and cannot see directly: how often your mail is opened, deleted unread, marked as spam, or replied to. Reply rate is a particularly strong positive signal, because it is expensive to fake.
This is why two businesses with identical DNS records get different results. One sends to people who asked for it. The other bought a list. The configuration is the same; the reputation is not.
What actually damages a domain
Sending to addresses that no longer exist. A high bounce rate is read as a sign that the list was not maintained, or was never earned. Old lists decay at a surprising rate — people change jobs — and a list that has sat unused for a year will bounce hard the day you use it.
Sending to people who forgot they agreed. Consent has a half-life. Someone who ticked a box eighteen months ago and has heard nothing since does not remember you, and the fastest way for them to resolve that confusion is the spam button. This is the mechanism behind the odd-looking rule that sending more often can improve deliverability: not because volume is good, but because recognition is.
Mixing message types on one domain. Your password reset and your promotional newsletter have different audiences, different engagement patterns, and different consequences when they fail. Sent from the same domain, the marketing mail's reputation drags the transactional mail down with it, and the first thing you notice is that people cannot log in.
Making unsubscribing hard. Every unsubscribe you prevent becomes a spam complaint instead, and a spam complaint costs you far more. The link is not a leak in the bucket. It is a pressure valve.
The part that is about restraint
The uncomfortable conclusion is that deliverability is mostly downstream of whether your email is wanted, which makes it a content and consent problem wearing a technical costume.
That has a practical implication for what you collect and why. An address gathered without a clear purpose is an address that will not engage, and a list assembled speculatively is a list that will damage the domain it is sent from. The rule we apply to data generally — not collecting it speculatively "in case it is useful later" [3] — is unusually literal here: every address you keep without a reason to use it is a small, permanent liability against your ability to reach the addresses you do have reason to use.
Volume is a signal, and sudden volume is a bad one
One more mechanism is worth understanding, because it catches businesses doing everything else right.
A domain that has sent forty messages a day for a year and suddenly sends forty thousand has done something that looks, from a receiving system's point of view, exactly like a compromised account. There is no way for the receiver to distinguish "this business finally launched its newsletter" from "someone got into their mail server", and the safe assumption is the second one.
The fix is unglamorous: increase volume gradually, over weeks rather than in a single send, and start with the segment most likely to engage. Your most recent, most active recipients establish the pattern that carries the rest. Sending to the coldest part of the list first does the opposite, which is unfortunately the instinct, because that is the part that feels most overdue.
The same logic applies to a new domain with no history at all. No history is not neutral — it is an absence of evidence in a system that treats evidence as the whole basis for the decision. A new sending domain needs a few weeks of small, well-received sending before it is trusted with anything important, which is a good reason not to move domains a fortnight before a launch.
A workable order of operations
Publish SPF, DKIM and DMARC, and read the DMARC reports rather than filing them. Separate transactional mail from marketing mail at the domain level. Remove hard bounces immediately and stop mailing people who have not opened anything in a year. Make unsubscribing a single click. Then send things people are glad to receive, at a rhythm they can predict.
The first four are a weekend. The last one is the job. Anyone offering to fix deliverability without touching it is selling you a setting.