Written and reviewed by the team operating TempMail Cloud. Product claims are checked against our live service and our editorial standards.
Test the delivered content in a controlled inbox, then test the actual email clients your audience uses. TempMail Cloud can show a received message in a restricted browser viewer. It does not emulate Gmail, Outlook or Apple Mail, generate cross-client screenshots, or prove that an attachment is safe.
Build one small, useful fixture
Use a staging template with a plain-text alternative, an informative image, a decorative image, one primary action and a fallback URL. Populate it with a long synthetic name and a long product title. Use your own staging host for links and a non-sensitive identifier such as QA-RENDER-07 for correlation.
Send the fixture through the same template-generation path you want to assess. Save its template version and the exact test inputs. An invented screenshot of an email is not evidence of what the sending system produced.
| Variation | What to inspect | Where to inspect it |
|---|---|---|
| Long name and title | Wrapping, missing variables and clipped actions | Received body, then target clients |
| Images unavailable | Text still explains the action and identity | A client or diagnostic environment that can block images |
| Narrow viewport and enlarged text | Readable content without losing the action | Actual supported client and device configuration |
| Text-only part | Destination and essential instructions remain present | Plain-text view or the sending fixture |
| Missing optional field | Clean omission rather than an empty label | Rendered message and generated template output |
These are proposed test cases, not claimed results. Fill in observed behavior after running them against your own template.
Use the inbox for what it can show
Compare the visible sender, subject, recipient, received time, text and HTML with the intended fixture. An extracted number is a convenience, not proof that the correct OTP was generated; inspect the surrounding message.
Our viewer uses an iframe boundary and content restrictions. Its presentation may differ from a mail client's sanitizer and CSS engine. Remote HTTPS images may load, so the sandbox is not a guarantee against tracking pixels. Avoid opening unexpected messages merely to collect visual evidence.
Full raw transport headers and complete MIME parts require an appropriate source view, sender logs or another diagnostic tool. Do not invent those observations from the sender label displayed in an inbox.
Test the clients separately
Choose a matrix based on the clients you support, recording application version and platform. Gmail's own documentation lists the CSS it supports and notes that unsupported properties may be ignored. That is one reason a normal browser preview cannot stand in for every email application. Gmail CSS support.
For example, a button may be legible in the TempMail Cloud browser view and clipped in a specific desktop client. Record that as a client-specific rendering defect, not a delivery failure. Conversely, the right layout with another user's name is a data defect even if every client displays it identically.
Report a defect without exposing credentials
Record the case identifier, template version, expected result, observed result, client and viewport. Redact active reset links and codes from screenshots. Retest with a newly sent fixture after a change so a cached old message cannot pass the test accidentally.
For behavior after following a link, use verification-flow testing or password-reset testing. For missing messages, use delivery diagnostics.