A deliverability audit that goes down to the sending infrastructure.

What changed underneath email between 2024 and 2026?

For most of email’s history the largest mailbox providers nudged non-compliant senders. They stopped nudging and started refusing. Google and Yahoo set the same bar on 1 February 2024: any domain sending 5,000 or more messages a day to their users needs SPF, DKIM and DMARC, has to keep spam complaints low, and must offer one-click unsubscribe on promotional mail. Microsoft adopted the same authentication floor on 5 May 2025, with its own hard-rejection code for mail that misses it. Then, in November 2025, Google escalated Gmail from temporary deferrals to permanent rejections for non-compliant bulk mail.

Three details in those rules trip up senders who skim them. The 5,000-a-day threshold is counted per provider, not across your whole program, so 4,000 daily messages to Gmail and another 4,000 to Outlook leaves you under each line while feeling like a high-volume sender. The bulk classification, once earned, does not expire if your volume later drops. And non-compliant mail is not filtered to spam — it is bounced at the SMTP level, with a code that tells you exactly which requirement failed. The table below sets the three providers side by side, because the principles rhyme but the specifics do not.

One more shift sits behind the rules and matters more than any of them. Authentication and a clean complaint rate are now the price of admission, not the thing that wins the inbox. Mailbox providers lean on engagement — opens, replies, folder moves, deletions without opening — because those signals are far harder to fake than a DNS record. Google has said its systems block on the order of 15 billion unwanted messages a day. The practical consequence for a serious sender is that you can pass every technical check and still lose placement, because the audience has stopped engaging and the filter has noticed. A deliverability audit reads the technical layer and the behavioural one together, since in 2026 they are scored together.

What are the five layers a deliverability audit reads?

We work outward from the message to the infrastructure, because that is the order in which problems compound. A content issue on top of a reputation problem on top of a broken authentication record is three findings, and fixing the visible one first usually wastes a warm-up cycle. These are the layers, and what tends to be wrong in each.

1. Authentication and alignment. SPF, DKIM and DMARC present, valid, and — the part most checks miss — aligned with the From domain. We look for SPF that exceeds the ten-lookup limit, DKIM keys still at 1024 bits where 2048 is now expected, selectors pointing at nothing after a DNS change, and a DMARC record stuck on p=none with no path toward enforcement.
2. Reputation, domain and IP. Domain reputation outlives IP reputation and follows you across provider changes, so we read it first. We pull Postmaster Tools and SNDS, check blocklist status as a floor rather than a verdict, and look for the slow erosion that a complaint-rate dashboard hides.
3. List and data quality. The single most controllable factor, and the most neglected. We look at how addresses are collected, validated and suppressed, at bounce handling that actually feeds back into the next send, and at the dead weight that drags engagement metrics down before content ever gets a vote.
4. Content and engagement. Not subject-line cosmetics — the structural signals: a healthy text-to-link ratio, working and visible unsubscribe paths, sane image and tracking-domain setup, and whether the program is segmented so that engaged and unengaged recipients are not sent the same volume at the same cadence.
5. Sending infrastructure. The layer most audits never open: how your IPs and domains are architected, whether streams are separated so a marketing misfire cannot sink transactional mail, how warm-up and volume ramps are paced, and whether your MTA’s throttling and backoff respect what the providers actually return.

# Does SPF stay within the 10-lookup limit, or silently overflow?
$ dig +short TXT example.com | grep spf1
"v=spf1 include:_spf.google.com include:sendgrid.net include:mktomail.com ~all"
# 11 lookups across the includes — over the limit, SPF returns permerror

# Is DMARC enforcing, or stuck on p=none with no path forward?
$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:[email protected]"
# p=none: reporting only — alignment failures are seen, not acted on

Where do most audits stop, and where does this one start?

A typical deliverability check reads the first four layers and calls the job done. That is enough to catch a missing DMARC record or a noisy list, and for many senders it is the right depth. It runs out of road precisely when the technical fundamentals are clean and placement still slips, because the cause has moved below the layer the check can see — into how the mail is actually being pushed onto the wire.

That fifth layer is our home ground. The same expertise that tunes a PowerMTA or KumoMTA estate — per-provider throttling, connection limits, VirtualMTA separation, backoff that recovers instead of looping — is what reads the infrastructure layer of a deliverability audit. A connection rate set higher than a provider tolerates earns deferrals that no amount of content work will fix. A single shared IP carrying both transactional and bulk streams ties two reputations together so that one bad campaign poisons the receipts. These are deliverability problems with their roots in operation, and they are invisible to a check that stops at the headers.

