How to Test Email Deliverability: A Practical Workflow

Your prospect list passed verification. The campaign launched, your sending platform reports delivered messages, and the sales team still isn't getting replies from Microsoft-hosted accounts. A controlled Outlook mailbox shows the problem: the message arrived in Junk, even though the recipient address passed validation.

Knowing how to test email deliverability means separating what your verifier knows from what your sending platform reports and what the recipient's mailbox does. Build those observations into a pipeline, and you can make defensible decisions about which records to send, retry, quarantine, or suppress.

Table of Contents

• Why Inbox Placement Is Harder Than a Valid Response
  • Replace the single score with observable outcomes
  • Make the investigation reproducible
• Four Outcomes You Must Measure Separately
  • Keep placement separate from engagement
  • Classify uncertainty without inventing probabilities
• The SMTP and DNS Validation Pipeline
  • Follow the protocol without overstating the result
  • Keep validation traffic bounded
• Running Provider-Segmented Seed Tests
  • Test the route you intend to deploy
  • Capture message evidence and contextual signals separately
• Reading Engagement Signals Without Open-Rate Traps
  • Treat the chart as illustrative, not a benchmark
  • Use engagement to investigate, not to certify placement
• Automating Tests With Batch APIs and Async Webhooks
  • Define an application-level contract
  • Gate deployments with placement evidence
• Field-Tested Takeaways for Your Runbook
  • Attach every trigger to an action
  • Make the audit trail usable

Why Inbox Placement Is Harder Than a Valid Response

A verifier's positive response answers a narrower question than most GTM dashboards imply. It can provide evidence that an address is structurally plausible and that the receiving infrastructure accepts a recipient probe. It doesn't establish where a campaign message will land.

That distinction matters when someone asks engineering to investigate a campaign that looks healthy in the sending platform but produces little activity. Re-verifying the same list might return the same results. If the problem is provider-specific filtering, you're measuring the wrong layer.

Replace the single score with observable outcomes

Use separate fields for address validity, server acceptance, provider-level delivery, and inbox placement. Each field should retain its own evidence, timestamp, and uncertainty rather than being compressed into a universal deliverability score.

A 2024 email service provider testing series reported average deliverability of 83.1%, leaving 16.9% of test messages short of the intended destination. That benchmark isn't a prediction for your campaign. It demonstrates why a successful send operation isn't enough evidence to declare success.

The useful debugging questions are concrete:

• Recipient evidence: What did the verifier establish, and which checks remained inconclusive?
• Sending evidence: Did the actual receiving provider accept the campaign message?
• Mailbox evidence: Did the controlled account place it in Primary, another tab, Spam, or nowhere observable?
• Scope: Is the failure associated with a recipient domain, mailbox provider, sender domain, or template version?

Practical rule: Never let a verification result populate an inbox-placement field.

Make the investigation reproducible

For the Outlook scenario, keep the recipient segment fixed while testing the production-like sending route. Record the sender domain, template version, tracking domain, infrastructure, and authentication configuration with the result. Otherwise, a later improvement won't tell you which change mattered.

Treat the investigation as an operational hypothesis: perhaps the list is uncertain, perhaps the sender configuration is broken, or perhaps Microsoft is filtering this particular route. Your measurements should distinguish those possibilities.

The engineering objective isn't to produce a reassuring badge. It's to identify the next safe action without pretending that incomplete evidence is certainty.

Four Outcomes You Must Measure Separately

The cleanest data model distinguishes pre-send evidence from observed message outcomes. A record can pass an early check and still fail later, so store the stages independently.

The verification accuracy discussion covering catch-all behavior, temporary failures, and masked responses supports keeping these observations distinct rather than treating SMTP acceptance as final delivery.

Keep placement separate from engagement

The diagram provides a useful vocabulary for distinguishing address checks, placement, and recipient activity.

For implementation, retain the more granular stages in the table. Spam placement is a placement result, while engagement is a subsequent observation, not evidence that every message reached an inbox.

Within placement, distinguish Primary from secondary tabs such as Promotions or Updates. Keep Spam separate, and preserve missing messages as unresolved unless you have evidence of blocking. A missing observation and an explicit rejection shouldn't share a reason code.

Classify uncertainty without inventing probabilities

Don't assign numerical confidence because an API returns a categorical status. Without calibrated evidence, a percentage would imply precision you don't have.

Instead, define action-oriented states:

• Eligible: Verification passed under your policy, and the sending route has acceptable placement results.
• Risky: Catch-all behavior or another risk indicator prevents a confident recipient-level conclusion.
• Deferred: A temporary condition warrants a later attempt.
• Unknown: The available evidence doesn't support a decision.

Use a catch-all email handling policy to determine whether ambiguous records enter a restricted workflow or remain quarantined. Don't promote them to eligible because an enrichment step found a plausible address.

Store the original provider response alongside your normalized state. That lets operations change routing policy without losing the evidence needed to explain an earlier decision.

The SMTP and DNS Validation Pipeline

