MailSlurp logo

blog

Email Deliverability Test: Inbox Placement and Spam Checks Before Launch

Run an email deliverability test before launch with inbox placement, SPF, DKIM, DMARC, spam-risk checks, content review, and monitoring.

Email Deliverability Test: Inbox Placement and Spam Checks Before Launch article preview

An email can be marked "sent" and still leave someone waiting for a password reset or hunting through spam. A deliverability test follows the message further: check the sender's authentication, where it lands, what it contains and whether it arrives in time.

This guide explains what a real deliverability test includes, how to run one before launch, and what to monitor after the first send goes live.

Quick answer

An email deliverability test should verify four things:

  • sender identity: inspect SPF and DKIM results and verify DMARC alignment with the visible From domain
  • message quality: links, HTML, headers, and copy do not create avoidable risk
  • mailbox placement: critical messages land where users will actually see them
  • workflow outcomes: signups, resets, invoices, and campaigns arrive with the right timing and content

If you only check delivery APIs or SMTP acceptance, you will miss the failures that hurt conversion most.

Start with these MailSlurp checks:

Start with a practical deliverability test

Use the Email Deliverability Test walkthrough to check a message from your app or campaign. It covers receipt, authentication, spam findings and provider placement.

Keep the checklist beside you when testing a release or campaign. The sections below explain how to interpret the results and choose your next check.

Which deliverability test should you run?

Different questions need different checks. Use the narrowest test that answers the launch question, then combine checks for critical workflows.

Question Test to run MailSlurp path
Will this message reach a usable inbox? Inbox receipt and placement test Email deliverability test
Is the message likely to trigger spam filters? Spam-risk and content check Email spam checker
Are SPF, DKIM, and DMARC healthy? Sender authentication check SPF checker, DKIM checker, and DMARC checker
Where did the received message actually land? Provider placement review Inbox placement test
Can this be repeated before every release? Automated inbox workflow test Email integration testing

For important signup, reset, billing, and campaign messages, run these checks together. A single score is less useful than evidence that the real message arrived, carried the right authentication signals, and supported the user action.

What a free account can prove first

Start with one message that matters: signup verification, password reset, invoice delivery, or a launch announcement.

With a MailSlurp account, you can:

  1. Create a controlled inbox for the test.
  2. Send the final message through the same provider, SMTP relay, API, or campaign workflow you plan to use.
  3. Confirm the message arrives, then inspect subject, sender, body, links, attachments, and timing.
  4. Check SPF, DKIM, DMARC, return-path, and routing headers from the received message.
  5. Add spam, placement, blacklist, or domain-monitoring checks when the first result shows risk.

For a password reset, finish by opening the link and checking that the app accepts the new password.

What email deliverability testing actually measures

Deliverability testing is not just "did the message send?"

It checks where the message arrived, what the received authentication results show, and whether it arrived in time for the user to complete the intended action.

That matters across:

  • signup verification
  • password reset and magic links
  • billing receipts and invoices
  • alerts and incident notifications
  • campaigns and lifecycle messages

Delivery rate vs deliverability vs inbox placement

These terms overlap, but they are not interchangeable.

Delivery rate

Delivery rate measures whether the receiving system accepted the mail. A provider can accept a message and still route it to spam, promotions, or a low-visibility folder later.

Deliverability

Deliverability concerns whether email reaches its intended recipients. Check authentication, provider placement and arrival time together when investigating a missing or late message.

Inbox placement

Inbox placement is the mailbox-location result inside that broader deliverability picture. It tells you whether the message landed in inbox, spam, promotions, updates, or another mailbox bucket.

If your team only watches send success, it will miss the business failures that matter most.

What to test before a campaign or product launch

Most deliverability issues are operational. They come from auth drift, rushed template changes, sender-volume spikes, or hidden provider differences.

Use this sequence before any important send:

1. Test authentication posture

Validate SPF, DKIM, and DMARC before you inspect the template:

If sender identity is broken, content tweaks will not save placement.

2. Test inbox placement

Run an inbox placement test so you know where messages land across the providers that matter to you:

  • primary inbox
  • spam or junk
  • promotions or updates
  • missing or delayed

This is the check most teams skip, and it is often the one that explains why a "working" campaign underperforms.

3. Test content and spam risk

Review the actual message, not just the template source:

Look for:

  • broken links
  • missing images
  • malformed HTML
  • suspicious link domains
  • weak plain-text fallbacks
  • header or return-path inconsistencies

4. Test the real workflow

Trigger the exact path that matters:

  • signup confirmation
  • password reset
  • invoice delivery
  • campaign send with personalization
  • account alerts or security notices

The email deliverability test walkthrough shows how to inspect the message that arrives from that send.

How to test email deliverability step by step

Work through these steps for the campaign, migration or template change you want to test.

Step 1: choose your critical send paths

Do not start with every email you send. Start with the messages that create revenue, access, or support load:

  • verification email
  • password reset
  • invoice or receipt
  • high-volume campaign
  • account and security notifications

Step 2: establish a sender baseline

Confirm:

  • which domain and subdomain are sending
  • which provider or relay is involved
  • what SPF includes and DKIM selectors are active
  • which DMARC policy and report addresses are live

This baseline matters later when something degrades and you need to know what changed.

Step 3: send controlled test messages

