An email deliverability audit has one job: prove that your mail reaches the inbox at the volume you plan to send, before you hire reps or buy tooling around it. A spam score cannot prove that, because it grades a single message and says nothing about your domains, your data or the infrastructure carrying the load.
So the way I frame it is as a pipeline-risk check. If outbound is going to supply a third of next quarter's meetings, the audit answers one question: what is the chance that it quietly doesn't?
Why a spam score is the wrong deliverable
Buyers we talk to bring a recurring worry: they have no internal experience running outbound at high scale and they know domain and inbox setup is where it goes wrong. That worry is correct, and a score does not address it.
Take a customer who sent roughly 12 to 13k emails and could not point to a single clear conversion. The copy might have been fine. The roles might have been wrong, some clicks might have been security scanners, and some mail might never have reached a human. A spam score separates none of those. An email deliverability audit has to.
The three proofs: domains, data and sending
I call these the three proofs. The audit passes only if all three hold.
- Domains. Your primary domain is protected from the experiment, secondary domains are authenticated and aligned under DMARC, and each has a reputation history you can read.
- Data. The list is verified, the roles match your ICP, and bounce risk is known before the first send.
- Sending. Mailbox count, per-mailbox volume and ramp schedule fit the domain's age, and one bad domain cannot drag the others down.
Most of the checklist-style guides cover authentication and blacklists well, so I won't repeat them. Authentication passing is the entry ticket. It tells you nothing about whether you can scale.
The data proof is the one teams skip, and it is the same discipline as a CRM cleanup. A broken portal looks very different from a rebuild quote once someone reads the underlying records, and a list works the same way. Bad records inflate bounces, and bounces damage the domain you need.
Email deliverability audit thresholds that green-light scaling
The common gap in the public guides is the pass/fail line. Here are the numbers we use. The first comes from a mailbox provider; the rest are my rules of thumb, not industry law.
| Check | Green light to scale | Source |
|---|---|---|
| Spam complaint rate | Under 0.10%, never near 0.30% | Google sender guidelines |
| Hard bounce rate | Under 2% on a verified list | Our rule of thumb |
| Warming | Three weeks minimum before ramping | Our rule of thumb |
| Volume per mailbox | Low tens of sends a day, then step up | Our rule of thumb |
Both major mailbox providers publish their own requirements for high-volume senders, so the same setup can pass on one provider and fail on the other. I don't have a universal volume ceiling for you. It depends on domain age, list quality and reply behavior, which is why the audit has to measure your sends rather than quote a number.
How to prove inbox placement by provider
Seed tests of 20 to 50 emails are a smoke alarm, not proof. They tell you the building isn't on fire today.
Proof means splitting results by receiving provider. Send a controlled batch to your real target mix, then read complaint and placement signals for Google and Microsoft separately. If 70% of your TAM sits on one provider, a blended placement figure hides the only number that matters. Google's own Postmaster reporting exists for exactly this reason.
The test the audit has to pass is a staged ramp with a stop rule agreed in advance: if complaints or bounces cross the line, volume freezes before anyone debates it.
Scanner clicks and why engagement can lie
Security scanners open and click links before a human does. Customers have told us they suspected exactly this: clicks that looked like interest and never became signups.
An audit that counts opens and clicks as proof of delivery will approve a broken setup. The better evidence is replies, positive replies, and attribution that survives scanner filtering. That is also why the audit belongs next to your reporting work. If you cannot tell a scanner from a buyer, you cannot defend the pipeline number, and a free revenue leak scan usually surfaces that gap early.
What the auditor should hand over
A trustworthy audit leaves you with evidence you can check, not a green badge. Ask for these:
- Per-domain authentication and alignment records, with the date they were read.
- Provider-level placement and complaint readings from your own sends.
- A list-quality report: verification results, role mix against ICP, duplicate and catch-all counts.
- The mailbox and volume plan, with the stop rule written down.
- A named owner for monitoring after the audit ends.
If a vendor cannot hand these over, the audit was an opinion.
Where to get help, and what I'd do first
For better or worse, this is not a weekend project. The audit is cheap compared with burning a domain and losing a quarter of outbound, but it needs someone who has seen failures at volume. We embed on this rather than hand over a report, and our deliverability infrastructure work is built around the same three proofs. If you want the checklist version, our email deliverability audit skill covers the mechanics.
My recommendation: run the audit before you scale, not after the first bad month. It follows the same logic as a migration case study, where the work is proving the foundation before you sign. If the domains, data and sending all pass, scale in steps. If one fails, you have just saved yourself a quarter.