Operational email

Catches merge fields that never filled in — `{{first_name}}`, `%%reset_link%%`, `*|SUBJECT|*` — across your subject line, preview text and body. That is why it blocks. In most email an unfilled token is embarrassing. In a security alert or a policy notice it is worse than that: an email that says your account is at risk, addressed to `Hi {{first_name}}`, is indistinguishable from the phishing attempt it is warning you about. You have spent the one message where your credibility had to be perfect. We found this in real mail from the most prolific operational sender we measured. Across a whole primary inbox, 33 of the 34 emails leaking a merge tag came from a single infrastructure vendor — every one leaking `*|SUBJECT|*`, a Mailchimp tag, into the body. Their plain-text maintenance notices are clean; the mail they build in their campaign tool is not. If you send service notices from two different systems, the one you use less carefully is the one that will do this. Runs with no configuration. The default patterns cover the documented merge delimiters — `{{tokens}}`, `%%tokens%%`, `*|MAILCHIMP|*` — plus placeholder filler. If your platform uses its own delimiters, add them. One limit worth stating: it finds tokens that never filled in, not values that filled in wrongly. A maintenance window rendering as `Invalid Date` will pass this check.

A dead link in a service notice is a total failure. You have told your entire user base that something needs their attention, and the status page, the policy document or the migration guide is the only place they can go. There is no second touch. It blocks for that reason. The check catches what proofreading cannot: a personalisation token that never resolved inside an href, a scheme-less URL that Outlook.com silently strips, an empty or bare-`#` link, and destinations that are provably dead. **Run it against a test send.** This check follows your links. Links whose path names an account action — verify, confirm, activate, reset, revoke and the like — are refused before any request is made, as your unsubscribe and preference links always have been, and every skip is listed in the result with its reason. For operational mail the underlying exposure was already low: we measured tokenised account-action links in 4% of operational email, against 63% of transactional, and found no sign-in or revoke endpoints at all. But 40% of operational links route through an ESP click-redirector, and those are still followed, so a run will register clicks in your own reporting. One quirk specific to this category, worth knowing before you read a result: **a status page can legitimately be unreachable during the incident it describes.** If you validate an outage notice while the outage is happening, a failure may be telling you the truth about your infrastructure rather than about your email. Validate the template, not the live send. Failures are trustworthy by design. Bot-protection responses (401/403/429) are reported as *unverifiable* rather than failed, because Cloudflare-class protection serves those to automated checkers and never to a human with a browser; transient errors are retried once before any verdict. Links are inspected with HEAD only, so a destination that refuses HEAD is reported unverifiable rather than re-requested with GET.

Checks that the `From:` address on your service notices is a domain you actually own, using DMARC relaxed alignment — `mail.yourbrand.com` matches `yourbrand.com`, because only whoever controls your DNS can create that subdomain, while `yourbrand-mail.com` never matches. **This is the one legal duty operational email still owes.** CAN-SPAM exempts service notices from almost everything — no unsubscribe, no postal address — under 15 U.S.C. §7702(17)(A)(ii) and (iii). The single requirement that survives the exemption is §7704(a)(1): header information must not be false or misleading. Everything else on this list is craft or accessibility law. This one is the statute. It matters commercially too. A security alert or a terms change is the email people are primed to act on without thinking, and the sending domain is the only thing separating yours from a convincing fake. Every time your own notices arrive from an unexpected domain, you teach your users that unfamiliar senders are normal — exactly the habit a phishing attempt needs. **List every domain you send from, including the ones your platform sends on your behalf.** This is where it catches people out. Of 74 distinct sending domains we measured across real operational mail, 46 were subdomains of the brand — those align. But four were separate registered domains that do not: `hulumail.com` does not align with `hulu.com`, and nor do `lyftmail.com`, `krogermail.com` or `instacartemail.com`, however much they look like they should. One company in our sample sends from two different registrable domains entirely. Until you provide the list, the check is skipped rather than failed, and it is not charged. One limit: this reads the `From:` header against your list. It does not verify SPF, DKIM or DMARC, and it cannot detect someone else spoofing you — it catches your own mail leaving from a domain you did not intend.

Confirms your email carries a plain-text version alongside the HTML one, and that it is not empty. It matters more here than almost anywhere, because of who receives a service notice: everyone. Notification previews, smartwatches, plain-text-only corporate clients and screen readers all read the plain-text part, and unlike a campaign there is no self-selected audience — you are mailing every account you have. Across real operational mail we found 15 senders shipping policy notices as HTML only, with no plain-text alternative at all, including several major payment and marketplace brands. One declared `multipart/alternative` and then put nothing in it, which is the version nobody catches because the structure looks right. It is also a long-standing deliverability signal — an HTML-only message is one of the oldest and cheapest things a spam filter can hold against you. Runs with no configuration. A warning about what a pass means: we confirm a plain-text part is present and non-empty, not that it says the same thing as your HTML. A stub reading "This email requires an HTML-capable client" passes this check and helps nobody. ⚠ **If you send plain-text-only notices, this check currently reports them incorrectly and we are fixing it.** A single-part `text/plain` email — the shape several infrastructure vendors correctly use for maintenance notices — has maximal reach and no HTML at all, and today it fails a check whose whole argument is about reach. That is our defect, not yours. Treat a failure on a text-only send as noise until the fix lands.

