Form REQ-DELIV — patient intake
Is your domain in spam, or just your content?
Sixty-second forensic check of the authentication layer underneath your sends. We probe DNS for SPF, DKIM, DMARC, MTA-STS, BIMI, and three public blacklists — show you the actual records — and tell you exactly which gap is costing you.
No signup required to see the score. Capture happens only after you've seen what's wrong — and only if you want the full remediation plan.
§ Protocol — what the lab examines
Eight discrete tests. Real DNS. Real records returned to you.
Most "deliverability checkers" run one or two surface lookups and gate the rest behind a signup. We do not. The eight tests below run end-to-end against your live zone the moment you submit, and the result page shows you the exact TXT/MX records they returned — so you can fix things yourself, or hand the report to someone who can.
The order matters. MX must resolve before the domain can receive mail at all. SPF authorizes which servers send for you. DKIM proves cryptographically that the message wasn't tampered with in transit. DMARC tells receivers what to do when SPF or DKIM fail — and equally important, where to send aggregate failure reports so you can see who's spoofing your domain. MTA-STS forces TLS upgrades between mail servers, closing a downgrade-attack vector most senders never look at. BIMI shows your logo in supporting inboxes once your DMARC is strict enough. DNSBL listings tell you whether your MX IP is on a public blocklist that major receivers consult.
When a check fails, the report names the specific record that's missing or malformed — and the specific fix. When a check warns, the report tells you why partial credit was issued. There is no middle ground where we say “needs improvement” without pointing at the line.
§ Specimen — what your report will look like
Authentication is missing or broken at the foundation. Sending from this domain right now is actively burning whatever reputation remains.
| Test | Finding | Status |
|---|---|---|
| MX | 3 hosts resolved (primary: aspmx.l.google.com). | PASS |
| SPF | No SPF record. Receivers can't verify which servers are allowed to send. | FAIL |
| DKIM | Probed 19 common selectors. None resolved a v=DKIM1 key. | FAIL |
| DMARC | Policy is p=none (monitor only). Spoofers can forge your domain with no consequence. | WARN |
Your actual report shows all 8 tests with the real record values returned from your zone, plus a prioritized prescription of the specific fixes.
§ Attending technician's note
In May our own domain got jailed. The DKIM public key was sitting at _dmarc — the DMARC slot — instead of zmail._domainkey, where Zoho actually signs with. Receivers looked up the selector, got NXDOMAIN, and silently failed every signature. Combined with a 7.5% historical bounce rate from a bad list import, Gmail decided we weren't a real sender.
Outbound paused for 14 days. We rebuilt the DNS, scrubbed the list, re-warmed from a single seed address per day. By the time we were back at full volume the recovery sequence had taken six weeks.
The audit you just ran is the audit I wish I'd run beforesending the first email from a new domain. It would have caught the DKIM-location bug in the first sixty seconds. If your report comes back green, that's the whole story — go build. If it comes back red, you now have the same prescription a sender three months ahead of you would have to follow anyway.
— Casey Hamilton, Surfscaler · Rochester, NY
§ Referral options — once you have the report
Two ways we can help, depending on what your report says.
Door 1 — if your score is under 65
Inbox Rescue — done-for-you remediation
We rebuild the authentication layer, scrub the list of bad addresses, re-warm the domain on a slow schedule, and stand guard while reputation rebuilds. The same playbook we ran on our own domain after we got jailed.
See the Inbox Rescue page →Door 2 — if you're building outbound from zero
Cold Email — outbound system, deliverability baked in
Engine we run on ourselves. Lead scoring, archetype-driven copy, two-way SMS routing, seed-engagement, reply detection, and the same deliverability audit baked into the daily watchdog so your sender doesn't silently slip.
See the Cold Email page →§ Standing orders — questions the lab answers in advance
- 01.
What does this actually check?
Live DNS lookups against your domain: MX records, SPF (presence, syntax, lookup count, terminator), DKIM (we probe 19 common selectors across Google, Zoho, Microsoft 365, SendGrid, Mailchimp, Mandrill, and generic defaults), DMARC (presence, policy strength, rua reporting), MTA-STS, BIMI, and public DNSBL listings (Spamhaus zen, Spamcop, Barracuda Central) on your primary MX host's IP. Everything we read is real and shown to you in the actual record values.
- 02.
How is the score calculated?
Published weights, no black box: MX 15, SPF 15, DKIM 15, DMARC presence 15, DMARC policy strength 10, MTA-STS 10, BIMI 5, DNSBL clean 15. Total 100. Each test contributes its full weight on pass, a partial amount on warn, zero on fail. The result page itemizes exactly what you earned on each test.
- 03.
What can't this audit see?
Gmail Postmaster reputation, Microsoft SNDS, per-IP warm-up history, and per-receiver private spam-filter scores — those need account-level access to your sending infrastructure. A clean 100/100 here is necessary but not sufficient. Inbox placement at Gmail also depends on engagement, content, and send velocity, which authentication alone cannot fix.
- 04.
I'm signing with a custom DKIM selector — will you miss it?
Possibly. We probe 19 of the most common selectors (google, zoho, zmail, selector1, selector2, s1, s2, k1, k2, k3, mandrill, smtpapi, default, mail, dkim, mxvault, mta, m1, zb01). If your selector is outside that set, we will report DKIM as missing when it isn't. Tell us the selector and we'll re-run targeted.
- 05.
Is this a sales pitch for something?
If your domain is healthy, you'll get a clean report and probably never hear from us. If your domain is jailed or compromised, you'll see two referral options at the bottom of the result page — one for done-for-you remediation, one for our cold-email system that bakes deliverability in. We sell that work. The audit is the audit, and the math runs the same whether you click anything afterward.
- 06.
Why does Casey care about this specifically?
Our own domain got Gmail-jailed in May 2026. A misplaced DKIM record at the wrong DNS location (the public key was sitting at _dmarc instead of zmail._domainkey, breaking selector lookup) plus a 7.5% historical bounce rate convinced Gmail we weren't trustworthy. It took 14 days of pause, a full DNS rebuild, list hygiene, and slow re-warm to crawl back. This audit is the tool we wish we'd had before any of that happened.
- 07.
How often should I re-run this?
Once a quarter as baseline. Immediately after any DNS change. Immediately if reply rate or open rate drops more than 20% in a week — that's usually deliverability before it's a content problem.
- 08.
What's the difference between MTA-STS and BIMI?
MTA-STS forces TLS encryption between mail servers (no downgrade attacks). BIMI displays your logo next to messages in Gmail and Yahoo, conditional on DMARC at quarantine-or-stricter plus a Verified Mark Certificate. MTA-STS is hygiene; BIMI is positioning. We score MTA-STS higher because real attackers exploit the absence.