How many email clients should I test a template in?

A practical baseline is Outlook on Windows and the web, Gmail on web and mobile, Apple Mail on macOS and iOS, and one Android client. Add any client your audience disproportionately uses. Testing a small, consistent set catches most layout breaks without turning every send into a full QA cycle.

Can I use a disposable inbox to test my email templates?

Yes, for short iteration loops such as checking that a signup or verification email arrives and that a code is detected. A disposable inbox is not a stable test address: on MailboxTemp an inbox lives for 60 minutes by default (extendable), and Pro inboxes last 24 hours. For long-running tests, use a real mailbox you control.

Does a good spam score guarantee my email will reach the inbox?

No. Spam-scoring tools flag specific issues such as a missing plain-text part, suspicious link domains, or image-heavy content with little text. Fixing those issues helps, but actual inbox placement depends on sender reputation, recipient engagement, and filtering decisions you cannot see. Treat the score as a checklist, not a promise.

Why does my template look broken in Outlook but fine in Gmail?

Outlook on Windows uses Microsoft Word's rendering engine for HTML, which ignores many modern CSS features such as flexbox, grid, and some background properties. Gmail uses a different engine with its own limits. Build with table-based layouts and inline CSS, and test in Outlook first, because it is usually the most restrictive.

What should the plain-text part of an email contain?

A readable version of the message: sensible line breaks, links written as full URLs that can be copied, the unsubscribe instruction, and no references to images the recipient cannot see. Many senders generate it automatically from HTML, which often produces broken output, so review it as a document in its own right.

How to Test Email Templates Before Sending: The Full Checklist

To test an email template before sending, check four things: how it renders across clients (including dark mode), whether every link and tracking parameter works, whether a plain-text part exists and is readable, and whether your sending domain is authenticated with SPF, DKIM and DMARC. Then send real test messages to inboxes you control. This guide walks through each step as a practical checklist for developers and marketers.

Why template testing matters more than most teams think

Email is one of the few channels where you cannot patch a mistake after delivery. A broken link, a missing plain-text part, or a dark-mode contrast failure is visible to every recipient, and some of those failures (especially authentication problems) affect deliverability for weeks. Testing before sending is not perfectionism; it is the minimum bar for a message that carries your brand and possibly a transaction.

The failure modes are well known but easy to forget under deadline pressure. Outlook on Windows uses Microsoft Word's rendering engine for HTML, which ignores many modern CSS features. Gmail strips some <style> blocks in certain contexts. Apple Mail applies dark-mode inversion that can turn white logos into invisible shapes. Link tracking rewrites URLs and can break deep links or unsubscribe flows. Sending domains without proper authentication land in spam or get rejected outright.

None of these are exotic. A checklist that covers them takes an afternoon to build and saves repeated embarrassment.

How do you check rendering across email clients?

Rendering is the first thing recipients notice and the hardest to test exhaustively. There is no single standard: each major client uses a different HTML and CSS engine, and the same template can look polished in one and broken in another. The practical approach is to pick a representative set of clients and test against them consistently.

Pick a representative client set

Most teams settle on a small matrix rather than testing everything. A reasonable baseline:

Outlook on Windows (desktop) — the most restrictive renderer; if it works here, it usually works elsewhere.
Outlook on the web — different engine from desktop and often used by corporate recipients.
Gmail on web and mobile — the largest consumer client; note that Gmail clips messages over roughly 102 KB.
Apple Mail on macOS and iOS — important for dark-mode behaviour.
A mobile client on Android — often Gmail or Samsung Mail, depending on the device.

Add any client your audience disproportionately uses, based on your own analytics or support tickets.

Use rendering tools, but verify manually

Services such as Litmus and Email on Acid render your HTML in real client engines and produce screenshots. They are useful for catching layout breaks quickly, but they are not a substitute for sending to a real inbox and looking at it yourself, especially on a phone. Screenshots can miss hover states, animation fallbacks, and how a message behaves when images are blocked by default.

Check image blocking and alt text

Many clients block remote images until the recipient allows them. Your template must remain legible with images off: alt text should describe the image and, where the image carries meaning (a price, a date, a code), the same information should appear as text. Test with images disabled in at least one client.

What breaks in dark mode, and how do you test it?

Dark mode is where otherwise solid templates fail. Clients handle it differently: some invert colours automatically, some respect prefers-color-scheme media queries, and some do a mix. The result is that a logo designed for a white background can disappear, and text can end up dark-on-dark.

Practical checks:

Logos and icons: use transparent PNGs or SVGs with sufficient contrast, or supply a dark-mode variant via a media query where supported.
Background and text: avoid pure white backgrounds with pure black text if you can; slightly off-white and dark grey degrade more gracefully under inversion.
Buttons: check that button text remains readable when the button background is inverted.
Test on a real device: Apple Mail on iOS and macOS is the most common place to see dark-mode issues; toggle the system setting and look at the message.

Support for prefers-color-scheme in email clients changes over time, so verify current behaviour rather than assuming a fixed list. If a client ignores your media query, the fallback design must still be acceptable.

