guides
What Is Email Testing? Definition, Types, Tools, and Practical Examples
Learn what email testing is, which email tests to run first, and how to verify inbox receipt, OTP codes, links, rendering, and deliverability before launch.
By Nicole Penn
Use with your tools

Email testing checks whether an email arrives, looks right and lets the reader do what they came to do. For a marketing campaign, that might mean reading an offer on an iPhone and opening its booking link. For an app, it might mean receiving a password reset and successfully changing the password.
A successful send is only the beginning. Your email platform can accept a message even when a recipient later finds it in spam, sees a broken layout or taps the wrong link. Each of those problems needs a different check.
If you are testing an application's signup, login or reset flow, start with the automated email testing walkthrough. It follows the message from the user action to the final assertion. For an existing browser suite, use the Playwright guide or Cypress guide. The sections below explain how those functional checks fit alongside campaign, rendering and delivery tests.
Email testing types
Start with the question you need answered. You do not need to write code to review a campaign's appearance or test its placement.
| Your question | The test to run | What to inspect |
|---|---|---|
| Does the email look right on phones and desktops? | Device rendering | Text, columns, images and buttons in the supported clients and display modes your audience uses |
| Do the campaign's links and images work? | Email Audit | Broken destinations, missing images and other content findings in the finished email |
| Does it reach inbox or spam? | Inbox placement testing | Results for the actual Gmail, Outlook and other provider samples in the test |
| Is the sender set up correctly? | Domain monitoring | SPF, DKIM, DMARC and other available domain checks |
| Can someone complete signup, login or a password reset? | Email integration testing | The received message, its code or link, and the result of using it in the app |
These tests complement each other. A screenshot shows appearance; it does not establish that the button opens the correct page. A message received by a test inbox proves receipt there; it does not establish where Gmail placed another copy.
Opening the campaign on one phone cannot show how another email app handles its layout. MailSlurp is an email testing service: it receives your test message and lets you compare device screenshots, inspect content and check inbox placement. Its inbox API also lets application tests use the received codes and links.
How automated device rendering works
Choose the devices and email services you want to test, and MailSlurp gives you a special email address. Send your campaign to that address. MailSlurp opens the email in the selected apps and webmail services, then captures screenshots automatically.
The screenshots come back together, ready to compare across phones, tablets and computers. Check the layout, images and buttons, then share a result link so your team can review the same version of the email.

How to test a marketing email before sending
Use a copy of the finished campaign in your email service provider, or ESP. Include the same sender, tracking settings and content you intend to send. A builder preview is useful while editing, but the delivered message is the version your customer receives.
Preview it in the clients your readers use
Create a MailSlurp device preview, copy its render address and send the campaign to that address from your ESP. Review the completed results for the relevant iPhone, Android and desktop clients, including light and dark mode where available.
Look beyond the opening screen. Can you read the offer without zooming? Do two columns stack in the right order on a phone? Is the logo visible in dark mode? Is the footer still there?
Our Mailchimp rendering guide and HubSpot rendering guide show the provider-specific steps. Use the mobile email preview guide when the problem is a narrow screen.
Check the content and destinations
Run an audit of the finished email, then review the findings against the intended campaign. A working URL can still point to last month's offer, so open the important destinations as well. Check prices, dates, personalization, image descriptions and the preference or unsubscribe links.
Include the versions of the message that differ materially. A campaign with a conditional product row or a long customer name can behave differently from a test using short, empty fields.
Test inbox placement separately
Start an inbox placement test and use its current recipient list and tracking marker. Send through the campaign's normal ESP, confirm the send and wait for the results. Keep inbox, Promotions, spam and unresolved outcomes distinct.
The Mailchimp inbox placement walkthrough shows the complete process. The result describes the mailboxes sampled in that run; it is useful evidence for the campaign, not a promise about every subscriber.
A rendering problem that a quick glance misses
In our Gmail clipping test, a short newsletter with excessive hidden formatting lost its footer behind Gmail's clipping notice. Reducing the redundant markup restored the footer in the next Gmail web capture, even though the visible campaign copy stayed the same.
That is why a review needs the complete message. An attractive first screen does not tell you whether the last product, offer condition or unsubscribe link survived. After a repair, send the revised campaign again and inspect the affected client as well as the other important clients.
How to test app emails, OTPs and password resets
Application testing starts with a user action, such as requesting a one-time password (OTP) or resetting a forgotten password. For example, create a test inbox, request a password reset for that address and wait for the matching message. Then extract the reset link, open it and verify that the new password works.
The final assertion matters. Checking that the body contains a link would miss a reset page that rejects its token. Depending on the flow, also test an expired code, a reused link and the message sent after a second reset request.
Decide where the test starts and ends
An integration test can call your signup API, receive its email and submit the verification code to your API. A browser end-to-end test also exercises the form and the browser session. Keep both focused on the same user outcome, while making clear which parts the test actually covers.
| Step | Useful assertion | A failure it catches |
|---|---|---|
| Request signup or reset | Your application accepts the intended test user and starts the correct flow | A form or API request that never schedules the email |
| Receive the message | The expected sender, recipient and subject arrive after this request, within a bounded wait | An old or unrelated message accidentally passing the test |
| Use the code or link | The code has the expected format, or the link belongs to your test application, before submission | A wrong code, wrong environment or unrelated URL |
| Check the application | The account is verified, the session is signed in, or the new password works | A valid-looking email whose action fails |
Create a separate inbox for each parallel scenario. Record the request time before triggering the email and use it as the lower bound when waiting for the message. Give the test runner more time than the email wait, then delete the test resources in teardown. The email wait troubleshooting guide explains how to distinguish a sender failure from a test that stopped waiting too soon.
MailSlurp's inbox APIs let automated tests receive and inspect those messages. Automated email testing explained covers the implementation and CI workflow. Keep these functional tests alongside campaign rendering and placement checks when the same email serves both purposes.
What makes a useful email test result?
Keep the campaign or template revision with the result, the sender used, the clients or mailbox providers checked, and the issue that needs fixing. Record what you actually observed: a broken image in Outlook, a missing Gmail footer, a spam placement result or an expired reset token.
After the correction, repeat the affected test with the new message. If the template changed, review rendering again. If the sender or authentication changed, run another placement test. A late edit after approval is a good reason for one more check.
Common questions
Is sending a test email to myself enough?
It is a useful first check for copy and links. It only shows your mailbox and device, though. Add the clients your audience uses and a placement test when inbox versus spam is the question.
What is the difference between email testing and A/B testing?
Email testing checks that a message works. A/B testing compares variants, such as two subject lines, to learn which performs better with recipients. Check both variants for rendering, links and content before comparing their campaign performance.
Can marketers test emails without a developer?
Yes. You can send from your ESP to MailSlurp's supplied addresses, review device previews, inspect audit findings and run placement checks. Bring in a developer when a custom template or application flow needs a code change.
Does a good spam score prove inbox delivery?
A score summarizes a particular set of checks. It does not replace observing placement in real provider mailboxes. Our SpamAssassin score guide explains how to read rule-based scores and combine them with placement results.
For your next campaign, start with the finished email in MailSlurp: review how it looks, check what readers can click and see where the test copies land.