Email template preview workspace
A design mockup shows what an email should look like. A real inbox shows what was actually sent. Use a fresh address to check the subject, message, and next steps together.
Whether the content is complete, the verification code is clear, and the HTML structure and basic layout look right.
It cannot replace compatibility testing across desktop and mobile email clients, or prove that an email will reach the inbox.
If an email hasn’t arrived, start with delivery troubleshooting. If it arrived but looks wrong, check the template.
Before you begin
Keep the environment, data, and template version fixed. Change only the recipient address so it’s easier to reproduce issues.
Make sure you’re allowed to trigger signup or password reset emails. Check environment labels and callback domains to avoid sending test actions into production.
Use a fictional name and test data. Don’t submit customer addresses, payment details, or production credentials.
Note the template version, expected subject, code expiry, and language for this run. Use the same inputs before and after making changes.
In the inbox on the homepage copy the currently active address. Use a fresh address for each run so you don’t mistake a previous code for the current result.
Ideal for signup, password recovery, and OTP checks you can complete in a few minutes. Temporary addresses last 3 hours by default; each extension adds 3 hours, up to 24 hours per address.
Receive only; sending isn’t available. Expired emails can’t be recovered. Save any screenshots and redacted records you need before the address expires.
Use a temporary address →Ideal for ongoing regression tests, scheduled notifications, and test accounts that need to receive email the next day. Create an alias after logging in, and incoming mail will be forwarded to your real inbox.
Forwarding can affect how an email looks in the destination client. When recording results, note whether you viewed it directly in the temporary inbox or after alias forwarding.
Log in to use an alias →Test a signup email
This page is a testing guide; it won’t send email on behalf of your app. Trigger the actual send from a test system you’re authorized to use.
Open the homepage, wait for an address to appear, and check how much time is left. Copy the full address, then make sure it has no extra spaces or missing characters when pasted.
Submit a test account in your staging environment and note the submission time and template version. Check whether the app actually queues an email, rather than relying on an on-screen confirmation.
Return to the auto-refreshing inbox. Note the arrival time, and avoid repeated sends that could muddle the results. If the email is delayed, check the address and sending logs first.
Open the matching subject, verify the sender and the code for this run, then check the message and action links. Don’t judge the template by the inbox preview alone.
One case per run: Link the recipient address, request ID, and send time in your app’s test records. The old address expires when you switch to a new one, so save any evidence you need first.
Email reading and review workspace
The two static examples below represent a verification email and a transaction notification. They illustrate review techniques; they aren’t real account notifications or proof of client compatibility.
Netflix · demo@netflix.example
A new device is trying to sign in to your account. If this was you, enter the code below on the sign-in page.
This is a Tempcase demo and is not affiliated with Netflix. The example code can’t be used to sign in to a real account.
Acceptance check: Without relying on images, can users tell which sign-in this is for, copy the full code, and see when it expires?
Uber · demo@uber.example
This sample receipt is for reviewing transactional email layout.
This is a Tempcase demo and is not affiliated with Uber. It doesn’t represent a real trip or payment.
Acceptance check: Do the receipt number, amount, currency, and trip details match? On a narrow screen, is the full receipt number still readable?
Compare HTML and plain text
Review the rendered email here, inspect its structure in the HTML source, and check the plain-text part in your sending system. Seeing the HTML doesn’t mean the email includes a usable plain-text version.
| Check | What to look for in HTML | What to check in plain text | Pass criteria for this run |
|---|---|---|---|
| Line wrapping on narrow screens | Narrow the browser and check the code, long order numbers, and button labels. Look for fixed widths and content that can’t wrap. | Check how long paragraphs, numbers, and URLs are separated. They should be understandable without relying on table column widths. | Key information isn’t cut off, and users don’t need to scroll sideways to complete the main action. |
| Font fallbacks | Check the layout without brand fonts, especially Chinese text, numbers, amounts, and button height. | Keep clear labels and paragraphs. Don’t use spaces to create tables that depend on monospaced alignment. | The hierarchy remains clear with system fonts, and no numbers or punctuation disappear. |
| Images missing | Check how the email looks when remote images don’t load, including alt text and placeholder sizing. Verification codes must not depend on images. | The company name, purpose of the action, expiry, and essential links should appear as text. | Users can still understand what happened and what to do next without the logo or decorative images. |
| Dark mode readability | Test backgrounds, text, transparent logos, and button borders in dark mode in your target email clients. | Avoid color-dependent instructions like “click the green area.” Describe the action directly. | Key text has enough contrast. Passing a light-mode browser preview doesn’t count as passing dark mode. |
| Content consistency | Check the code, amount, receipt number, expiry, and link parameters. Look for leftover template placeholders. | Check the text/plain part in the sending-side MIME or logs and confirm it matches the same data as the HTML. | Key details match in both versions; there are no old codes, old amounts, or links for a different environment. |
Tempcase renders HTML emails in an isolated environment, where dangerous scripts and some interactive content are restricted. Remote images, fonts, and styles may also be affected by resource permissions, hotlink protection, or network conditions; embedded attachment images may not appear either. Check that resources are accessible before deciding the template is at fault.
Browsers and desktop or mobile email clients don’t use exactly the same rendering rules. Before release, retest in the clients you actually support. To inspect plain-text MIME, headers, or attachments, also check the original test email retained by your sending system. This page is not an HTML uploader or a cross-client screenshot service.
Retest records
A screenshot shows the result; the version and inputs are what make it reproducible. Record exactly which email arrived, and don’t treat one successful delivery as proof that every scenario passed.
The times above are examples of a record format, not a delivery-time guarantee. Before sharing screenshots, hide verification codes, reset tokens, full recipient addresses, and customer data. Never submit usable credentials in a public issue tracker.
Check that the verification code matches the account, the expiry is clear, and the behavior of older codes after resending is handled correctly. A correctly displayed email doesn’t confirm the server-side rules; test those in the app.
Check the reset purpose, link environment, expiry, and guidance for requests you didn’t make. Link expiry and single-use behavior must be verified in the authorized app, not judged by the button’s appearance.
Check amounts, currency, time, reference numbers, and line items. Retest with long product names, multiple items, and different languages; don’t rely on the shortest receipt to confirm the layout is robust.
FAQ
Delivery, content, layout, and business-rule validation are four different outcomes. Track them separately to avoid fixing the wrong thing.
Open the verification email delivery diagnosticDon’t change the template styling yet. Check the recipient address, address expiry, send task, and sending logs, then follow the delivery troubleshooting steps to find the cause. If the message hasn’t arrived, you can’t yet attribute the issue to the layout.
Not necessarily; that doesn’t cover every email client. This preview is useful for checking content and basic layout, but before release you still need to test wrapping, image handling, and dark mode in your target desktop and mobile email clients.
Your sending system may not have generated a text/plain part, or the current display may not show it. Viewing the HTML source isn’t the same as viewing the plain-text message. Check the original MIME on the sending side to confirm both versions are included.
No. They’re original Tempcase demos with no brand affiliation, included only to illustrate how to review verification codes and receipt details. They don’t provide real account services and must not be used to impersonate brand emails.
Use a long-term forwarding alias, or a long-term email account you’re authorized to use. Temporary addresses last up to 24 hours and can’t be recovered after expiry, so don’t use one for an account you’ll need to recover later.
Use these checks on your next email
Use a one-off inbox for a single test run and a forwarding alias for regression tests across days. Receive a real email first, then decide what needs to change in the template.
