How to read a WillItInbox deliverability report
Prioritize authentication, routing, headers, content, links, and infrastructure findings without treating the score as a delivery guarantee.
A WillItInbox report is not just a spam score. It is a fix order for the real message you sent through your app, ESP, sender domain, DKIM selector, tracking links, headers, and MIME output. Read the score last; read the evidence first.
For the wider operating model, see the tools hub after you finish the report. It groups the diagnostics, workflows, and API paths that turn one report into a repeatable process.
Start with the category that blocks receivers first
| Category | What to inspect | First action |
|---|---|---|
| Authentication | SPF, DKIM, DMARC, alignment, BIMI, ARC. | Fix DNS and ESP signing before changing copy. |
| DNS and infrastructure | PTR, HELO, TLS, MX, DNSBLs, sender host signals. | Correct sender infrastructure or investigate listings. |
| Headers | List-Unsubscribe, Message-ID, Date, From, MIME, Received chain. | Make the message compliant and machine-readable. |
| Content | Plain text, image ratio, trigger phrases, body structure. | Fix concrete findings instead of chasing generic word lists. |
| Links | HTTP URLs, shorteners, suspicious tracking, mismatched anchors. | Use HTTPS, branded tracking, and consistent destinations. |
Interpret severity as launch risk
- Critical: block launch for important sends. Examples: failed DKIM alignment, SPF permerror, broken sender identity, malformed DNS.
- Warning: fix before bulk volume when practical. Examples: missing List-Unsubscribe, weak DMARC policy, HTML-only MIME, HTTP tracking link.
- Info: document or schedule. Examples: optional hardening, context notes, or best-practice improvements.
Triage workflow for a real report
Working through findings
- 01
1. Confirm the message path
Make sure the report came from the same app, ESP, From domain, Return-Path, DKIM selector, tracking domain, and template that will send in production.
- 02
2. Fix durable receiver gates
Authentication, DNS, PTR, HELO, TLS, and blocklist findings usually matter before content tweaks.
- 03
3. Fix compliance and structure
Use the header analyzer for List-Unsubscribe, MIME, Message-ID, Date, From, and Received-chain checks.
- 04
4. Clean the recipient side
If the send is high-volume or stale, validate the list through email validation or bulk CSV before launch.
- 05
5. Retest and compare
Run a new test from the same sender path and compare the score, category findings, and remaining accepted risks.
What good looks like before launch
For important product or campaign email, aim for no critical findings, no unresolved authentication failures, working unsubscribe headers where required, safe links, a plain-text alternative, and a documented reason for any remaining warning. Then retest the final message through the email deliverability tester.
If you are comparing tools, read the Mail Tester alternative page to see why WillItInbox is positioned around repeatable QA, saved evidence, validation, monitoring, and API workflows rather than only a one-off score.
Frequently asked questions
| Priority | Evidence | Why it comes first |
|---|---|---|
| 1 | Routing and authentication failures | They can block or invalidate the sender identity |
| 2 | Header, MIME, and link failures | They affect parsing, trust, and user safety |
| 3 | Content and advisory warnings | They matter in context but rarely override broken identity |
| 4 | Retest comparison | It proves whether the same sender path improved |
Open the sample report, then create a test inbox for the exact message and sender path you need to evaluate.
Continue this email deliverability testing workflow with the commercial page, the core guide, the implementation docs.
Last updated June 13, 2026.
Sources reviewed
Factual review: June 13, 2026 by WillItInbox Editorial.
Keep reading