Example
Walk through a sample WillItInbox report with category scoring, pass/warn/fail evidence, owner-ready actions, and a retest workflow.
82
sample score
Warn
DMARC policy
Fail
missing plain text
Reviewed July 26, 2026. This sanitized example uses the same score, category, evidence, and fix-order shape as a WillItInbox report. Identifying sender and message data is omitted, and the values below are illustrative rather than a live placement guarantee.
A typical report starts with a score and then explains the issues that cost points. The goal is not a vanity number; it is a fix order.
| Category | Sample result | Fix priority |
|---|---|---|
| Authentication | SPF pass, DKIM pass, DMARC p=none warning | Move toward enforcement after reviewing reports. |
| DNS and infrastructure | PTR pass, TLS pass, no DNSBL listing | Monitor monthly. |
| Headers | List-Unsubscribe missing | Add one-click unsubscribe before bulk sends. |
| Content | HTML-only message | Add text/plain alternative. |
| Links | One HTTP tracking link | Switch to HTTPS branded tracking. |
Fix authentication and infrastructure issues first, because they are usually receiver gates. Then clean headers, content, and links before retesting.
Developer workflow
A report becomes operational when the team can retain its token, inspect critical findings, link back to the evidence, and decide whether the build should fail or require review.
| Report outcome | Automation decision | Developer follow-up |
|---|---|---|
| Critical authentication or MIME defect | Fail the release gate | Open the saved report and fix the sender or template. |
| Score below an owned threshold | Fail or require approval | Compare category evidence with the previous accepted run. |
| Contextual content or reputation warning | Create a review task | Assign an owner instead of silently ignoring it. |
| Temporary analysis failure | Retry with bounded backoff | Preserve the original report or message identifier. |
Score summary
Buyers comparing spam testers need to see the shape of the evidence. The sample report shows the score, categories, severity, exact findings, and retest path without pretending one test predicts every inbox.
| Panel | Sample evidence | Decision |
|---|---|---|
| Score | 82 with two warnings and one failure. | Do not launch until the failure is fixed. |
| Authentication | SPF pass, DKIM pass, DMARC p=none warning. | Monitor reports before moving toward enforcement. |
| Headers | List-Unsubscribe missing. | Add one-click unsubscribe before bulk sends. |
| Content | HTML-only body and image-heavy section. | Add text/plain and enough readable copy. |
| Links | One HTTP tracking link. | Move to HTTPS branded tracking and retest. |
Evidence cards
A useful report separates the evidence, likely owner, next action, and retest trigger. That makes it easier to hand the work to DNS, engineering, lifecycle, or marketing owners.
Fix SPF, DKIM, DMARC, PTR, TLS, MTA-STS, and routing findings, then wait for propagation.
Fix List-Unsubscribe, MIME alternatives, footer requirements, visible sender, content, and links.
Validate the recipient list, document accepted warnings, schedule a retest, and monitor after launch.
Retest workflow
After fixes ship, rerun the exact sender path and compare the new report with the baseline. That is how the score becomes operational evidence instead of a screenshot.
How to use this example
Examples are not decorative screenshots. They should show the request, evidence, interpretation, decision, and next internal link. Use them when you need to explain a result to a teammate or convert a diagnostic finding into a policy.
Decision policy
A good example does not stop at valid, risky, pass, or fail. It says whether to accept, suppress, segment, retry, fix DNS, change a template, open an owner task, or retest after propagation.
Use /test when the question is whether the exact production email is technically ready.
Use /validator or /validator/bulk before imports, outbound, newsletters, and reactivation.
Use /docs/api when deliverability QA belongs in CI, release tooling, or an internal workflow.
Related
Capture development messages, inspect source, and run reusable CI checks.
Review authenticated endpoints, request shapes, errors, and quotas.
Verify HMAC signatures and process asynchronous events safely.
Use Node, Python, and command-line helpers for common workflows.
Create a fresh report from your own production-like message.
Follow the recommended testing workflow.
Compare testing volume, API, and monitoring options.
Open the public tool that helps diagnose one part of email deliverability testing.
Read the supporting guide for practical context around email deliverability testing.
FAQ
Use the request and policy patterns, but replace sample keys, domains, tokens, and thresholds with your own account and risk policy.