Checks that the images in your email carry alt text a person can actually use — not missing, not `"image"`, not a filename, and not an unlabelled linked graphic announced to a screen reader as just "link". This blocks, and the reason is the audience. A service notice reaches your entire user base with no opt-out, which means it reaches every one of your users who relies on a screen reader — and every Outlook recipient who has never added you to their safe-senders list. Microsoft blocks remote images by default until you do; Thunderbird ships the same default. For those readers the alt text *is* the email, and if your remediation step is inside a graphic they are told there is a problem and not told what to do about it. It is also law. WCAG 2.1 §1.1.1 is Level A — the lowest bar there is, and levels are cumulative, so failing it fails you at every level. The European Accessibility Act has applied since 28 June 2025 through EN 301 549, and reaches services sold to EU consumers; a notice about the service you sold is part of that service, not an advertisement for it. Expect to find something the first time, but less than you fear. Operational senders are markedly better at this than marketers: 62% of images in the service notices we measured carry usable alt text, against 30% in campaign mail. About a third of image-bearing operational emails still fail, and the commonest single cause is one unlabelled linked logo in the template header — a one-line fix that repairs every send. **An email with no images passes at no cost.** Runs with no configuration and makes no model call.

Resolves every image your email references — attached, embedded, or hosted — and checks the dimensions you declared against the file's real ones. It catches images that cannot be fetched at all, declared sizes that contradict the natural aspect ratio (the squashed logo), and images upscaled far enough to render soft. **Run this against a test send.** It fetches every image, and 81% of operational email carries a 1x1 open-tracking pixel — so on a live send this will register an open you did not earn. One caveat we would rather state than have you discover: the upscale rule currently flags differences too small to see — a 28px icon declared at 32px will be reported. We are fixing the threshold. Until then, treat upscale findings as worth a look rather than as defects, and trust the unresolvable-image and distortion findings, which are exact. An email with no images passes at no cost.

Checks that every image your email points at actually resolves to real image bytes over a sound path. It catches dead references, dangling content-ids for images you meant to attach, redirect chains that run past five hops, and http-only sources whose https upgrade fails — that last one is why images pass in your test client and break for the recipient. That last defect is not hypothetical here. Across the operational mail we measured, 3.9% of image references were still plain `http://`, and they clustered in exactly the wrong place: the single security broadcast in the sample carried six of them. **Run this against a test send**, for the same reason as the image-rendering check: it fetches every image, and 81% of operational email carries an open-tracking pixel. Optionally restricts images to hosts you approve, checked at the original source and at the final redirect destination. Worth knowing before you configure it: the operational mail we measured pulled images from 56 distinct hosts across 25 organisations, so an approved-host list needs your CDN, your ESP and your status-page provider on it. Leave the list empty and there is no host restriction. It overlaps the image-rendering check on unresolvable images, so a broken URL will be reported by both. Their unique halves differ: this one owns the delivery path, that one owns dimensions. An email with no images passes at no cost.

Judged from the rendered screenshot at every viewport you selected — mobile, tablet and desktop, in both Gmail and Outlook — reporting what specifically broke rather than a bare pass or fail. Outlook is the reason this is worth paying for. It renders through the Word engine and breaks structures that are perfectly safe in a browser, and a service notice goes to your whole user base, which means a large corporate share. Across our runs every recorded layout failure was at mobile or tablet width and none at desktop — an email that looks correct on your monitor is not evidence about the screen your user is holding when the alert arrives. This is the check that makes your bill jump, and you should know why before you choose this tier. Most of the others read your email's source and cost a credit each. This one has to actually render your email in real mailboxes, at three widths, in two clients — so it carries the cost of the renders as well as the judgement. Every visual check you add after it is much cheaper, because the renders are already paid for. If you send plain-text notices it will pass them trivially, since a plain-text email has no layout to break. That is a real cost with no information in return, and it is the honest argument against running this tier on a text-only maintenance stream. It reports rather than blocks, deliberately. It can tell you something is cut off; it cannot tell you whether the cut-off thing was a copyright line or the sentence explaining what your users have to do. That call is yours.

Judged visually per client, and the question is not whether an image is cropped but whether the crop destroys its meaning — text cut off inside an image, a truncated diagram, framing broken badly enough to change what the picture communicates. Tight but deliberate crops pass. For a service notice the case is narrower than for a campaign but sharper when it applies: a maintenance timetable rendered as a graphic, a network diagram showing which regions are affected, a screenshot of the setting a user is being asked to change. When the explanation is inside the image, a bad crop removes the explanation. An email with no meaningful images passes at no cost.