Choose the recipient setup for the question you are testing. A MailSlurp inbox captures an application's email so you can assert its content and arrival time. A provider seed test observes where Gmail, Outlook and other configured mailboxes place a campaign. Use both when a release needs message assertions and provider-folder evidence.

For an application email, create a controlled inbox, use its address in the signup or reset workflow, and wait for the matching message after triggering the action. Inspect the received headers, code or reset link, and record how long the message took to arrive.

For a campaign deliverability test:

  1. Open Inbox placement, create a run, and copy its current marker and complete seed list.
  2. Add the marker to the final subject or body. Keep the campaign's normal sender, links, tracking and unsubscribe setup.
  3. Put the current seeds in a separate test audience in your ESP. Check its selected and excluded recipient counts before sending; a suppressed address has not received a test.
  4. Send only to that audience through the campaign's normal route, then confirm the send in MailSlurp after submission succeeds.
  5. Wait for the completed provider results. Keep Primary, Promotions, Spam and not-received outcomes separate, and investigate any unresolved result.

The seed-list guide covers audience isolation and exclusions. For platform-specific controls, follow the HubSpot, Klaviyo or Mailchimp walkthrough. A fresh run gives the next revision its own marker and addresses.

Step 4: review the evidence

Compare these results from the test:

  • inbox vs spam distribution
  • delivery timing
  • authentication pass or fail
  • header anomalies
  • content and render issues
  • provider-specific outliers
  • render or mobile-layout problems that explain weak engagement after placement looks healthy

Read authentication from the received message as well as DNS. DMARC can pass through an aligned SPF result or an aligned DKIM signature; an unrelated passing signature alone is insufficient. The DMARC alignment rules explain that distinction. A DNS record's existence does not prove the final send used it correctly.

Step 5: fix, then re-test before rollout

Do not ship on the first clean send status. Ship after the fixes hold through a retest.

Common causes of failed email deliverability tests

The root cause is usually not mysterious. It is usually one of these:

  • SPF records that no longer match the real sender path
  • DKIM selectors rotated in one system but not another
  • DMARC alignment breaking after provider or subdomain changes
  • templates introducing broken links, missing assets, or spam-like structure
  • send-volume spikes from migrations or campaigns
  • marketing and transactional traffic sharing one identity
  • weak rollback discipline after DNS or provider changes

How MailSlurp makes deliverability tests repeatable

MailSlurp turns a deliverability check into a workflow that can run before every launch:

  1. Create a fresh inbox or use a managed test inbox for the workflow.
  2. Send the exact template through the production-like SMTP, API, or campaign path.
  3. Wait for the expected subject, sender, or recipient in MailSlurp.
  4. Inspect headers for SPF, DKIM, DMARC, return-path, and routing evidence.
  5. Check body content, links, attachments, and OTP or reset tokens.
  6. Record pass/fail results and re-run the same test after fixes.

Save the test with the app or campaign it checks. When DNS, provider settings or the template changes, rerun it and compare the received messages.

Release-gate checklist for deliverability

Before a campaign or product change goes live, confirm:

  • SPF, DKIM, and DMARC pass
  • inbox placement is acceptable on the providers that matter
  • critical links, images, and dynamic content are correct
  • latency is within your threshold
  • recent sender, DNS, or provider changes are documented
  • rollback owners are clear if the first send goes wrong

What to do after launch: monitor, do not assume

Deliverability testing before launch is only half the job. Once volume starts, you need ongoing monitoring.

Track:

  • inbox placement drift
  • complaint rate changes
  • blacklist movement
  • auth failures
  • provider-specific anomalies
  • delivery latency on critical flows

For that ongoing layer, use deliverability monitoring, domain monitor, and Campaign Probe for continuous email quality monitoring of recurring sends.

Common mistakes teams make

Using acceptance as a success metric

Accepted mail is not the same as inbox placement. This mistake hides most failures until support tickets arrive.

Testing only content, not identity

If SPF, DKIM, or DMARC are broken, a polished template still fails.

Running one-off checks with no baseline

Without a baseline, teams cannot tell if a result is normal or a regression.

Treating campaigns and transactional email the same

Password resets and invoices should not inherit the same risk profile as a large blast.

When a critical message is already failing, use the transactional email incident worksheet to keep provider events, received headers, placement, latency, and the controlled retest in one investigation.

MailSlurp workflow for email deliverability testing

With MailSlurp, you can:

  • run controlled inbox and placement tests
  • inspect real received messages and headers
  • preview delivered HTML in supported client and device contexts
  • capture links, codes, attachments, and evidence in CI
  • pair message tests with domain and sender monitoring
  • keep recurring campaign and lifecycle streams under review with Campaign Probe

Recommended path:

FAQ

How do you test email deliverability?

Test sender authentication, spam risk, inbox placement, and the real end-user workflow together. Good tests inspect real received messages, not only send logs.

What is the best email deliverability test?

The best deliverability test is the one that combines auth checks, placement evidence, and workflow assertions for the messages that matter most to your business.

How often should you test email deliverability?

Before every significant campaign, provider migration, domain launch, or major template change. After launch, switch to ongoing monitoring.

Is inbox placement part of deliverability testing?

Yes. A message can be accepted by the provider and still fail the business outcome if it lands in spam or another low-visibility folder.

What should you monitor after a deliverability test?

Track inbox rate, spam rate, auth drift, complaint changes, blacklist events, and delivery timing for critical transactional flows.