Deliverability
Test the message or validate the mailbox.
Use the switch below to choose the workflow: send a real email to a WillItInbox inbox, or verify recipient addresses before you send.
Two different deliverability questions
A message can be technically safe while the recipient address is risky, and a valid mailbox can still receive a message that fails authentication, link, content, or sender reputation checks. This page keeps those workflows together so teams can test the email they plan to send and validate the audience they plan to send it to.
Choose a tool
Deliverability workbench
Deliverability tester
Generate an inbox, send any real email to it, and get the same evidence a receiving mailbox sees: authentication, infrastructure, headers, SpamAssassin, content, links, and a prioritized fix list.
When to test the message
Run the deliverability tester before a launch, a template change, an ESP migration, or a domain warm-up. It answers whether the exact message you plan to send passes authentication (SPF, DKIM, DMARC), carries the headers bulk senders are required to publish, and avoids the content and link patterns that trigger filters. Every test produces a report with a weighted 0-100 score and a prioritized fix list.
- Pre-flight check for campaigns and product launches
- Evidence for why a live message started landing in spam
- Regression testing after DNS, ESP, or template changes
When to validate the list
Run the validator before importing a list, reactivating dormant segments, or sending to addresses you have not mailed recently. Twelve evidence layers classify each address as valid, invalid, risky, catch-all, or unknown, so hard bounces and spam-trap-adjacent addresses are suppressed before they damage sender reputation. Bulk CSV jobs return enriched, downloadable results.
- List cleaning before campaigns and re-engagement sends
- Signup and form validation through the API
- Catch-all and unknown handling that stays honest about uncertainty
One evidence model, two entry points
Both workflows report the same categories of evidence — authentication, DNS and infrastructure, headers, content, and links — so findings from a message test and a list-validation job can be compared directly. Teams typically validate the audience first, then test the final production-like message from the same sender path, and retest after every change that could alter authentication or reputation. Domain monitoring and DMARC reporting extend the same evidence into an ongoing watch rather than a one-time check.