Email Testing Tools: Preview, Spam Check, and QA
A pre-send checklist and the tools for each step, including the check most senders skip until it costs them.
On this page
The short version
- A pre-send checklist matters more than any tool. Most bad sends are caused by something on it that nobody looked at.
- Rendering previews catch the faults that only appear in clients you do not use — which is most clients.
- The check most often skipped is clicking every link in the actual test send, and it is the one that catches the errors readers notice.
Testing tools cover three jobs: showing how a message renders across clients, estimating whether it will be filtered, and validating the mechanics — links, merge tags, tracking, unsubscribe.
The third is the one that catches the most consequential errors and needs the least tooling. Most of it is a checklist and a test send.
A pre-send checklist, and what checks each
| Check | Tool | Catches |
|---|---|---|
| Renders in Outlook on Windows | Rendering preview | The client most likely to break a layout |
| Renders on a phone and in dark mode | Preview, or a real device | Invisible logos, oversized footers |
| Images blocked | Preview with images off | An email that is unreadable without them |
| Spam-score mechanics | Spam checker | Missing unsubscribe, broken authentication |
| Every link clicked | A test send and a mouse | Wrong URLs, placeholder links, broken tracking |
| Merge tags with an empty value | A test to a contact with blank fields | "Hi ," and worse |
| Unsubscribe works | Click it on the test send | The fault with legal consequences |
| Subject and preview together | Look at the inbox list | A preview repeating the subject |
What rendering previews are for
Seeing your email in clients you do not have. Outlook on Windows renders with a different engine from everything else and breaks layouts nothing else breaks; several webmail clients strip the head; dark mode implementations differ substantially.
The value is highest when you build custom templates and lowest when you use one template repeatedly. A template that has been checked once and not structurally changed does not need re-checking every send.
That suggests the right cadence: preview thoroughly when the template changes, and spot-check on a phone and in Outlook for routine sends.
How much to trust a spam score
Spam checkers are useful for mechanical faults — a missing unsubscribe, unauthenticated sending, a blocklisted link domain, an extreme image-to-text ratio. Those are real findings and worth acting on.
The content score is much weaker, because the dominant inputs to real filtering are your sending reputation and how recipients behave, neither of which a checker can see. A message scoring well from a sender with a poor reputation will still be filtered.
Use them as a lint pass rather than a prediction. A clean score means you have not made an obvious mistake; it does not mean the email will reach the inbox.
Test with realistic data
Send the test to a contact record with the fields populated the way a real subscriber's are — including the ones that are frequently empty.
The specific case worth engineering: a test contact with every optional field blank. That is the version that reveals the greeting with a missing name, the conditional block that renders nothing, and the personalisation that assumes data most of your list does not have.
Keeping two test contacts — one fully populated, one entirely blank — makes this a habit rather than an occasional thought.
Before every send
- Test sent through the platform, not previewed in the editor
- Every link clicked from the test
- Opened on a phone and in dark mode
- Viewed with images blocked
- Sent to a contact with all optional fields empty
- Unsubscribe clicked and confirmed working
- Subject and preview text checked together in the inbox list
- Segment count sanity-checked against expectation
Frequently asked questions
Is a rendering preview tool worth the subscription?
For a team building custom templates regularly, yes. For a programme using one template, checking it thoroughly when it changes and spot-checking otherwise covers most of the risk for nothing.
What single check catches the most?
Clicking every link in a real test send. Wrong and broken links are the most common send error and the most visible to a reader.
Should the whole team test, or one person?
One person with the checklist, every time. Shared responsibility for pre-send checks reliably produces sends where everyone assumed someone else had looked.