The problem this solves
Most failed cold campaigns fail before the first word is read, in the DNS records and reputation signals that decide whether mail reaches an inbox or a spam folder. The cruelty is the silence: the sending tool reports 'sent', the metrics show a catastrophic open rate, and the team responds by rewriting subject lines when the actual problem is a misaligned DMARC policy nobody has looked at since the domain was configured.
Authentication is fiddly in a specific way: SPF, DKIM, and DMARC each have their own syntax, their own failure modes, and an alignment relationship between them that is easy to get subtly wrong. A record can exist and still fail - too many DNS lookups in the SPF chain, a DKIM selector that does not match the sender, a DMARC policy that quarantines your own mail. The knowledge to diagnose this lives in deliverability specialists, and most outbound teams have none.
The stakes compound with volume. A misconfigured domain sending ten emails learns a cheap lesson; the same domain sending a thousand-lead campaign torches its reputation in an afternoon, and recovery takes weeks of careful warming. Five minutes of preflight is the cheapest insurance in outbound, and it is skipped almost universally because nobody owns it. Making it a mission gives it an owner.
How the mission runs
- Audit SPF, DKIM, and DMARC. Email Deliverability inspects your sending domain's authentication records: whether each exists, whether each is syntactically valid, and whether they align with each other and with your actual sending setup. Every finding is recorded with the current value and what correct looks like.
- Check the failure modes that hide in valid-looking records. Beyond existence, the audit catches the subtle breaks: SPF lookup-limit violations, DKIM selectors that do not match the mail actually sent, DMARC policies that conflict with your sending pattern. These are the misconfigurations that pass a casual glance and still route your campaign to spam.
- Run an inbox-placement test through Instantly. A placement test sends through Instantly to observe where your mail actually lands - inbox, promotions, or spam. Placement is the ground truth that pure DNS auditing cannot see, because reputation and content factors only reveal themselves in a live delivery.
- Deliver the go or no-go with exact fixes. The verdict is binary and justified: go, or no-go with the precise changes required - the exact record values to set, in DNS-ready form, ordered by impact. No deliverability lecture, just what is broken, what to paste, and what to re-test after.
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 clear verdict on your sending domain before the campaign spends it: the full authentication audit with each record's current state, the inbox-placement result from the live test through Instantly, and - if anything fails - the exact DNS-ready fixes ordered by impact. Green means launch with confidence; red means twenty minutes of fixes now instead of weeks of reputation recovery later.
Make it yours
- Make it a standing gate: every new campaign in your workflow runs the preflight first, and launch waits on green.
- Point it at a fresh secondary sending domain before its first warm-up send, when configuration mistakes are cheapest to fix.
- Re-run mid-campaign when reply rates sag unexpectedly, to rule out a placement problem before rewriting copy that was never the issue.
Frequently asked questions
What does the placement test add beyond the DNS audit?
Ground truth. Records can be perfectly configured while reputation or content factors still push mail to spam, and only a live send observed on arrival reveals that. The audit explains what to fix in configuration; the placement test tells you where mail actually lands today.
Can the agent apply the DNS fixes for me?
The mission delivers the exact record values ready to paste, and the application stays with whoever controls your DNS - domain records are infrastructure, and changes there deserve deliberate human hands. Re-run the preflight after applying to confirm everything resolves green.
How often is the preflight worth re-running?
Before any significant send, after any DNS or sending-tool change, and whenever performance drops without an obvious copy explanation. Reputation drifts with sending behavior, so a domain that passed in March is not automatically a domain that passes in June.