We do this without a stake in the answer. We resell neither IP space nor an ESP relationship nor a particular MTA, so the report has no commercial pull toward a product. For a market where much of the deliverability advice on offer is attached to the thing being sold, an independent reading is the point.

What do the monitoring tools show, and where do they stop short?

No single source tells the whole story, and treating any one of them as the verdict is how senders end up chasing the wrong fix. We triangulate across the provider tools and the public signals, and we are explicit about the blind spot in each. Where two sources disagree, the provider’s own data outranks any third-party panel.

How does the audit run?

The engagement is short and structured, and it does not touch your sending until you decide to act on what it finds.

1. Scope and access. We agree which domains, streams and providers are in play, and you grant read access to DNS, recent logs, Postmaster Tools and SNDS. No credentials to your sending platform are required to start.
2. Read the five layers. We work from authentication out to infrastructure, recording each finding with the evidence behind it rather than a checklist tick.
3. Measure against 2026 enforcement. Every finding is weighed against how Gmail, Yahoo and Microsoft actually filter now — the thresholds, the codes, the per-provider rules — not against last year’s best practice.
4. Rank by cost to placement. Findings are ordered by how much inbox they are losing you, so the first thing you fix is the thing that moves the number most.
5. Deliver and walk it through. You receive a written assessment and a working session to talk through it. What you do next, and with whom, is yours to decide.

What you receive

The deliverable is a written assessment, built to be used. Each finding is stated with its evidence, ranked by the placement it is costing, and labelled by the kind of work it needs: a DNS change you can make this afternoon, a sending-pattern adjustment, a data project, or a structural decision about infrastructure. Where a fix is a ten-minute edit, we say so. Where the honest answer is that the architecture is fighting you, we say that too, and we show the data behind it.

What you do not receive is a single reputation score and a calendar link. A number on its own tells you that something is wrong without telling you what, and it is the format favoured by audits whose real product is the upsell. The document is yours to keep and act on, in any order, with our help or without it.

The structure of the report follows the five layers rather than a generic checklist, so each finding is already attached to the layer it belongs to and the order in which it should be addressed. A broken authentication record at layer one is flagged ahead of a content tweak at layer four, because fixing the content while the authentication is failing changes nothing a receiver can see. Inside each layer, findings carry a plain estimate of effort and expected placement impact, so the person approving the budget can read the same document as the engineer making the change and reach the same conclusion about what to do first. That shared reading is most of the value: a deliverability problem usually persists not because nobody can fix it, but because the team cannot agree on which of five plausible causes to spend the next two weeks on.

When should you run a deliverability audit?

A deliverability audit earns its cost in a few recognisable situations. Several of these together is a strong signal that the distance between your program and the current rules has grown wide enough to be taxing every send. The cost of waiting is rarely a sudden block; it is the quiet compounding of a placement rate that slips a point or two a month until a campaign that once reached eighty-five percent of inboxes is reaching sixty, with every downstream metric — opens, clicks, revenue per send — scaled down by the same hidden factor. An audit is cheapest to act on when the drift is small, because the reputation it rebuilds is rebuilt in days rather than the weeks a deep slide demands. The free 25-point audit exists for exactly that reason: it is a fast directional read on whether the deeper engagement is worth scoping, before any figure is named. Most senders who run it find that one or two of the five layers carry the bulk of the loss — which is the point of running it: the audit narrows down where the budget should actually go, instead of spreading a fixed-price rebuild evenly across five layers when, in practice, only one or two of them were ever the thing actually dragging inbox placement down.

• Open and reply rates drifting down slowly while delivery stays high — the signature of placement erosion rather than a list problem.
• A clean spam-complaint rate paired with falling engagement, which usually points below the content layer.
• A migration, a new IP, a domain change or an ESP switch that went in and was never validated against real inbox placement.
• Bounce codes in the 550 5.7.x family appearing in your logs, which mean a 2026 requirement is failing outright.
• Mail landing in spam for the same recipients who used to open it — a reputation or engagement signal, not a content one.
• Growth into Spanish- or Portuguese-speaking markets, where local provider behaviour and list practices differ from the English-language playbook most guides assume.

None of these is proof on its own. Taken together, they are the cheapest possible warning — cheaper than the delivery incident they tend to precede, and far cheaper than discovering after a send that a sixth of your reach has been quietly going nowhere.