You've finished the campaign, checked that the sending platform accepted every message, and watched the dashboard report successful delivery. Then replies slow down, clicks disappear, and someone discovers that the campaign landed in spam at a major mailbox provider. The send technically worked, but the audience never saw it.
That's the central problem with email testing. A receiving server accepting a message doesn't prove that a person can find it in the inbox. A reliable workflow must test the list, authentication, message content, provider-level placement, and sender reputation as connected parts of one operating system.
Table of Contents
- Understanding What Deliverability Testing Reveals
- Preparing the List and Sending Infrastructure
- Running an Inbox Placement Test
- Diagnosing Spam-Filter and Authentication Problems
- Choosing Tools and Scripts for Deeper Testing
- Tracking Metrics and Acting on Results
- Building a Repeatable Deliverability Routine
Understanding What Deliverability Testing Reveals
A campaign can receive an SMTP 250 OK response and still miss the outcome you care about. That response confirms that the receiving server accepted the message for processing. It doesn't tell you whether the message reached the primary inbox, a promotions tab, a spam folder, an administrator quarantine, or nowhere visible at all.
Delivery rate measures server acceptance. Inbox placement measures whether the message reached an inbox a recipient is likely to see. Validity's benchmark materials define inbox placement as the number of messages found in the inbox divided by the number of messages delivered, which makes the distinction operational rather than semantic. In one widely cited benchmark, global inbox placement was 84.8%, spam placement was 6.1%, and 9.1% of messages were missing, as reported in Validity's global deliverability benchmark. The same research says global average inbox placement in 2022 was just below 85%, meaning about 1 in 6 legitimate permission-based marketing emails didn't reach the inbox.
The evidence behind a failed send
A practical deliverability review asks several different questions:
- Did the list contain valid recipients? Invalid, stale, disposable, role-based, or trap-like addresses can create bounces and complaints.
- Did the infrastructure authenticate correctly? SPF, DKIM, and DMARC must work together and align with the visible From domain.
- Did providers place the message where expected? Seed-list testing shows folder-level results that delivery logs can't reveal.
- Did the content trigger filtering? Links, attachments, HTML structure, image balance, and message wording can influence filtering.
- Did the sender's history affect the decision? Provider treatment reflects reputation, engagement, complaints, and sending patterns over time.
If you're still separating delivery from inbox placement, this explanation of email deliverability gives the distinction a useful operational frame.
Practical rule: Treat every test result as a clue about a specific failure layer, not as a universal pass or fail.
Testing should run before a campaign, during an active send, and after the results arrive. A pre-send check can expose an authentication mismatch. A live campaign can reveal provider-specific deferrals. Post-send data can show that an aged segment is producing complaints even though the technical setup remains unchanged. The workflow works when each result changes what the team checks next.
Preparing the List and Sending Infrastructure
Start with the recipients. Technical configuration can't rescue a list that contains invalid addresses, forgotten subscribers, or contacts who never gave permission.
Clean the data before you validate the message
Remove hard bounces from future sends immediately. Suppress known spam traps, disposable addresses, and contacts who have repeatedly failed delivery. Review role accounts such as generic department addresses separately because they often behave differently from individual subscribers and may not represent a clear opt-in relationship.
Run an email verification pass before a major campaign and again when a list has aged. A useful validation process checks syntax, domain configuration, mailbox existence, catch-all behavior, disposable providers, role accounts, and historical bounce signals. You can use this practical guide to cleaning an email list to turn those checks into a repeatable suppression process.
Segment engagement rather than sending the same way to everyone. Keep recently active subscribers in the main campaign, isolate unengaged contacts for a controlled re-engagement message, and suppress people who no longer respond or who have shown negative signals. A list that looks large in a database can still be risky if many contacts are stale.
Confirm the sender identity
Check the full authentication chain against the domain visible in the From address:
- SPF should authorize the systems that send on your behalf, without unnecessary or conflicting include mechanisms.
- DKIM should produce a valid signature and align with the visible From domain where your policy requires it.
-
DMARC should publish a policy, with
p=noneas a sensible observation stage for teams still establishing reporting, andruareporting enabled so failures can be reviewed. - Return-path configuration should remain consistent with the sending setup and shouldn't create unexplained alignment differences.
- Reverse DNS should identify the sending IP appropriately, while forward resolution should support that identity.
- TLS and certificate behavior should be valid for the systems exchanging mail.
Use DNS lookup tools and your ESP's authentication tester before scheduling the campaign. Don't stop when a record exists. Inspect whether the record resolves, whether the correct provider is authorized, and whether the authenticated domain matches the address recipients see.
Finally, review infrastructure history. A new IP or sending subdomain needs an established warm-up pattern, while a shared pool requires confidence that the ESP monitors the behavior of other senders. Separate marketing and transactional streams when their audiences, complaint patterns, or business importance differ. That separation limits the chance that a problem in one stream affects the other.
Running an Inbox Placement Test
A seed-list test recreates the recipient experience across mailbox ecosystems. Instead of asking whether the ESP accepted the campaign, you send the production message to monitored addresses and inspect the folder where each provider placed it.
Build a seed list that includes Gmail, Outlook, Yahoo, AOL, and relevant corporate domains. If your audience contains a meaningful share of another ecosystem, include it too. The purpose isn't to create a perfect model of every recipient. It's to expose provider-specific behavior that a single mailbox can hide.
Control the test conditions
Send the same content you plan to send in production. Keep the From address, sending domain, reply-to address, links, attachments, HTML, and tracking configuration consistent. Match the planned day and time, and throttle the test so its pacing resembles the campaign rather than an artificial burst.
Change one variable per comparison. If you alter the subject line, From name, sending IP, and template at the same time, you won't know which change affected placement. Keep a version identifier in your test record, and don't split one comparison across unrelated subdomains.
Provider coverage matters because placement varies by mailbox ecosystem. A published benchmark cited by Validity reports Gmail at 89.8%, Yahoo at 87.3%, Apple Mail at 82.0%, and Microsoft at 77.4% in its provider-level results, so a Gmail-only test can create false confidence. The inbox placement testing guide is useful when you're formalizing the seed-list process.
Classify every result
Record the provider, seed address, timestamp, content version, sender identity, and observed folder. Classify the result consistently rather than relying on a tester's single summary score.
| Placement Outcome | Meaning | Action Trigger |
|---|---|---|
| Primary inbox | The message reached the most visible mailbox location | Preserve the tested conditions and compare future runs |
| Promotions or secondary tab | The message arrived but may receive less attention | Review campaign intent, content structure, and audience expectations |
| Spam or junk | The provider accepted the message but filtered it | Inspect reputation, authentication, complaints, and content |
| Quarantine | A corporate or security gateway held the message | Review policy, URLs, attachments, and administrator controls |
| Missing | The message wasn't found in an expected folder | Check logs, deferrals, filtering, and test-address health |
Calculate placement separately by provider and by campaign version. Don't collapse spam, quarantine, and missing results into a generic delivery rate. Each outcome points to a different investigation, and provider-level differences often reveal whether the issue belongs to the message, the sender, or a particular mailbox environment.
Diagnosing Spam-Filter and Authentication Problems
When a seed test fails, don't rewrite the entire campaign immediately. Read the evidence in a fixed order so you can distinguish an authentication problem from a content problem or a reputation problem.
Read the message from the provider's perspective
Start with SMTP logs. Look for rejects, temporary deferrals, policy responses, connection failures, and provider-specific explanations. A rejection points to a different path from a message that was accepted and later placed in spam.
Next, open the complete message headers and find the Authentication-Results header. Confirm that SPF and DKIM passed, then verify DMARC alignment against the visible From domain, not only the envelope sender. A message can have an SPF record and a DKIM signature yet still fail the alignment that DMARC evaluates. When forwarding is involved, inspect ARC results as well, because forwarding can alter authentication behavior.
Check alignment, not just existence. A published record is only the starting point. The header shows what the provider actually evaluated.
Compare headers with seed placement. If the message fails authentication across providers, fix the DNS and sending identity first. If authentication passes but one provider sends the message to spam, investigate reputation, engagement, and that provider's filtering behavior before changing the template.
Isolate content triggers
Run controlled tests with one change at a time:
- Link density: Remove unnecessary links and compare placement.
- Image balance: Test a lighter HTML version against the original.
- Trigger language: Replace unusually promotional or ambiguous wording.
- Attachments: Remove attachments and test linked resources separately.
- Template weight: Simplify nested tables, tracking elements, and excess markup.
- Destination reputation: Review every domain used in links, redirects, and image hosting.
Content filtering often repeats across several providers. Reputation filtering may appear as quiet spam placement or deferrals at a particular ISP, especially when the same content reaches the inbox elsewhere. Document the exact header line, provider result, suspected trigger, change made, and next test result. That history prevents the team from repeating guesses.
For a broader pre-send review, the Tagada spam prevention checklist can supplement your internal diagnostic notes.
Choosing Tools and Scripts for Deeper Testing
No single deliverability tool sees every failure mode. Choose the tool according to the question you're asking, then combine its output with logs and real mailbox observations.
| Method | What It Tests | Best Used For |
|---|---|---|
| Commercial placement service | Seed inboxes, folders, provider differences, and some reputation indicators | Broad pre-send coverage across consumer and corporate providers |
| Manual seed sends | Actual rendering and folder placement in controlled mailboxes | High-value segments and campaign-specific confirmation |
| DNS and authentication validators | SPF, DKIM, DMARC, MX, PTR, and policy configuration | Foundation checks before scheduling |
| Header analyzers | Authentication results, routing, ARC, and provider processing clues | Post-send debugging and forwarded-message analysis |
| Spam-score checkers | Content patterns, markup, links, and suspicious elements | Copy and template review before final approval |
| SMTP utilities and log parsers | Connection responses, deferrals, rejects, and retry behavior | Engineering diagnosis during and after a send |
Commercial placement platforms save time because they maintain provider coverage and collect folder results in one interface. The trade-off is cost and abstraction. You may get a clear placement report without seeing every underlying mailbox decision, so retain raw headers and provider responses for difficult incidents.
Manual seeds give you direct evidence, but they require disciplined recordkeeping. They're particularly useful for a critical newsletter, a transactional template, or a segment whose provider mix differs from your general audience.
Script the foundation, not the judgment
Engineers can automate repeatable checks with command-line tools such as dig and nslookup for DNS inspection, and openssl for TLS and certificate validation. Keep those scripts focused on whether expected records resolve and whether the sending endpoint presents a valid certificate. Don't treat a green script result as an inbox-placement prediction.
For list risk, CleanMyList can accept a CSV or pasted addresses and return verification results across syntax, DNS, SMTP mailbox existence, catch-all behavior, disposable providers, role accounts, historical bounce reputation, and a send-or-skip recommendation. Its API also supports address testing and simulation for send workflows. Use it as a list-quality layer, not as a replacement for authentication or seed placement.
The practical balance is simple: pay for broad provider visibility when the campaign justifies it, automate deterministic infrastructure checks, and reserve human review for the message, audience, and business context.
Tracking Metrics and Acting on Results
A deliverability dashboard becomes useful when every metric has an owner and a response. Don't collect acceptance, engagement, complaint, and placement data in separate reports that nobody connects during a send review.
Group the signals by what they explain
Acceptance metrics include hard bounces, soft bounces, deferrals, and rejects. They tell you whether providers accepted the message and whether your list or sending behavior is creating friction. A sudden bounce increase should trigger list re-verification and a review of recent acquisition sources.
Engagement metrics include opens, clicks, replies, and reading behavior where your tracking setup supports it. Treat open data carefully because measurement methods vary and privacy controls can distort it. A sudden decline in clicks or replies, while the content and audience remain stable, deserves a provider-level placement check.
Complaint signals include spam complaints, unsubscribe activity, and feedback-loop data. Industry guidance commonly treats 0.1% as a best-practice ceiling for spam complaints, as described in Mailgun's State of Email report. Even small complaint rates can weaken reputation, so a rise should lead to a review of permission, targeting, frequency, and the clarity of the unsubscribe path.
Placement metrics come from the seed test: inbox, promotions, spam, quarantine, and missing. Record these by provider rather than reporting one blended number. The global benchmark cited earlier shows why this matters, with a large share of technically delivered messages still absent from the inbox.
Turn trends into decisions
Use a weekly review to compare current results with your own recent baseline. Adjust expectations for list age, acquisition source, campaign type, and provider mix. A healthy result for an engaged newsletter segment may not be an appropriate benchmark for a re-engagement audience.
| Signal | Likely investigation | Immediate response |
|---|---|---|
| Rising bounces | Stale or invalid addresses, acquisition quality, DNS, or provider blocks | Re-verify the affected segment and pause risky sources |
| More deferrals | Volume pattern, reputation, connection behavior, or policy limits | Review pacing, recent campaign changes, and provider responses |
| Higher complaints | Weak permission, irrelevant content, excessive frequency | Tighten targeting, reduce pressure, and suppress complainants |
| Lower inbox placement | Authentication, reputation, content, or provider-specific filtering | Run the full diagnostic cycle and segment the next test |
| Lower clicks or replies | Relevance, rendering, or reduced visibility | Compare placement and content versions before changing strategy |
Record the action, owner, date, and follow-up result. A metric only improves operations when the next campaign inherits what the previous campaign taught you.
Building a Repeatable Deliverability Routine
Deliverability testing fails when the team treats it as a launch-day ritual. Providers evaluate your sending history, recipient reactions, authentication, and traffic patterns over time, so your process must produce evidence continuously.
Use three operating rhythms
Before every send, verify the audience segment, suppress bounces and complaints, confirm SPF, DKIM, and DMARC results, inspect links and attachments, and send the production version to your seed list. Don't approve a campaign from the ESP's delivery count alone.
Each week, review bounce and deferral trends, complaint and unsubscribe signals, provider-level placement, authentication failures, and any changes in sending volume. Re-run validation on lists that have been sitting unused, especially when the audience contains older imports or contacts from changing sources.
Each month, perform a broader inbox audit across consumer and corporate providers, inspect DMARC reports, review reputation indicators, check blocklist warnings, and compare results by sending subdomain and campaign type. Mailbox policies change, and a configuration that worked previously can become a source of failures when requirements tighten. The email deliverability rates guide provides useful context for interpreting industry benchmarks without treating them as a substitute for your own provider-level evidence.
Troubleshoot in the right order
Fix authentication and identity problems first. A content rewrite won't repair a DMARC alignment failure, and list cleaning won't correct a broken DKIM signature. Once the technical foundation passes, investigate list quality and message content, then examine infrastructure, pacing, and reputation.
Create alert thresholds that match your program and segment. Escalate recurring provider-specific failures to your ESP or postmaster contact with timestamps, headers, SMTP responses, seed results, and the exact changes already tested. That packet turns “our emails are going to spam” into an incident another team can investigate.
The wider lesson is that how to test email deliverability isn't a single checklist. It's a diagnostic loop: validate the recipients, authenticate the sender, observe real mailbox placement, interpret the signals, document the cause, and use the result to improve the next send.
CleanMyList helps you verify bulk lists before launch by checking addresses across multiple deliverability signals, returning plain-English reasons, and letting you export or sync the cleaned results. Visit CleanMyList to test a list or add real-time email validation at signup before risky addresses enter your sending system.