Read enough deliverability job postings and a pattern shows up: half of them aren't asking for help with SPF and DKIM. They're asking someone to clean up the list.
TL;DR Half of deliverability job postings are really asking someone to clean the list. Across our scan of 117 companies hiring for the work, list hygiene recurs more than authentication does. Perfect SPF and DKIM cannot save a list full of dead addresses, and the two categories nobody screens for are carrier gateways and personal mailboxes.
We read a stack of "email deliverability" job postings this month. The surprise wasn't that companies are hiring for deliverability — we already knew they were. It was what they keep asking the hire to fix.
A veterinary-software company wants someone to own "deliverability issues, list hygiene, sender reputation." A DTC sports-commerce brand lists "bounces, complaints, sender reputation." A document-workflow platform running email at 100K+ scale needs "list health across four products." A supplements brand leads with the number that says it all: "1M+ email subscribers." Different industries, same quiet admission — the list is the job.
That cuts against the reflex. When mail starts landing in spam, teams reach for the sender side: SPF, DKIM, DMARC, IP warming. All necessary. None of it saves you if you're sending to a bad list. Mailbox providers grade you on who you send to and how they react — not just how cleanly the message is signed. You can run a flawless authentication setup and still wreck your reputation on addresses that bounce, complaints that pile up, and contacts who stopped opening a year ago.
And a list goes bad quietly. Email addresses are commonly estimated to decay at roughly 2% a month as people change jobs — a widely repeated industry rule of thumb we have not independently measured. Three things happen quietly, none of which your ESP reports:
None of it shows up in your ESP's green dashboards — the same silence that lets a broken SPF record go unreported for weeks — — until your inbox placement has already slipped and you're reverse-engineering why.
That's the other half of deliverability, and almost nobody checks it before a send — because checking has always meant handing your customer list to a vendor.
So we built the check to run without the upload.
List hygiene turned out to be one of only three responsibilities that recur across every title family in our hiring scan, alongside domain warm-up and authentication. Whatever the role ends up being called, cleaning the list is part of it: are companies really going to hand DNS administration to marketers?
The pattern in those job postings is really a maturity signal: companies discover deliverability through their list going bad, then hire someone to own it full-time. Increasingly, they won't hire for it — they'll instrument it. Knowing which addresses are dragging you down shouldn't require a new headcount, a data-sharing agreement, or a single upload.
Two categories break sends and almost no tool flags them: carrier gateways and personal mailboxes. Both come from published CC0 datasets rather than our own guesswork. An address like [email protected] is not an inbox — it is an email-to-SMS gateway, and the message arrives as a text. Per Christian Ricci’s CC0 carrier-domain dataset, there are at least 466 such domains across mobile and paging networks, current and retired. Long-form email renders badly on them, and carriers treat unsolicited email-to-SMS traffic as a complaint against your sending domain rather than a bad campaign. They deliver successfully, which is exactly why syntax checks never flag them.
The second is the share of a list that is a personal mailbox rather than a work address. Ricci’s companion CC0 dataset lists roughly 812 consumer mailbox domains beyond the obvious handful — Gmail and Outlook.com, but also several hundred regional and legacy freemail providers. That number is not a defect: for a consumer brand it is the whole audience. For a B2B sender who believed they were mailing companies, it is the first honest measure of what the list really is. Both are vendored at a pinned revision in our contact list reality check rather than fetched, so the check runs with the page.
| What it is | Deliverable? | Why it still costs you |
|---|---|---|
| Email-to-SMS gateway | Yes | Arrives as a text; carriers count unsolicited traffic as a complaint |
| Personal mailbox on a B2B list | Yes | Not a defect — but not the audience you thought you had |
Role account (info@) | Usually | Nobody owns it, so nobody engages with it |
| Dead domain (NXDOMAIN, null MX) | No | Hard bounce on every send until removed |
Run the check in the browser and never transmit the addresses at all. That constraint is why most regulated teams checked nothing: the moment list hygiene means handing a customer file to a third party, it becomes a procurement question and it stops happening. Parsing, deduplication, syntax, typo detection, role and gateway matching and the personal-mailbox share are all computable locally. Only a domain-level DNS lookup needs the network, and a bare domain name discloses nothing about who is on the list.
The useful output is not a score but a verdict per address, each carrying the action it implies:
Equally important is what a list check cannot tell you, and any tool that claims otherwise is guessing:
Because the sender side and the list side fail on different clocks, and only one of them announces itself. Authentication is binary and cheap to fix once: our scan of 117 companies hiring for this work found 92% publishing SPF and 97% publishing DMARC, so most teams have already cleared that bar. List quality is continuous, compounds, and shows up only in aggregate weeks later. That same scan found the smallest companies in the sample clean on authentication just 38% of the time against 79% for those over 1,000 people — and the list-side gap is wider still, because nothing measures it by default.
| Sender side | List side | |
|---|---|---|
| Fails | Binary — passes or does not | Continuously, by degree |
| Fix cost | Once, then it holds | Ongoing, every send |
| Who reports it | Any audit tool | Nothing, by default |
| Share already clean | 92% publish SPF | Unmeasured for most senders |
This is the same split we found when nobody owns whether email lands: the binary half gets done because it is visible, and the continuous half waits for someone whose job it is. The practical sequence is to fix what is binary first and then measure what is continuous. Confirm SPF, DKIM and DMARC with an authentication audit, profile the list before the next send, and then keep a watch on the records so the binary half does not quietly regress while you are working on the other one.
They fail differently. Authentication is pass or fail and it is cheap to fix once. List quality is continuous and it compounds: mailbox providers grade you on who you send to and how they react, so bounces, complaints and long-term non-engagement erode reputation even when every message is signed correctly. A flawless authentication setup does not survive a list full of dead addresses.
An address whose domain belongs to a mobile carrier, such as vtext.com or txt.att.net, which converts the email into a text message on the recipient's phone. There are at least 466 such domains across current and retired carrier and paging networks. They deliver successfully, which is why syntax checks never flag them, but long-form email renders badly and carriers treat unsolicited traffic as a complaint against your sending domain.
Everything that matters at the address level is computable in the browser: syntax, duplicates, typo detection, role accounts, disposable domains, carrier gateways and the personal-mailbox share. Only domain-level DNS lookups need the network, and a bare domain name discloses nothing about who is on your list. The addresses themselves never leave the page.
Roughly 2% of addresses per month go stale as people change jobs, which is about a fifth of a list per year. Abandoned addresses are also recycled into spam traps by mailbox providers, so an old list is not merely less effective over time; it becomes actively dangerous to send to.