What is email deliverability
Guide · Glossary & Definitions · 5 min read · last verified 2026-08-11
Email deliverability is whether a message you send actually reaches the recipient's inbox — as opposed to a spam folder, a promotions tab, or nowhere at all — and it sits underneath every other email metric a dashboard reports. An open rate is only ever calculated against mail that arrived and rendered; mail that never reached the inbox does not lower the open rate, it simply never enters the count. That is how a sending program can look stable on a dashboard while its inbox placement quietly erodes underneath it, unmeasured by the one number everyone is watching.
SPF, DKIM, and DMARC: three different questions a receiving system asks
The three acronyms answer three separate questions, and treating them as interchangeable is the fastest way to misdiagnose a delivery problem. SPF (Sender Policy Framework) is a published list, attached to a domain, of which servers are allowed to send mail claiming to be from it — a receiving system checks the list and treats mail from an unlisted server as suspect. DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each message, letting the receiving system verify that the content and headers were not altered in transit and genuinely originated from a server holding the matching private key — tamper-evidence, not a permissions list. DMARC sits above both and states an enforcement policy: what a receiving system should do when a message fails SPF, DKIM, or both — let it through, quarantine it, or reject it outright — plus where to send reports describing what happened. Put in one line: SPF is who may send, DKIM is proof nothing was altered, DMARC is what happens when either check fails.
The reporting half of DMARC is worth using, not just configuring, and it is the one step here a team can take this week. A record published in monitor-only mode — asking receiving systems to report what they saw without changing how they treat the mail — invites aggregate reports back from the receiving systems that support them, and each report names the sources sending as your domain and whether their mail passed authentication. If something is sending as you that nobody remembers authorising, an old invoicing tool or a regional office's own server or a platform connected long ago and never disconnected, that report is where it surfaces. Reading those reports before tightening the policy to quarantine or reject is what keeps a legitimate internal sender from being the first thing the stricter policy blocks.
Deliverability is reputation, accumulated over time
None of the three settings above measures whether anyone wants the mail. That judgment is made continuously by the receiving system, which watches signals correlated with wanted versus unwanted mail from a given sender — opens, replies, deletions without opening, moves to a spam folder, complaint clicks — and uses the accumulated pattern to decide how to treat that sender's future mail, independent of any single message's content. Exactly which signals matter, and how heavily each is weighted, is not published by any mailbox provider and is understood to shift over time without notice, so a specific claim about current thresholds is out of date before it is written down. What stays stable is the mechanism, not the numbers behind it: reputation is built from a sending history, not configured in a settings screen.
What poisons a sending reputation faster than authentication can fix
A list built from purchased or scraped addresses produces recipients with no reason to open anything, and a share of those addresses are no longer live at all — someone changed jobs, an inbox went dormant, or the address is one of those understood to be seeded as a trap, planted where only a harvester would find it so that mail arriving there marks a sender who never collected consent. Like the reputation signals above, that practice is described from outside rather than published by anyone, which makes it a mechanism to reason from and not a specification to rely on. A lead magnet that collects an address through genuine interest is a structurally different list from a bought one, because consent is close to the exact signal engagement-based reputation is trying to approximate after the fact. Sudden changes in sending pattern do similar damage: a new domain sending a large batch immediately, or an established sender's volume spiking without warning, resembles what a compromised account looks like to a filter �� regardless of what the message inside says. Authentication repairs neither problem. SPF, DKIM, and DMARC only prove a message truthfully came from the domain it claims; they say nothing about whether that domain has a history of sending mail people want. A fully authenticated sender with a poor reputation is not a mystery to troubleshoot. It is a correctly authenticated sender nobody wants to hear from.
Authentication proves identity; it does not buy trust
The two halves of this article are necessary and insufficient for each other, which is worth stating directly. Without authentication, no reputation can accumulate at all, because a receiving system cannot reliably attribute a stream of mail to one consistent sender — impersonating a domain is close to trivial, so nothing about an unauthenticated message reliably identifies the history a filter would need to score it. With authentication alone, reputation still has to be earned the slow way, by sending mail people want; passing SPF, DKIM, and DMARC proves who is speaking, not that anyone asked to be spoken to. The volume math behind cold outbound compared with a warm introduction matters here too: a cold program starts mailing unproven addresses at real volume, which is a change in sending pattern by definition, while a list that grows and sends at a steady rate presents no change for a change-detector to register at all.
The plumbing underneath the channel's value
Whether an archived newsletter helps a brand get cited in AI-generated answers is a separate question entirely from whether any single issue reaches an inbox at all — that piece is about what happens once content is published somewhere public; this one is about whether the email itself gets delivered in the first place, a condition that has to hold before an open rate, a reply, or an archive can mean anything downstream. And getting into the inbox says nothing about whether the message deserves to be there: what to put inside a cold email once it can arrive is a separate craft, and a well-authenticated sender with nothing worth reading still gets marked as spam by the people receiving it. Reputation runs on both halves of the problem at once — the plumbing that lets a message arrive, and the substance that decides whether it should have.