Previews show you the email. They never measure it.

There are two questions in email QA and they sound similar enough that most teams only ever answer one. The first is a design question: does this look like what we approved, in the clients our audience uses? The second is a measurement question: is any value in this render outside a limit we care about? Both produce something that looks like a screenshot, which is why the second one keeps getting skipped — the team already has pictures, so the job feels done.

It is not done. A picture of an email at 600 pixels tells you nothing about what happens at 390. A picture at 390 tells you the CTA wrapped, but only if someone notices. Noticing is a coin flip on a Wednesday afternoon in a thread with a subject-line debate running through it. Measurement does not depend on anyone noticing. That is the entire argument for it.

Orbit's render gate lays the email out at 640px and 390px inside a real browser engine and measures the result. The list of what comes back is short, deliberately, because each item is a defect class that static analysis of the HTML genuinely cannot see and a human reviewer genuinely does not catch reliably.

Notice what these have in common. Every one of them is a number compared to a threshold — which means every one of them survives being pasted into a thread by someone with no authority. That is the underrated political function of measurement: findings with units let the most junior person on the review block a send. Taste does not travel down a hierarchy. Ratios do.

The Email Render QA skill runs the measured layout first and the markup-level checks second — alt text, heading order, dark-mode risk — and treats them as complements rather than alternatives. They catch different things and neither is a superset of the other.

Missing a defect is one failure. Being confidently reassured about one is worse. Previews do that in three specific places.

Dark mode. A dark preview captures what one client did to your colours. It does not tell you which colour pairs in the template are at risk when a different client inverts differently, and the major clients each implemented their own logic. A pair check enumerates the foreground/background combinations that meet on the page and shows what a full inversion does to each — including the pair that currently looks fine because both sides happen to be dark already, and will collapse to invisible when only one side flips. That mechanism is what the dark mode guideexists to explain. Nothing else generates as much "but it looked fine in the preview".

Length. Every preview renders the whole email. Gmail does not, past 102 KB. So the artefact your team reviews is systematically the version a large share of your audience will never see the bottom of. The review reaches a footer the recipient does not.

Width. A preview tool picks a viewport. Your audience picks a phone. If those two numbers differ — and they usually do, because 600 or 640 is the design width and 390 is a common device width — then the reflow behaviour between them is unreviewed. That gap is where the wrapped CTA lives, along with the two-column block that stacked in an order nobody intended.

Now the honest half, because a gate oversold is a gate ignored. A browser engine is not Outlook on Windows. Outlook's desktop client renders mail through Word's layout engine. No browser reproduces its behaviour — the padding it drops, the way it treats certain background images, the widths it recomputes. If a meaningful share of your list opens in Outlook desktop, a client-matrix preview service still has a real job — the client-specific tail.

The order is what changes. Measure first: fast, deterministic, catching the defects that affect every recipient regardless of client. Preview second: it is slower and it catches the quirks that affect a subset. Most teams run only the second one, and run it by eye, which means the universal defects — the ones hitting one hundred percent of the audience — get caught by whoever happens to be paying attention, while considerable effort goes into a rendering quirk affecting eight percent.

Take the email you shipped most recently — already sent, already approved, already forgotten. Put the HTML through a measured render at 390px and read the findings.

You are looking for two specific things: a tap target under 44×44 and a computed contrast under 4.5:1. If neither is there, your review process is genuinely working and you have earned the right to keep approving by screenshot. If both are there, they were there last month as well and the month before, because nothing in a picture-based review has ever been capable of surfacing them.

Then put the gate in front of the send rather than beside it. A check that runs when someone remembers is a check that runs on the calm sends and skips the rushed ones, which inverts the entire point.