The problem this solves
Deliverability fails silently, which is what makes it dangerous. The sends still go out, the platform still reports them sent, and the only visible symptom is a slow sag in opens that gets blamed on subject lines. Meanwhile the actual cause sits in DNS: an SPF record that broke when someone added a tool, a DKIM signature that was never set up for the sending domain, a missing DMARC policy that mailbox providers now read as a reason for suspicion. By the time someone checks, months of email have been quietly filtered from view.
The rules also moved. Major mailbox providers now hold bulk senders to explicit requirements - authentication on all three protocols, visible one-click unsubscribe, spam-complaint rates under hard thresholds - and falling short means filtered or rejected mail regardless of how good the content is. Most teams learned these rules exist from a deliverability incident, and most fix attempts stall in the gap between knowing something is wrong and knowing which DNS record, exactly, to publish.
What a rescue actually requires is unglamorous precision: test every authentication layer, compare the domain's reality against the bulk-sender bar, and produce fixes specific enough to paste - the record, the host, the value. Then a recovery plan, because a domain that has been damaged rebuilds trust through volume discipline over weeks rather than through a single corrected record, and the discipline needs to be written down to survive the first busy send day.
How the mission runs
- The domain's authentication is tested end to end. Email Deliverability checks the live DNS reality of your sending domain: whether SPF exists and covers your actual senders without exceeding lookup limits, whether DKIM signs your mail with valid keys, and whether DMARC exists, what policy it declares, and whether alignment actually passes.
- The setup is graded against bulk-sender rules. Findings are compared to the requirements major mailbox providers enforce for bulk senders: full authentication, one-click unsubscribe, and complaint-rate expectations. Each gap is graded by consequence - what is actively causing filtering today versus what is a risk waiting for volume - so urgency is explicit.
- Every problem is explained in plain language. The audit states what is broken and why it matters in words a non-specialist can act on: what this record does, what its absence makes mailbox providers assume, and what fixing it changes. No finding is delivered as jargon plus a severity color and nothing else.
- The fix list is literal: records to publish. For each gap, the exact DNS record to publish - type, host, value - ready to paste into your DNS provider, with sequencing where order matters, such as moving DMARC policy from monitoring toward enforcement in stages rather than overnight. The fix list is written to be executed by whoever holds DNS access.
- A warm-up plan maps the recovery. Because trust rebuilds gradually, the audit closes with a volume plan: where to start after fixes, how to favor engaged segments first, what to watch as evidence recovery is holding, and how quickly to return to full sends. The plan turns the fix from a hopeful change into a managed recovery.
The prompt
This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.
What comes back
A complete deliverability audit for your domain: pass-and-fail reality across SPF, DKIM, and DMARC, your standing against the bulk-sender requirements, every problem explained in plain language, and a literal fix list of DNS records ready to publish - plus a staged warm-up plan for rebuilding sender trust at controlled volume. The whole audit is diagnosis and prescription, executed by you or your DNS admin.
Make it yours
- Run it before a send-volume jump - a product launch or list migration - so the infrastructure is verified in advance rather than diagnosed post-incident.
- Audit subdomain strategy alongside: whether separating marketing and transactional mail onto distinct subdomains would isolate reputation risk for your situation.
- Schedule a quarterly re-audit that diffs against this baseline, catching records broken by tool changes before they show up as filtered mail.
Frequently asked questions
Does the agent change my DNS records itself?
No. The audit produces exact records to publish, and publishing them stays in your hands or your DNS administrator's. DNS changes affect all mail from your domain, so the boundary is deliberate: complete diagnosis and paste-ready prescriptions from the agent, execution and verification by the humans who own the zone.
We send through several tools - does the audit account for that?
Yes. A multi-tool sending stack is the most common way SPF breaks, through lookup limits and forgotten includes. The audit maps which services legitimately send as your domain, checks that authentication covers each without exceeding limits, and flags senders in your records that nobody can identify anymore.
How fast does deliverability recover once the fixes are live?
Authentication fixes take effect quickly, but filtering decisions reflect accumulated reputation, so inbox placement recovers over weeks of consistent, disciplined sending rather than instantly. That is what the warm-up plan manages: engaged segments first, gradual volume, and the signals that show recovery is real.