How do you verify links, tracking and the plain-text part?

Links and tracking parameters

Every link in the template should be clicked in a test send, not just eyeballed in the HTML. Tracking systems rewrite URLs, and a rewrite can break a deep link, strip a query parameter, or point to a staging host. Check:

Each link resolves to the intended destination, including any utm_ parameters.
Unsubscribe and preference-centre links work and are one-click where required.
Deep links into a mobile app open the app if installed and fall back gracefully if not.
Links do not point to localhost, staging domains, or preview environments.

If you use a link-tracking domain, confirm it is authenticated too; a tracking domain without SPF and DKIM alignment can hurt deliverability even when the main sending domain is set up correctly. Our guide to email tracking pixels explains how opens are recorded and where the signals can mislead.

The plain-text part

Multipart messages should include a text/plain alternative. Many senders generate it automatically from the HTML, which often produces unreadable output: broken line lengths, raw URLs, and stripped structure. Review the plain-text part as a document in its own right:

Does it read naturally, with sensible line breaks?
Are links written as full URLs that a recipient can copy?
Is the unsubscribe instruction present and clear?
Does it avoid referring to images the recipient cannot see?

A well-formed plain-text part also helps spam filters, which weigh the text-to-HTML ratio and the presence of a text alternative.

Is your sending domain authenticated before you test content?

Content testing is wasted if the message never reaches the inbox. Before testing templates, confirm the sending domain is authenticated. The three records that matter are SPF, DKIM and DMARC; our plain-English explainer on SPF, DKIM and DMARC covers what each does.

Minimum checks:

SPF: a single TXT record listing the sending services you actually use, within the ten-lookup limit.
DKIM: a selector published in DNS and signing enabled at the sending service; verify the signature passes on a test message.
DMARC: a policy record published at _dmarc on your domain, with reporting addresses so you can see failures.
Alignment: the From domain should align with the authenticated domain, or DMARC will fail even if SPF and DKIM pass on a different domain.

For the underlying standards, see RFC 6376 for DKIM and the DMARC specification. Use a test message to confirm the results: most clients let you view the raw source and the authentication results, and our guide to reading email headers explains how to interpret them.

Spam score is a signal, not a verdict

Spam-scoring tools such as SpamAssassin or the checks built into sending platforms flag common problems: missing text part, suspicious link domains, image-heavy content with little text, and malformed HTML. Treat the score as a checklist of things to fix rather than a guarantee of inbox placement. Real placement depends on sender reputation, recipient engagement, and filtering decisions you cannot see. Do not chase a perfect score; fix the specific issues the tool reports and move on.

How should you send test messages without polluting real inboxes?

Test sends should go to inboxes you control and can discard. A few practical options:

Seed addresses on your own domain: a mailbox you own at a major provider (Gmail, Outlook) is the closest thing to a real recipient.
A dedicated test domain: useful for staging, but remember it needs its own authentication records.
A disposable inbox for quick iterations: convenient for checking that a message arrives and that a one-time code is detected, especially while iterating on signup and verification flows. Our guide to testing signup and verification emails covers this in more depth.

A disposable inbox is a practical choice for short-lived test sends because it keeps test mail out of your real mailbox and avoids the temptation to reuse a personal address in staging configs. Keep in mind that a disposable inbox is temporary: an inbox on MailboxTemp lives for 60 minutes by default, extendable in ten-minute increments, and Pro inboxes last 24 hours. That is fine for a quick send-and-check loop, but it is not a place to keep a long-running test address. If you need a stable test mailbox, use a real address you control.

Also be honest about limits: some platforms block disposable addresses at signup, and a test that relies on one may fail for reasons unrelated to your template. Where a platform rejects disposable addresses, use a real test mailbox instead. Our guide to why websites block disposable emails explains the pattern.

What else should be on the pre-send checklist?

Beyond rendering, links and authentication, a few items catch problems that are easy to miss:

Personalisation fallbacks: send a test with an empty first name and confirm the fallback reads naturally.
Subject line and preheader: check length, truncation on mobile, and that the preheader does not repeat the subject.
Accessibility: sufficient contrast, meaningful alt text, and a logical reading order for screen readers.
Volume and timing: a small seed send before the full list, and a send time appropriate to the audience's time zone.
Reply-to and from addresses: confirm they are monitored and that replies do not bounce.

For teams that send verification or signup mail, it is also worth confirming how codes are detected and displayed; our explainer on how OTP verification works is a useful companion.

Sources

RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — the specification for DKIM signing and verification.
RFC 7489: DMARC — the DMARC specification, including alignment and reporting.
NIST SP 800-63B: Digital Identity Guidelines — guidance on authentication and verification channels relevant to signup email design.

In short

Test email templates in four layers: rendering across a representative client set including dark mode, every link and tracking parameter, the plain-text alternative, and sender authentication on the domain. Send real test messages to inboxes you control, use disposable inboxes only for short iteration loops, and treat spam scores as a fix-list rather than a guarantee.