Docs
Learn how WillItInbox test inboxes work, what the report checks, how to validate supporting lists, and how to retest after fixes.
0-100
weighted score
5
score categories
24h
short raw email retention
WillItInbox generates a unique test address. You send a message to that address from the exact app, ESP, domain, and template you want to evaluate. The report analyzes what a receiver can see.
The score is intentionally weighted toward signals mailbox providers care about before content reputation can help you.
SPF, DKIM, DMARC, alignment, policy strength, selector lookup, and BIMI signals.
PTR, forward-confirmed rDNS, HELO, MX, DNSBLs, dynamic IP signals, and TLS.
Required headers, SpamAssassin signals, MIME shape, unsubscribe, address, attachments, and links.
Run a fresh test after meaningful DNS, ESP, template, domain, or sending infrastructure changes. Do not treat one old report as proof that future campaigns are safe.
Pre-send workflow
The docs should teach a repeatable operating loop: send the real message, fix durable failures, validate the recipient list, retest after changes, and keep the report as evidence.
| Moment | Check | Destination |
|---|---|---|
| Before template launch | Final message through the real sender path. | /tools/email-deliverability-tester |
| Before campaign volume | List validation and risky recipient segmentation. | /tools/email-validator |
| Before bulk sends | List-Unsubscribe, MIME, links, image ratio, and sender requirements. | /tools/header-analyzer |
| After fixes | Retest and compare report evidence. | /examples/sample-deliverability-report |
Limits
WillItInbox can expose technical risk and obvious spam signals. It should not claim to guarantee inbox placement because reputation, engagement, recipient history, and provider behavior remain separate inputs.
Evidence quality
A forwarded proof, pasted HTML body, or staging message through a different sender can hide the exact problems that mailbox providers will see. The strongest test uses the production-like application, ESP, sender domain, DKIM selector, Return-Path, tracking links, and final template.
Fix order
Authentication and infrastructure failures usually deserve attention before content refinements because receivers evaluate sender identity and connection quality before trusting the body. After that, required headers, unsubscribe handling, MIME quality, and links shape the final risk profile.
| Layer | Common issue | First action |
|---|---|---|
| Authentication | SPF/DKIM/DMARC missing or unaligned | Fix DNS/provider configuration, then retest. |
| Infrastructure | PTR, HELO, TLS, or blocklist issue | Correct the sender host or investigate the listing cause. |
| Headers | Missing List-Unsubscribe or Message-ID | Fix the mailer or ESP template settings. |
| Content | HTML-only, image-heavy, or suspicious links | Improve MIME structure and link hygiene. |
Related
Open the public tool that helps diagnose one part of email deliverability testing.
Read the supporting guide for practical context around email deliverability testing.
Inspect the evidence format customers use to prioritize authentication, DNS, content, and placement fixes.
Use the REST API reference when validation, bulk jobs, webhooks, reports, or usage need to run from your own systems.
Compare validation volume, monitoring, API access, reporting, and workspace limits by plan.
FAQ
No. It shows technical deliverability signals and likely risk. Inbox placement still depends on reputation, engagement, recipient history, and provider behavior.
Yes. They often use different templates, headers, links, subdomains, and sending systems.
Retest after DNS changes, ESP migrations, template edits, tracking-domain changes, new sending subdomains, and before important campaigns or product-email releases.
Yes. They often use different templates, headers, links, sender domains, and risk profiles.
