Example

Sample deliverability report with score, evidence, and fix order.

Walk through a sample WillItInbox report with category scoring, pass/warn/fail evidence, owner-ready actions, and a retest workflow.

Read report guideAutomate report QA

82

sample score

Warn

DMARC policy

Fail

missing plain text

Sample result

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.

CategorySample resultFix priority
AuthenticationSPF pass, DKIM pass, DMARC p=none warningMove toward enforcement after reviewing reports.
DNS and infrastructurePTR pass, TLS pass, no DNSBL listingMonitor monthly.
HeadersList-Unsubscribe missingAdd one-click unsubscribe before bulk sends.
ContentHTML-only messageAdd text/plain alternative.
LinksOne HTTP tracking linkSwitch to HTTPS branded tracking.

How to act on the report

Fix authentication and infrastructure issues first, because they are usually receiver gates. Then clean headers, content, and links before retesting.

  • Batch DNS changes and wait for propagation.
  • Retest from the exact sending system after fixes.
  • Document remaining warnings so the team understands accepted risk.

Developer workflow

Use report evidence in release automation

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 outcomeAutomation decisionDeveloper follow-up
Critical authentication or MIME defectFail the release gateOpen the saved report and fix the sender or template.
Score below an owned thresholdFail or require approvalCompare category evidence with the previous accepted run.
Contextual content or reputation warningCreate a review taskAssign an owner instead of silently ignoring it.
Temporary analysis failureRetry with bounded backoffPreserve the original report or message identifier.

Score summary

A sample report should make the product feel concrete

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.

PanelSample evidenceDecision
Score82 with two warnings and one failure.Do not launch until the failure is fixed.
AuthenticationSPF pass, DKIM pass, DMARC p=none warning.Monitor reports before moving toward enforcement.
HeadersList-Unsubscribe missing.Add one-click unsubscribe before bulk sends.
ContentHTML-only body and image-heavy section.Add text/plain and enough readable copy.
LinksOne HTTP tracking link.Move to HTTPS branded tracking and retest.

Evidence cards

Each finding needs an owner-ready action

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.

DNS owner

Fix SPF, DKIM, DMARC, PTR, TLS, MTA-STS, and routing findings, then wait for propagation.

Template owner

Fix List-Unsubscribe, MIME alternatives, footer requirements, visible sender, content, and links.

Ops owner

Validate the recipient list, document accepted warnings, schedule a retest, and monitor after launch.

Retest workflow

The report is a baseline, not the finish line

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.

  • Batch DNS and sender configuration fixes, then wait one TTL cycle before retesting.
  • Retest from the same app or ESP path, not a forwarded message.
  • Record remaining warnings as accepted risk or create follow-up tasks.
  • Use API/report workflows when release gates need a repeatable check.

How to use this example

Read examples as implementation patterns

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

Examples should end in an action

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.

Run a real-message test

Use /test when the question is whether the exact production email is technically ready.

Validate recipients

Use /validator or /validator/bulk before imports, outbound, newsletters, and reactivation.

Automate checks

Use /docs/api when deliverability QA belongs in CI, release tooling, or an internal workflow.

Related

Email sandbox

Capture development messages, inspect source, and run reusable CI checks.

API reference

Review authenticated endpoints, request shapes, errors, and quotas.

Webhook documentation

Verify HMAC signatures and process asynchronous events safely.

SDK and CLI docs

Use Node, Python, and command-line helpers for common workflows.

Run a test

Create a fresh report from your own production-like message.

Deliverability docs

Follow the recommended testing workflow.

Pricing

Compare testing volume, API, and monitoring options.

Email Deliverability Tester tool

Open the public tool that helps diagnose one part of email deliverability testing.

Reading The Willitinbox Report guide

Read the supporting guide for practical context around email deliverability testing.

FAQ

Can I reuse these examples in production?

Use the request and policy patterns, but replace sample keys, domains, tokens, and thresholds with your own account and risk policy.