Flags subject lines longer than 60 characters. For a service notice the subject is doing a specific job: it has to communicate urgency and topic in an inbox where it is competing with mail the reader actually asked for. Which is why **where the meaningful word sits matters more than the total length**. Mobile clients cut the subject at roughly 35–40 characters, and this check's limit is 60 — so it will pass subjects whose point is already invisible on a phone. Read a pass as "not obviously too long", never as "your reader can see what this is about". The specific trap in this category is the prefix. Real examples we measured: `[Action Advised] Review Google Cloud cre…` spends sixteen characters on a bracket tag before anything informative, and `Cancelled - Core Infrastructure Maintena…` spends twelve on a status word. Both lose their topic to the clip. `Core Infrastructure Maintenance — cancelled` survives it. Most operational senders already do this reasonably well — in real mail the topic word survives the mobile cut about 85% of the time. This is a cheap safety net for the rest. Runs with no configuration. Two honest limits: the 60-character threshold is a decided number rather than a derived one, and about half of what it flags is long-but-fine while it misses some subjects that are short enough to pass and still lose their meaning. Treat it as a prompt to re-read your subject, not as a verdict on it.

The line of text beside your subject in the inbox is the second thing your user reads, and for a service notice it is often what decides whether they open it now or later. This predicts what that line will actually show and checks your own boilerplate has not got in front of it. The common failure is a "View in browser" link at the top of the template becoming the first thing in the preview — we have found exactly that on a new-sign-in security alert and on an account welcome, in both cases pushing the actual message out of view. It also catches leaked merge tokens, bare URLs, and hidden-preheader padding characters that leak into your plain-text part as literal `͏` garbage. **You almost certainly do not need to add a hidden preheader block.** Every outage and maintenance notice we measured passed this check without one — the first line of a service notice is already the notice. If your preview is wrong, the fix is to move boilerplate below your opening sentence, not to bolt a preheader on top. Runs with no configuration. One thing it cannot check, and it is the thing that matters most here: whether your preview is *useful*. A real maintenance notice in our sample previews as `Start: 2026-08-03 09:00 UTC End: 2026-08-05 11:00 UTC Hello, During the…` — two timestamps before the reader learns what is happening or to what. It passes this check cleanly, because there is nothing wrong with it that a machine can see. Lead with the sentence, not the schedule.

Reports whether your email carries a physical postal address. It reports rather than blocks, because most operational mail genuinely does not need one — and yours may well be fine without it. **The exemption is real.** CAN-SPAM's postal-address duty applies to *commercial* email, and a notice about a change in the terms or features of an account, or about safety or security, is excluded (15 U.S.C. §7702(17)(A)(ii) and (iii)). In real operational mail we found 87% of outage and maintenance notices carry no address at all, and almost all of them are compliant. Infrastructure vendors in particular almost never include one. **The exemption is also per-message, and easy to lose without noticing.** Under 16 CFR §316.3 your notice becomes commercial if a recipient reading the subject line would think it contains an ad, **or** if the non-commercial content is not at the beginning of the body. We measured promotional content in 4% of operational email — including a privacy-policy notice carrying "25% off" and "free shipping". Whoever added that block changed the email's legal status, and penalties run to $53,088 per email. So the question to ask is not "am I exempt?" but "is there promotional content in here, and is the notice still at the top?" If there is, treat the message as marketing — it owes an address, an unsubscribe, and the rest of that standard. One reason to include an address even when exempt: security and policy notices are the most impersonated mail there is, and a real postal address is a trust signal a phishing copy usually will not carry. The check anchors on a postcode that agrees with its region, and recognises US, UK, Canadian, European, PO box, private mailbox and military formats. It fails an incomplete address on purpose — a city name alone is not an address.

Confirms your logo is visible and fully rendered at the top of the email, in Gmail and Outlook, on mobile and desktop. On a campaign this is a branding question. On a service notice it is closer to a security one. Security alerts, policy changes and outage notices are the mail people are primed to act on, and your user's ability to spot a fake depends on knowing what the real one looks like. An unbranded notice teaches them that unbranded notices are normal. It also catches the plain failure: a logo hosted somewhere that stopped resolving, rendering as a broken-image icon at the top of every notice you send. That is the kind of defect nobody notices internally, because your own mail client has the image cached. **If you send plain-text notices, this check will report a logo as missing — and the fix is not to rebuild your email in HTML.** The check accepts a text wordmark, not only a graphic. Putting your company name on the first line, above the timestamps, satisfies it and is good practice anyway: it tells the reader who is talking before it tells them when. Several infrastructure vendors send excellent plain-text maintenance notices that open with a bare `Start:` timestamp and never name themselves in the body at all. It reports rather than blocks. A missing logo is a real defect and not a fatal one.

Gmail stops rendering a message at roughly 102KB of HTML and hides the rest behind a "View entire message" link, and what sits below the cut is the end of the notice. On a service notice that matters more than the length suggests: the instruction, the affected account, or the link to act on is often the last thing in the message, and a reader who has to click "View entire message" to find out what to do is a reader who does not. It blocks. A maintenance notice whose instructions sit behind "View entire message" has not really been sent, and this is the category where the reader is least willing to go looking.