A recipient verifier should perform a bounded investigation, not send a miniature campaign. Its output needs to describe what happened, including when the server refused to provide enough information.

This flow shows the execution order to inspect when evaluating a verifier.

Follow the protocol without overstating the result

Start by normalizing the input and validating syntax. Preserve the submitted value for auditability, and avoid aggressive rewriting that changes the intended recipient.

Next, query DNS for MX records. Establish an SMTP connection where permitted, issue a RCPT TO recipient probe, and capture the response. Classify the observation as deliverable, invalid, catch-all, temporary failure, or indeterminate.

An MX record establishes advertised mail infrastructure, while SMTP probing remains subject to verification policies, firewalls, greylisting, tarpits, and catch-all behavior. A timeout therefore shouldn't automatically become an invalid address.

The operational branches matter more than a green checkmark:

• Catch-all response: Probe several deliberately nonexistent recipients, within provider policies. If all are accepted, mark the target uncertain rather than claiming mailbox existence.
• Temporary failure: Schedule exponential backoff. Keep the record out of the permanent suppression list while the retry policy remains active.
• Indeterminate response: Preserve the reason and quarantine the record rather than translating uncertainty into success.
• Risk indicators: Track role accounts, disposable domains, and spam-trap indicators separately from protocol validity.

Keep validation traffic bounded

Don't transmit message bodies during mailbox validation. Recipient probing should respect provider policies and applicable privacy and anti-abuse requirements. More probing isn't automatically better evidence, particularly when a server deliberately conceals recipient status.

When implementing an email verification API, retain the raw verdict, normalized classification, reason code, observation time, and retry eligibility. Report acceptance, uncertainty, hard-invalid, and temporary-failure rates by provider and domain.

For a companion walkthrough, use this video alongside the protocol workflow.

Recipient validation is only part of operating a sender. For a broader sending-practices checklist, NotionSender's guide to improve your email deliverability is a useful companion resource.

The trade-off is deliberate: a conservative verifier leaves some records unresolved. That's preferable to converting an uncooperative server into false confidence.

Running Provider-Segmented Seed Tests

Build the seed list around the providers your prospects use. Include controlled Gmail, Microsoft, Yahoo, Apple/iCloud, and representative corporate accounts, plus regional services relevant to your audience.

Use a dashboard to compare destinations, but keep the underlying message evidence available for inspection.

Test the route you intend to deploy

Send through the same operational route as the campaign. Match the visible From domain, sending infrastructure, tracking domain, template, and authentication configuration. A hand-written message sent from a different mailbox won't test the proposed deployment.

Keep the test content consistent across providers and attach a unique correlation identifier to each message. Record the test's configuration as an immutable snapshot so later comparisons don't depend on someone remembering which template was active.

Before sending, check the applicable sender requirements. Google requires bulk senders to use SPF, DKIM, and DMARC, with valid forward and reverse DNS and TLS for sending infrastructure. Authentication is a prerequisite to inspect, not a substitute for observing placement.

Capture message evidence and contextual signals separately

For each seed message, collect:

• Transport evidence: Final SMTP response, TLS status, delivery timing, and bounce category.
• Authentication evidence: SPF authorization and alignment, DKIM verification and alignment, DMARC result, and visible From versus envelope-domain relationship.
• Placement evidence: Primary inbox, secondary tab, Spam, or missing at the observation cutoff.
• Contextual signals: Available IP and domain reputation information, complaints, and the sending configuration associated with the test.

Not every signal comes from the message headers. Store reputation and complaint data with their source and observation time, and leave unavailable information explicitly unknown.

A provider-specific failure needs a provider-specific decision. A healthy overall average isn't permission to ignore a failing recipient segment.

For example, if Gmail placement remains stable while Microsoft seed messages move to Junk, investigate the Microsoft segment before rewriting the entire campaign. If every provider changes after a template deployment, compare that deployment against the prior configuration.

Re-run placement tests after material changes to templates, links, sending IPs, domains, authentication, or volume. Compare like-for-like configurations and avoid changing multiple unrelated variables during diagnosis.

Finally, treat seed results as controlled observations, not a guarantee for every prospect. They show what happened to those accounts through that route. Keep production bounces, complaints, and deferrals alongside them so the team can distinguish a clean preflight from healthy ongoing operation.

Reading Engagement Signals Without Open-Rate Traps

An open event doesn't reliably establish that a person read your message. Apple Mail Privacy Protection can prefetch tracking pixels, inflating apparent opens and making comparisons particularly misleading for Apple users.

The provider-level deliverability analysis reports 87.2% global inbox placement in 2025, compared with approximately 77.4% for Microsoft and 82.0% for Apple. Those benchmark differences reinforce the need to inspect provider-level outcomes before interpreting an aggregate engagement trend.

Treat the chart as illustrative, not a benchmark

Use the following visual to distinguish metric types. Its displayed values are illustrative, not campaign targets or measured results for your pipeline.

For operational reporting, keep each signal tied to the question it can answer.

Use engagement to investigate, not to certify placement

