Docs
Use diagnostic seed inbox tests, provider evidence, repeat runs, and real-message reports to investigate inbox, spam, promotions, delayed, and missing outcomes.
A seed test gives controlled evidence about how a campaign appears in configured inboxes. It is useful for diagnosis, but it is not a substitute for real engagement and reputation data.
Placement diagnostics need at least one seed inbox with IMAP access. Authorized diagnostic send is optional: it stores encrypted SMTP credentials from a sender you own, then sends one diagnostic message only to your configured seeds.
After polling, placement results roll into provider coverage, heatmaps, trends, test detail, and optional recurring schedules.
A small seed list cannot guarantee every recipient will see the same folder. Recipient history, engagement, provider reputation, and personal filters still matter.
Use before major sends to catch obvious spam-folder or missing-message issues.
Run before and after DNS, template, or ESP changes.
Diagnostic seed tests do not create engagement or repair sender reputation.
Placement diagnostics
Inbox placement diagnostics answer a narrow but valuable question: where did this marked message land in the configured seed inboxes at this point in time? That sample is useful for QA and comparison, but it does not guarantee every real recipient will see the same folder.
Create the test, send a marked production-like message, poll seed inboxes, classify folders, then retest after meaningful fixes.
Pair placement results with a deliverability report so authentication, DNS, headers, content, and links are not guessed.
Use Google Postmaster and Microsoft SNDS as provider-specific context when enough traffic exists.
Provider evidence matrix
A placement result is strongest when it is interpreted alongside independent signals. When several surfaces point to the same issue, the fix order becomes clearer.
| Surface | What it helps explain | Where to use it |
|---|---|---|
| Seed inbox result | Inbox, spam, promotions, delayed, missing, or provider-specific folder outcome. | /docs/inbox-placement |
| Google Postmaster | Gmail-side reputation, spam rate, authentication, and compliance trends. | /blog/google-postmaster-tools-walkthrough |
| Microsoft SNDS | Outlook IP traffic, complaint, trap-hit, filter-result, and HELO evidence. | /blog/snds-microsoft-guide |
| DNSBL/domain monitoring | Blocklist, DNS, authentication, PTR, TLS, and provider-evidence drift. | /docs/domain-monitoring |
| Real-message report | Authentication, infrastructure, headers, content, links, and prioritized fixes. | /tools/email-deliverability-tester |
Placement vs deliverability
A deliverability test explains the message and sender path. A placement diagnostic samples folders. They answer different questions and become more useful together.
| Question | Deliverability test | Placement diagnostic |
|---|---|---|
| Is the message technically ready? | Best first step for SPF, DKIM, DMARC, DNS, headers, content, and links. | Useful after technical blockers are understood. |
| Where did the seed message land? | Does not classify seed folders. | Classifies inbox, spam, promotions, delayed, missing, and provider outcomes. |
| Can this guarantee recipient inboxing? | No. It produces technical evidence. | No. It produces a controlled sample. |
Repeat-test interpretation
Repeat placement tests only mean something when the sender path, template, seed set, subject marker, timing, and provider mix are recorded. Treat every run as an experiment with a clear change log.
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. |
Plan model
WillItInbox plans are easiest to understand when the metered usage stays simple: deliverability tests, email validations, API calls, and bulk CSV rows. Monitoring, webhooks, workspaces, branded reports, placement diagnostics, and trust-layer APIs are shown as feature access until those surfaces need explicit capacity counters.
Newer surfaces
The pricing page should stay scannable. The docs and feature pages should explain what the newer surfaces do, what evidence they produce, and where they fit in a sender's workflow.
The DMARC docs explain DMARC aggregate/RUF/TLS-RPT separation, mailbox ingestion, source labels, forensic-report handling, and alerts.
Connect Google Postmaster for read-only domain evidence, compliance status, and latest Gmail-side reputation snapshots.
Diagnostic seed tests, schedules, user-authorized SMTP sends, and provider heatmaps are documented as evidence, not a placement guarantee.
DSN bounce ingestion, ARF complaint ingestion, and suppression-aware validation are API-backed workflows for operational hygiene.
Related
Open the placement workflow for seed-backed folder evidence.
Inspect the exact sent message before interpreting folders.
Track sender-domain and provider evidence over time.
Compare monitoring, reports, validation, and workspace limits.
Learn when seed-list placement evidence is useful, where it is limited, and how to compare repeat tests.
Inspect the evidence format customers use to prioritize authentication, DNS, content, and placement fixes.
Read the supporting guide for practical context around inbox placement and reputation monitoring.
Read the supporting guide for practical context around inbox placement and reputation monitoring.
Read the supporting guide for practical context around inbox placement and reputation monitoring.
Read the supporting guide for practical context around inbox placement and reputation monitoring.
Compare how WillItInbox handles the same buyer need in inbox placement and reputation monitoring.
FAQ
No. It shows where a controlled seed sample landed. Real recipients can differ because of reputation, engagement, recipient history, content, timing, and provider behavior.
Run them before important campaigns, after sender-path changes, during reputation incidents, and when provider-specific behavior needs evidence beyond a technical message report.
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.
No. WillItInbox exposes four clear usage quotas today: tests, validations, API calls, and bulk rows. Other workflows are handled as feature access or beta access unless a concrete capacity limit is added later.
Placement tests provide diagnostic seed evidence, and trust-layer APIs provide operational ingestion and suppression evidence. Neither should be described as a guarantee of inbox placement or compliance certification.