Prioritize meaningful replies and downstream conversions when evaluating campaign usefulness. Keep clicks as supporting evidence, and interpret opens cautiously rather than using them to approve a send expansion.

A reply decline should trigger investigation, not an automatic deliverability diagnosis. Compare the affected provider, sender route, audience segment, and template against the placement evidence. If placement is stable, review relevance and targeting instead of treating every weak campaign as an infrastructure incident.

Likewise, distinguish hard bounces from temporary failures. Permanent failures belong in suppression workflows; soft failures need a controlled retry policy rather than unlimited resend attempts.

For B2B operations, the practical hierarchy is straightforward: placement establishes observed mailbox location; engagement helps evaluate recipient response. Neither should overwrite the other in your data model.

Automating Tests With Batch APIs and Async Webhooks

The production workflow needs independent state machines for recipient verification and sender-route testing. A prospect can become eligible for sending only when the recipient policy and the route policy both permit it.

Use synchronous verification when an interactive workflow needs an immediate decision. For imported lists and enrichment jobs, submit batches and process completion asynchronously. The webhook versus API workflow comparison is useful when deciding whether your application should wait, poll, or receive a completion event.

Define an application-level contract

The following is a proposed orchestration pattern, not a vendor request schema:

Import → normalize → submit verification batch → persist job reference → receive completion webhook → map verdicts → apply routing policy

Keep each stage restartable. My recommendation is to persist a correlation identifier before submitting work, verify webhook authenticity using the provider's documented mechanism, and make event processing idempotent. Duplicate notifications shouldn't enroll the same prospect twice.

For a waterfall-backed service, store execution logs showing which providers were tried, which answered, and what was billed. Fixed endpoint credits make reconciliation easier; where email or phone misses don't bill, keep those misses visible as unresolved outcomes rather than mistaking a low bill for high coverage.

Gate deployments with placement evidence

Run a CI-style preflight whenever a template or sending configuration changes:

• Create a candidate: Save the template and route configuration under a deployment identifier.
• Run controlled sends: Dispatch seed messages through the candidate route.
• Join observations: Associate mailbox results and sending events with that deployment.
• Evaluate policy: Approve, hold, or restrict the deployment by provider.
• Continue monitoring: Reopen the decision when production deferrals or placement regressions appear.

Authentication deserves an explicit gate. Mailgun's cited survey tracked DMARC usage from approximately 43% in 2023 to 54% after the 2024 requirements, reaching 61% in 2025. Don't infer correct configuration from adoption or from a previously passing deployment.

Engineering safeguard: A successful verification webhook must never stand in for a completed placement test.

Make alert thresholds configurable and establish them from your baseline. Route Microsoft deferral alerts to throttling controls, isolate a sender domain when route evidence deteriorates, and hold deployments with unresolved authentication failures.

Keep suppress, retry, and quarantine as different actions. Suppression prevents future sends, retry schedules another bounded attempt, and quarantine requires new evidence or review. Collapsing them into a boolean loses the operational decision you'll need during an incident.

Field-Tested Takeaways for Your Runbook

A useful runbook tells an operator what to do when evidence changes. It shouldn't require someone to reinterpret a generic deliverability score during a campaign incident.

Attach every trigger to an action

• Verification completes: Write address validity and server acceptance separately. Preserve uncertain results instead of enrolling them by default.
• A temporary failure arrives: Apply the scheduled retry policy and retain the reason. Escalate exhausted retries to quarantine, not invented certainty.
• A permanent recipient failure arrives: Suppress the address and propagate the decision to every connected sending workflow.
• A complaint or unsubscribe arrives: Stop further outreach to that recipient and review the affected campaign segment.
• A template or domain changes: Require a new deployment-linked seed test before expanding sends.
• Microsoft deferrals increase: Slow the affected route and investigate the provider segment rather than pausing unrelated healthy traffic automatically.
• Placement deteriorates for a sender domain: Hold that route, preserve its last passing configuration, and assign an owner to remediation.
• Authentication alignment fails: Block expansion until the configuration passes inspection and the candidate route is retested.
• Webhook processing fails: Keep the job pending and recover processing without treating missing results as approved recipients.

Make the audit trail usable

For every decision, retain the triggering observation, policy version, action, timestamp, and responsible owner or service. Record explicit exceptions with a reason and a review condition, so temporary workarounds don't become invisible permanent policy.

Keep dashboards segmented by provider and sender domain. Display recipient acceptance, uncertainty, actual-message delivery, and placement as distinct measurements, with engagement available for diagnosis rather than substituted for mailbox evidence.

The operating principle is evidence before expansion. Verification reduces recipient uncertainty, seed tests evaluate a sending route, and production feedback determines whether that route should remain active.

A team has a working deliverability process when an unfamiliar operator can identify the failing layer, find its evidence, and execute the next safe action without guessing.

RichAPI offers email verification, batch processing, and async webhooks through a unified API for existing GTM workflows. Visit RichAPI to connect recipient checks to your pipeline, retain verification outcomes, and pair eligible records with a separate provider-level seed-testing gate before sending.