{"modules":[{"modelVersion":1,"id":"email-accessibility","slug":"meets-wcag-accessibility-criteria","name":"Accessibility criteria met (WCAG, source-decidable)","aka":["WCAG","email accessibility","AA compliance","accessible email"],"subjectType":"email","category":"accessibility-compliance","severity":"recommended","description":"Source-decidable WCAG checks over the email: language declaration, table semantics, colour contrast, link naming, tap-target size, and animation duration — enabled by conformance level (A, AA default, AAA). Checks that cannot be decided from source abstain with a typed reason rather than guessing, and the result is never a compliance verdict. See docs/EMAIL-ACCESSIBILITY.md.","executionKind":"functional","checkLabel":"Meets WCAG accessibility criteria","checkValue":"Section 508, EN 301 549 and the 2024 ADA Title II rule all point at WCAG AA, which is why it is the default level here. Anything the source cannot decide abstains and says so — a pass is evidence, never a compliance certificate.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-accessibility/custom","parameters":[{"name":"wcagLevel","severity":"required","standardDefault":"AA","formatSummary":"wcag-level"},{"name":"ambiguousLinkPhrases","severity":"recommended","standardDefault":["click here","here","read more","more","learn more","this","link","details","continue"],"formatSummary":"non-empty-string-array"},{"name":"logoPatterns","severity":"recommended","standardDefault":["logo","wordmark","brandmark"],"formatSummary":"non-empty-string-array"},{"name":"enabledPolicyChecks","severity":"recommended","standardDefault":[],"formatSummary":"non-empty-string-array"}],"standards":[{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"recommended","rationale":"The source-decidable half of email accessibility, at the WCAG level you choose (AA by default, because AA is the level the law actually references). Relevant here even in plain email: body text nobody can comfortably read, or a link distinguished only by colour, costs you replies regardless of compliance.\n\nWhen something cannot be determined from the source it abstains and records that as evidence, rather than guessing — and a pass is never a compliance verdict, because no automated tool can issue one.\n\nBe prepared for a failure. Across a 57,000-email corpus this check failed 96.6% of messages — though that corpus is marketing email, which carries far more markup for this check to judge than a plain outreach message does, so your own rate is likely lower. A failure here is common enough that it is weak evidence about your send specifically, which is why it sits in this tier rather than the standard one.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"recommended","rationale":"The source-decidable half of email accessibility, at the WCAG conformance level you choose — AA by default, because AA is the level the law actually references. The European Accessibility Act has applied since 28 June 2025 and is enforced through 2026 via EN 301 549, which adopts WCAG 2.1 AA in full.\n\nBe prepared to fail this. Nearly every marketing email does, and the reason is structural rather than careless. WCAG levels are cumulative, so a single Level A criterion fails you at every level — and email is built from the very techniques WCAG penalises. Layout tables are unavoidable because Outlook's Word engine forces them, yet each must be marked as presentational. \"Shop Now\" and \"Learn More\" are the vocabulary of high-converting calls to action, and also non-descriptive link text. Almost no email template declares a document language, partly because the major webmail clients discard the element that would carry it.\n\nSo read this as an improvement roadmap rather than a verdict on one campaign. Its findings divide into fixes you make once in your template and fixes you make per send, and the template-level ones are where nearly all of the volume is.\n\nWhere something cannot be determined from the source it abstains and records that as evidence rather than guessing. A pass is never a compliance certificate — no automated tool can issue one.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"recommended","rationale":"The source-decidable half of email accessibility, at the WCAG conformance level you choose — AA by default, because AA is the level the law actually references. The European Accessibility Act has applied since 28 June 2025 and reaches transactional email: an order confirmation is part of the service you sold, not an advertisement for it.\n\nBe prepared to fail this. Nearly every email does, and the reason is structural rather than careless. WCAG levels are cumulative, so a single Level A criterion fails you at every level — and email is built from the very techniques WCAG penalises. Layout tables are unavoidable because Outlook's Word engine forces them, yet each must be marked as presentational. Almost no template declares a document language, partly because the major webmail clients discard the element that would carry it.\n\nSo read this as an improvement roadmap for your template rather than a verdict on one send. Its findings divide into fixes you make once in the template and fixes you make per send, and nearly all the volume is in the first kind — which is good news for transactional mail, where one template serves every receipt you will ever send.\n\nIt sits in this tier rather than the standard one because it fails about 96% of real email, and a check that fails almost everything cannot tell a good send from a bad one.\n\nWhere something cannot be determined from the source it abstains and records that as evidence rather than guessing. A pass is never a compliance certificate — no automated tool can issue one. Costs a single credit and makes no model call.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"recommended","rationale":"The source-decidable half of email accessibility, at the WCAG conformance level you choose — AA by default, because AA is the level the law actually references.\n\nThis matters more for a service notice than for anything else you send, and the reason is structural rather than legal. Every other kind of email has a self-selected audience: people who bought from you, or subscribed, or can unsubscribe. **A service notice goes to everyone and nobody can leave.** If it is unreadable to someone using a screen reader, they do not get to opt out of the consequence. The European Accessibility Act has applied since 28 June 2025 through EN 301 549, and reaches notices about a service sold to EU consumers.\n\nBe prepared to fail this. Nearly every email does, and the reason is structural too. WCAG levels are cumulative, so a single Level A criterion fails you at every level — and email is built from the very techniques WCAG penalises. Layout tables are unavoidable because Outlook's Word engine forces them, yet each must be marked presentational. Almost no template declares a document language, partly because the major webmail clients discard the element that would carry it.\n\nSo read this as an improvement roadmap for your template rather than a verdict on one send. That framing suits operational mail unusually well, because one template typically serves every maintenance notice you will ever send — the fixes are made once and repay themselves indefinitely.\n\nIt sits in this tier rather than the standard one because it fails around three-quarters of real operational email even after discounting our own known false findings on plain-text sends, and a check that fails most things cannot tell a good send from a bad one.\n\nWhere something cannot be determined from the source it abstains and records that as evidence rather than guessing. A pass is never a compliance certificate — no automated tool can issue one. Costs a single credit and makes no model call.","parameters":null}],"runStats":{"runCount":12,"failureRate":1,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-accessibility","slug":"meets-wcag-accessibility-criteria","aka":["WCAG","email accessibility","AA compliance","accessible email"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"accessibility-compliance","detects":["source-decidable WCAG failures at the chosen level","missing language or structural information","contrast and link-purpose problems the source can settle"],"commonlyPairedWith":["email-image-alt-text","email-images-off-legibility","email-typography","email-preheader"],"triggersWhen":["an accessibility review is scheduled","a template is certified for reuse","a public-sector or regulated obligation applies"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this when accessibility is an obligation or a commitment rather than an aspiration. Section 508, EN 301 549 and the 2024 ADA Title II rule all point at WCAG AA, which is why AA is the default level here. It is most valuable on templates rather than individual campaigns, because template-level failures repeat across every send that inherits them — certify the template once and the campaigns come along with it.","whenNotToUse":"Do not use it as a compliance certificate. It decides success criteria from the email's own source, and anything the source cannot decide is abstained on and said so, never guessed — a pass is evidence, not a legal conclusion. Skip it on mail that is not part of any accessibility scope, and do not reach for it when your actual question is narrower: alt text has its own check, and whether the message survives images being blocked has another.","failureMeaning":"A failure names the success criterion that was not met at the level you selected. Because judgement is limited to what the source can settle, a failure is a strong statement — it is not an inference about how a screen reader might behave but something the markup itself decided. Abstentions matter as much as failures and should be read rather than skipped: they mark the criteria a human still has to check, which is precisely the list an accessibility reviewer wants.","thresholdRationale":"Four parameters carry the check. `wcagLevel` defaults to `AA`, the level every accessibility law actually references, and W3C itself advises against AAA as a general policy. `ambiguousLinkPhrases` holds the usual \"click here\" family and is consulted only at AAA, where link purpose out of context becomes a criterion. `logoPatterns` defaults to `logo`, `wordmark` and `brandmark` because logotypes are exempt from contrast by the success criterion itself. `enabledPolicyChecks` is empty by default, since findings with no success criterion behind them are policy rather than WCAG.","customWhenWarranted":"Set `wcagLevel` to `A` when you are establishing a floor on a large legacy template estate and need a triage pass before committing to AA. Set it to `AAA` for a specific high-obligation template, accepting that link-purpose and other stricter criteria come into play. Enable entries in `enabledPolicyChecks` when your organisation wants findings beyond WCAG — house rules about readability or structure — and extend `logoPatterns` if your brand assets are named in a way the defaults would not recognise as a logotype.","customWhenToStayStandard":"Stay on AA in almost every case, because it is the level the law references and therefore the level a result is worth citing at. Keep `enabledPolicyChecks` empty when the output is intended as accessibility evidence, so every finding maps to a success criterion and none of them are house preferences wearing WCAG's authority. Leave `ambiguousLinkPhrases` alone unless you are actually running at AAA, where it is the only level that consults it.","customTradeoffs":"Dropping to A produces a cleaner report that means less, and it is easy for a triage setting to become the permanent one nobody revisited. Running at AAA generates findings W3C explicitly does not recommend as a blanket policy, which can crowd out the AA failures that actually carry obligations. Enabling policy checks mixes two kinds of finding in one verdict, so a reader cannot tell a legal criterion from a house rule unless you separate them — and extending `logoPatterns` too broadly exempts real content from contrast judgement, which quietly weakens the check.","customGovernanceNotes":"The Standard configuration is a transcription of published standards and their own guidance about levels, which is what makes an AA result citable outside your organisation. Policy checks are the opposite — yours, with no external authority — so keep them clearly labelled as such wherever the output is used as evidence. Because the check abstains rather than guessing, the governance question that matters is who picks up the abstentions: a pass with unread abstentions is not an accessibility review, it is half of one.","customExamples":"A public-sector supplier keeps `wcagLevel` at `AA` and reports abstentions to its accessibility reviewer, using the check to narrow human effort rather than replace it. A team triaging two hundred legacy templates runs at `A` first to find the worst, then re-runs the survivors at `AA` before certifying them. An organisation with internal readability rules enables specific `enabledPolicyChecks` on its own template audits while keeping them off the runs whose output goes into a compliance file.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-accessibility"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-accessibility","parameters":{"wcagLevel":"AA","ambiguousLinkPhrases":["click here","here","read more","more","learn more","this","link","details","continue"],"logoPatterns":["logo","wordmark","brandmark"],"enabledPolicyChecks":[]}}]},"defaultClients":null},{"modelVersion":1,"id":"email-cta-button-visible","slug":"call-to-action-visible-and-clickable","name":"CTA button visible and unclipped","aka":["CTA button","call to action clipped","button not rendering","clickable button"],"subjectType":"email","category":"content-quality","severity":"recommended","description":"At least one call-to-action button must be visible and fully rendered at each selected viewport.","executionKind":"visual","checkLabel":"Call to action visible and clickable","checkValue":"A call to action clipped at one viewport is a campaign that spent its budget reaching people who could not click. Buttons break per client and per width — which is exactly where a proof sent to one inbox does not look.","hasCustomConfig":false,"requiresConfiguration":false,"price":{"unitCredits":6,"unit":"per_capture","captureCount":4,"captureMailboxes":2,"captureCredits":20,"configuredCredits":24},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":null,"parameters":[],"standards":[{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"A marketing email exists to be acted on, which makes this the one check that asks whether your campaign can do the job it was sent to do.\n\nIt confirms there is a call to action and that it is fully visible at every viewport and email client you selected — not clipped at the edge, not cut off, not pushed out of frame. A campaign whose CTA is unreachable on a 320px screen still delivers, still complies, and converts nobody.\n\nFooter unsubscribe and preference links are never counted as calls to action.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"A marketing email exists to be acted on, which makes this the one check that asks whether your campaign can do the job it was sent to do.\n\nIt confirms there is a call to action and that it is fully visible at every viewport and email client you selected — not clipped at the edge, not cut off, not pushed out of frame. A campaign whose CTA is unreachable on a 320px screen still delivers, still complies, and converts nobody.\n\nFooter unsubscribe and preference links are never counted as calls to action.","parameters":null}],"runStats":{"runCount":580,"failureRate":0.06379310344827586,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-cta-button-visible","slug":"call-to-action-visible-and-clickable","aka":["CTA button","call to action clipped","button not rendering","clickable button"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"content-quality","detects":["a call to action clipped at one viewport","a button rendered without its label","a CTA pushed off the visible area in one client"],"commonlyPairedWith":["email-layout-not-broken","email-hero-image-renders","email-link-integrity","email-images-off-legibility"],"triggersWhen":["a campaign with a primary conversion goal is built","a template's button style changes","a new mail client or width is added to the audit"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on any send with money attached to a click: an offer, a webinar registration, a cart recovery, a demo request. Buttons break per client and per width, which is exactly where a proof sent to one inbox does not look — so the value is in rendering the same message across the clients your list actually uses. Include it whenever a template's button style has changed, since button construction in email is fragile and a small CSS edit can collapse it in one client while looking perfect in the others.","whenNotToUse":"Skip it on sends with no meaningful call to action — a plain-text-styled outreach message, a service notice, a receipt whose only links are functional. It is also not a judgement of whether the CTA is *persuasive* or well placed above the fold; it answers whether the button rendered and is visibly clickable. If the question is whether the destination works, that belongs to the link check rather than this one.","failureMeaning":"A failure means the primary call to action was clipped, unrendered or not visibly clickable in the client and width captured. Read plainly: the campaign spent its budget reaching people who could not act on it, and the affected group is whichever slice of your audience uses that client at that width. Because the defect is client-specific, a failure alongside passes elsewhere is the normal shape of this finding and tells you where to look rather than casting doubt on the whole send.","thresholdRationale":"This check has no tunable thresholds. It is a rendered visibility judgement about the call to action in the captured message — there is no number, list or pattern to configure, and the only levers are which clients and widths the job renders. Nothing about the standard varies by brand, so the check is entirely zero-configuration.","customWhenWarranted":"Never — there are no Custom Parameters on this check, and its public custom page redirects to the Standard page. Anything you might want to vary lives in the job's client and viewport selection rather than in the check.","customWhenToStayStandard":"Always, because Standard is the only available behaviour. The decision worth making is client coverage: rendering the clients your audience really uses is what determines whether a pass means anything.","customTradeoffs":"Nothing can be traded, since nothing can be set. The genuine trade-off is between render cost and audience coverage, because each additional client and width adds a capture and this defect hides in specific ones.","customGovernanceNotes":"There is no local configuration here for anyone to own, so governance attaches to the standards that decide which clients a campaign is rendered in. That list is the thing to review, since it defines whose experience your verdict describes.","customExamples":"No override examples exist, as the check exposes no parameters. In practice teams differentiate this check by client selection — mobile widths especially, where a wide button is the most common casualty.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-cta-button-visible"]},"agentContractCustom":null,"defaultClients":{"mobile":["gmail_chrome_mobile","outlook_chrome_mobile"],"desktop":["gmail_chrome","outlook_chrome"]}},{"modelVersion":1,"id":"email-footer-complete","slug":"footer-has-everything-it-needs","name":"Footer complete with required elements","aka":["email footer","footer elements","footer block","required footer content"],"subjectType":"email","category":"brand-compliance","severity":"required","description":"The email footer must contain every element you ask this check to look for. There is no default list: a curated standard states the elements its category owes, or you state your own. Selecting the check without either skips it rather than grading your footer against an assumed category.","executionKind":"visual","checkLabel":"Footer has everything it needs","checkValue":"The footer carries what a send is legally and practically required to have. It is also the block most likely to be inherited from an old template, so when it is wrong it is wrong identically across every campaign that inherited it.","hasCustomConfig":true,"requiresConfiguration":true,"price":{"unitCredits":5,"unit":"per_capture","captureCount":4,"captureMailboxes":2,"captureCredits":20,"configuredCredits":20},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-footer-complete/custom","parameters":[{"name":"requiredFooterElements","severity":"required","standardDefault":[],"formatSummary":"footer-element-list"}],"standards":[{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"Your footer is where the legally required content lives, and this is the check that confirms a reader can actually see it. The address and unsubscribe checks read your source; this one reads the rendered email, so an address hidden in a collapsed block, or pushed off the end of a broken table, is caught here and nowhere else.\n\nIt failed 18.4% of the emails we have run it against, and every one of those failures a human reviewed was confirmed correct.\n\n**What this standard asks the check to look for: a visible postal address and an unsubscribe link.** Both are the CAN-SPAM floor for commercial bulk email, which is what this category is — they are not a general assumption about mail, and the operational and transactional standards deliberately ask for something different. You can ask for more — a logo, social links, a phone number, legal text — at which point it stops checking our standard and starts checking yours.","parameters":{"requiredFooterElements":["address","unsubscribe"]}},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"Your footer is where the legally required content lives, and this is the check that confirms a reader can actually see it. The address and unsubscribe checks read your source; this one reads the rendered email, so an address hidden in a collapsed block, or pushed off the end of a broken table, is caught here and nowhere else.\n\nIt failed 18.4% of the emails we have run it against, and every one of those failures a human reviewed was confirmed correct.\n\n**What this standard asks the check to look for: a visible postal address and an unsubscribe link.** Both are the CAN-SPAM floor for commercial bulk email, which is what this category is — they are not a general assumption about mail, and the operational and transactional standards deliberately ask for something different. You can ask for more — a logo, social links, a phone number, legal text — at which point it stops checking our standard and starts checking yours.","parameters":{"requiredFooterElements":["address","unsubscribe"]}},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"recommended","rationale":"Checks your footer as it actually renders — in Gmail and Outlook, on mobile and desktop — rather than trusting that what is in the source reaches the screen. Footers are where that gap shows up: Outlook renders through the Word engine, and a footer block that looks fine in a browser can collapse, clip, or vanish.\n\nA footer is good practice on any company email, and on transactional mail it is doing a specific job: confirming that a receipt for money the reader just spent came from who they think it did, and telling them where to go when something has gone wrong with the order.\n\n**What this standard asks the check to look for: a visible postal address, a legal or copyright block, and a route to help.** A route to help is any of \"Contact us\", a support address, a help centre or status page link — a phone number alone does not count unless it is presented as the way to get help. It deliberately does not ask for an unsubscribe link — you cannot opt out of the mail that runs your account, and this standard does not check for an opt-out anywhere else either. US law does not require the address on a genuinely transactional send; we ask for it because a receipt with no identifiable sender reads as a phishing attempt.\n\nIt reports rather than blocks. A footer that renders imperfectly is a real defect, but it does not make a receipt worth less than no receipt.","parameters":{"requiredFooterElements":["address","legal-text","support-contact"]}},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"recommended","rationale":"Checks your footer as it actually renders — in Gmail and Outlook, on mobile and desktop — rather than trusting that what is in the source reaches the screen. Footers are where that gap shows up: Outlook renders through the Word engine, and a footer block that looks fine in a browser can collapse, clip, or vanish.\n\nA footer is good practice on any company email, and on transactional mail it is doing a specific job: confirming that a receipt for money the reader just spent came from who they think it did, and telling them where to go when something has gone wrong with the order.\n\n**What this standard asks the check to look for: a visible postal address, a legal or copyright block, and a route to help.** A route to help is any of \"Contact us\", a support address, a help centre or status page link — a phone number alone does not count unless it is presented as the way to get help. It deliberately does not ask for an unsubscribe link — you cannot opt out of the mail that runs your account, and this standard does not check for an opt-out anywhere else either. US law does not require the address on a genuinely transactional send; we ask for it because a receipt with no identifiable sender reads as a phishing attempt.\n\nIt reports rather than blocks. A footer that renders imperfectly is a real defect, but it does not make a receipt worth less than no receipt.","parameters":{"requiredFooterElements":["address","legal-text","support-contact"]}},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"recommended","rationale":"Checks your footer as it actually renders — in Gmail and Outlook, on mobile and desktop — rather than trusting that what is in the source reaches the screen. Footers are where that gap shows up: Outlook renders through the Word engine, and a footer block that looks fine in a browser can collapse, clip, or vanish.\n\nFor a service notice the footer is doing a different job than on a campaign. It is where a reader confirms the notice is genuinely from you — which matters most on exactly the mail that phishing imitates: password resets, security alerts, terms changes — and where they look for a way to ask a follow-up question.\n\n**What this standard asks the check to look for: a visible postal address, a legal or copyright block, and a route to help.** A route to help is any of \"Contact us\", a support address, a help centre or status page link — a phone number alone does not count unless it is presented as the way to get help. It deliberately does not ask for an unsubscribe link. You cannot opt out of a security notice or a terms change, this standard does not check for an opt-out anywhere else either, and a footer check demanding one would have contradicted the rest of the set.\n\nIt reports rather than blocks. A footer that renders imperfectly is a real defect, but it does not make a service notice worth less than not sending.","parameters":{"requiredFooterElements":["address","legal-text","support-contact"]}},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"recommended","rationale":"Checks your footer as it actually renders — in Gmail and Outlook, on mobile and desktop — rather than trusting that what is in the source reaches the screen. Footers are where that gap shows up: Outlook renders through the Word engine, and a footer block that looks fine in a browser can collapse, clip, or vanish.\n\nFor a service notice the footer is doing a different job than on a campaign. It is where a reader confirms the notice is genuinely from you — which matters most on exactly the mail that phishing imitates: password resets, security alerts, terms changes — and where they look for a way to ask a follow-up question.\n\n**What this standard asks the check to look for: a visible postal address, a legal or copyright block, and a route to help.** A route to help is any of \"Contact us\", a support address, a help centre or status page link — a phone number alone does not count unless it is presented as the way to get help. It deliberately does not ask for an unsubscribe link. You cannot opt out of a security notice or a terms change, this standard does not check for an opt-out anywhere else either, and a footer check demanding one would have contradicted the rest of the set.\n\nIt reports rather than blocks. A footer that renders imperfectly is a real defect, but it does not make a service notice worth less than not sending.","parameters":{"requiredFooterElements":["address","legal-text","support-contact"]}}],"runStats":{"runCount":580,"failureRate":0.1879310344827586,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-footer-complete","slug":"footer-has-everything-it-needs","aka":["email footer","footer elements","footer block","required footer content"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"brand-compliance","detects":["a footer missing its postal address or opt-out","an inherited footer block that lost an element","a footer that differs between sending platforms"],"commonlyPairedWith":["email-unsubscribe-present","email-physical-address-present","email-no-placeholder-text"],"triggersWhen":["a template's footer block changes","a new sending platform is introduced","a compliance review covers a campaign family"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on commercial sends where the footer carries obligations, and run it on the delivered message rather than the template. The footer is the block most likely to be inherited from an old template, which means when it is wrong it is wrong identically across every campaign that inherited it — so one audit usually answers for a family. It complements the individual opt-out and postal-address checks by asking one question about the block as a whole, which is how a reviewer actually thinks about it.","whenNotToUse":"Skip it on operational and transactional mail whose footer legitimately carries less: nobody may opt out of a security notice, and a receipt is exempt from the postal-address duty. It is also not the place to enforce brand styling of the footer — it asks which elements are present, not whether they are laid out correctly or legible. If you want the stronger, statute-specific reading of one element, the dedicated opt-out and address checks make sharper findings than a combined verdict does.","failureMeaning":"A failure names the required footer element it could not find. The cause is nearly always structural rather than editorial — an inherited block that was edited for one campaign, a platform whose wrapper supplies a different footer, or a merge that dropped a region. Because the same block is shared, treat a failure as a question about which templates inherit it rather than about the single campaign you happened to audit.","thresholdRationale":"One parameter carries the check: `requiredFooterElements`, defaulting to `address` and `unsubscribe`. Those two are the elements a commercial send is actually obliged to carry, which is why they and nothing else are on by default — a longer default list would fail correct mail for organisations that have no such policy. The parameter is a list of named elements rather than free text, so the finding can say precisely which one was missing instead of reporting that a sentence was not satisfied.","customWhenWarranted":"Override `requiredFooterElements` when your footer standard is broader than the legal minimum. Adding elements is the right move when your organisation has decided every commercial send must route to a preference centre, carry a privacy link, or show the company registration details. It is also useful in the other direction for a specific campaign family: narrowing the list for operational mail lets you keep the check in the set without demanding an opt-out that should not be there.","customWhenToStayStandard":"Stay on the default pair when your obligation is the legal minimum, because adding elements you do not actually require turns compliance findings into style findings and dilutes both. Keep it when auditing across brands or clients that have different footer conventions, since a shared minimum is what makes those results comparable. If a single element matters intensely — the opt-out, say — the dedicated check for it is a better instrument than a longer list here.","customTradeoffs":"Each element you add is another way for a correct send to fail, and elements that are not legally required tend to be the ones a campaign editor legitimately drops. A long list also weakens the signal: when a footer must satisfy six things, the finding becomes a checklist result rather than a clear defect, and people start skimming it. Narrowing the list for a campaign family carries the opposite risk, since a narrowed configuration applied to the wrong send quietly stops checking something that was required.","customGovernanceNotes":"The Standard pair reflects statutory duty rather than preference, which is why it is short and why it is the version worth citing externally. A Custom list is your organisation's own footer policy and belongs with whoever owns it — legal, brand, or both — with a record of why each element is required. Review it when your obligations change, because a footer policy written for one jurisdiction quietly becomes wrong when you start sending into another.","customExamples":"A company that requires a preference-centre route on every marketing send sets `requiredFooterElements` to include that alongside `address` and `unsubscribe`, so a footer offering only a hard opt-out fails. A regulated business adds its company registration details to the list, making one audit serve as evidence for a compliance file. A team auditing operational notices narrows the list to `address` only, keeping the check useful on mail where an unsubscribe link would itself be the defect.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-footer-complete"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-footer-complete","parameters":{"requiredFooterElements":[]}}]},"defaultClients":{"mobile":["gmail_chrome_mobile","outlook_chrome_mobile"],"desktop":["gmail_chrome","outlook_chrome"]}},{"modelVersion":1,"id":"email-from-domain-match","slug":"sent-from-your-own-domain","name":"From-domain match","aka":["from domain","sending domain","spoofing check","sender alignment"],"subjectType":"email","category":"brand-compliance","severity":"recommended","description":"Parse From: header; extract domain. Fail if domain is not in allowedFromDomains parameter list (case-insensitive). Error if From: header is absent.","executionKind":"functional","checkLabel":"Sent from your own domain","checkValue":"Mail from an unexpected domain looks like spoofing to recipients and mailbox providers, and damages deliverability. The sending domain must be one the brand has verified.","hasCustomConfig":true,"requiresConfiguration":true,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-from-domain-match/custom","parameters":[{"name":"allowedFromDomains","severity":"required","standardDefault":[],"formatSummary":"domain-list"}],"standards":[{"setId":"cold-outreach-standard","setName":"Cold outreach — standard","category":"cold-outreach","tier":"standard","severity":"recommended","rationale":"Checks that the domain in your `From:` header is one you actually own, using DMARC relaxed alignment — `reply.yourbrand.com` matches `yourbrand.com`, because only whoever controls your DNS can create that subdomain, while `notyourbrand.com` never matches. Cold outreach has no reputation buffer, so a mismatched or spoofed sender domain is expensive.\n\nNeeds one piece of configuration: the domains you send from. Until you provide them the check is skipped rather than failed.","parameters":null},{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"recommended","rationale":"Checks that the domain in your `From:` header is one you actually own, using DMARC relaxed alignment — `reply.yourbrand.com` matches `yourbrand.com`, because only whoever controls your DNS can create that subdomain, while `notyourbrand.com` never matches. Cold outreach has no reputation buffer, so a mismatched or spoofed sender domain is expensive.\n\nNeeds one piece of configuration: the domains you send from. Until you provide them the check is skipped rather than failed.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"Confirms the domain in your From: header is one you own, using DMARC relaxed alignment — mail.yourbrand.com matches yourbrand.com, because only whoever controls your DNS can create that subdomain. That distinction matters: 52.3% of real senders mail from a subdomain of their brand domain, so exact matching would fail most legitimate campaigns.\n\nThe failure it catches is an ESP misconfiguration sending your campaign from the wrong domain. At bulk volume that breaks DMARC alignment, which Gmail, Yahoo and Microsoft all require and, since May 2026, enforce with permanent 550 rejections. It also catches a staging domain leaking into production, and the wrong brand's domain in a multi-brand account.\n\nNeeds one piece of configuration: the domains you send from. Until you provide them the check is skipped rather than failed. Note it does not verify that SPF, DKIM or DMARC actually pass — it confirms the From domain is one you claim.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"Confirms the domain in your From: header is one you own, using DMARC relaxed alignment — mail.yourbrand.com matches yourbrand.com, because only whoever controls your DNS can create that subdomain. That distinction matters: 52.3% of real senders mail from a subdomain of their brand domain, so exact matching would fail most legitimate campaigns.\n\nThe failure it catches is an ESP misconfiguration sending your campaign from the wrong domain. At bulk volume that breaks DMARC alignment, which Gmail, Yahoo and Microsoft all require and, since May 2026, enforce with permanent 550 rejections. It also catches a staging domain leaking into production, and the wrong brand's domain in a multi-brand account.\n\nNeeds one piece of configuration: the domains you send from. Until you provide them the check is skipped rather than failed. Note it does not verify that SPF, DKIM or DMARC actually pass — it confirms the From domain is one you claim.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"required","rationale":"Checks that the `From:` address on your transactional mail 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.\n\nThis matters more here than on a campaign. A password reset or an order confirmation is the email people are primed to act on without thinking, and the sending domain is the only thing distinguishing yours from a convincing fake. Every time your own mail arrives from an unexpected domain, you teach your customers that unfamiliar senders are normal — which is exactly the habit a phishing attempt needs.\n\n**List every domain you send from, including the ones your platform sends on your behalf.** This is where transactional email catches people out: dedicated transactional streams often go out from a separate registered domain rather than a subdomain — `lyftmail.com` for Lyft, `hulumail.com` for Hulu — and a separate domain does not align, however similar it looks. If your ESP sends from its own domain, list that too.\n\nUntil you provide the list, the check is skipped rather than failed, and it is not charged.\n\nOne 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.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"required","rationale":"Checks that the `From:` address on your transactional mail 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.\n\nThis matters more here than on a campaign. A password reset or an order confirmation is the email people are primed to act on without thinking, and the sending domain is the only thing distinguishing yours from a convincing fake. Every time your own mail arrives from an unexpected domain, you teach your customers that unfamiliar senders are normal — which is exactly the habit a phishing attempt needs.\n\n**List every domain you send from, including the ones your platform sends on your behalf.** This is where transactional email catches people out: dedicated transactional streams often go out from a separate registered domain rather than a subdomain — `lyftmail.com` for Lyft, `hulumail.com` for Hulu — and a separate domain does not align, however similar it looks. If your ESP sends from its own domain, list that too.\n\nUntil you provide the list, the check is skipped rather than failed, and it is not charged.\n\nOne 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.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"required","rationale":"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.\n\n**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.\n\nIt 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.\n\n**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.\n\nUntil you provide the list, the check is skipped rather than failed, and it is not charged.\n\nOne 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.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"required","rationale":"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.\n\n**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.\n\nIt 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.\n\n**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.\n\nUntil you provide the list, the check is skipped rather than failed, and it is not charged.\n\nOne 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.","parameters":null}],"runStats":null,"content":{"id":"email-from-domain-match","slug":"sent-from-your-own-domain","aka":["from domain","sending domain","spoofing check","sender alignment"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"brand-compliance","detects":["mail sent from an unapproved domain","a send that escaped through an ESP's shared domain","a subdomain nobody authorised"],"commonlyPairedWith":["email-plaintext-alt-present","email-unsubscribe-present","email-link-integrity"],"triggersWhen":["an ESP or sending platform is changed","a new campaign tool is introduced","a domain or subdomain migration happens"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on every commercial send once you have declared your sending domains, because the failure it catches is silent and expensive. It matters most when more than one system can send on your behalf — a marketing platform, a CRM, a support desk, an agency's tool — since that is how mail starts arriving from a domain nobody signed off. Keep it in the standard set for cold outreach in particular, where an unfamiliar sending domain is the difference between a reply and a spam report.","whenNotToUse":"Skip it while you genuinely do not know your own approved list, because until it is configured the check cannot run and will simply report as needing configuration. It is also not the right tool for verifying authentication: it reads which domain the mail claims to come from, not whether SPF, DKIM or DMARC pass for it. If your question is whether your alignment records are correct, that is a DNS and authentication review, and this check complements it rather than replacing it.","failureMeaning":"A failure means the mail arrived from a domain that is not on your approved list, and it names the domain it found. To a recipient that reads as a possible spoof, and to a mailbox provider it reads as a reason to treat your mail with more suspicion — the cost is paid in deliverability, quietly, over subsequent sends. The most common cause is not an attack but a tool: a platform defaulting to its own shared domain, or a subdomain introduced by a new integration.","thresholdRationale":"One parameter carries the check: `allowedFromDomains`, whose Standard default is an empty list at `required` severity. That is a deliberate gate rather than an oversight — there is no universal set of correct sending domains, because every brand's are its own, so instead of guessing the check reports as needing configuration until you state yours. The empty default is what keeps it from erroring on every unconfigured job, since an error scores as a failure at any severity.","customWhenWarranted":"Configuring `allowedFromDomains` is not really an override, it is the act that switches this check on — the value is always yours. Set it to every domain and subdomain you legitimately send from, including the ones your ESP, CRM and support tooling use, and including delegated subdomains you have given to agencies. The narrower the list you can honestly keep, the more the check is worth: a list containing every domain anyone has ever used cannot detect anything.","customWhenToStayStandard":"There is no useful Standard state to stay on here, because the unconfigured default is a skip rather than a verdict. The nearest equivalent decision is whether to run this check at all: if you cannot yet enumerate your sending domains, leave it out of the set until you can, rather than listing everything to make it pass. If you are auditing mail on someone else's behalf and do not know their sending estate, ask them for the list rather than inferring it from the sends you happen to see.","customTradeoffs":"Every domain you add is a domain the check will never question again, so a permissive list buys quiet at the cost of the whole point. Keeping it tight has the opposite cost: a legitimate new tool will fail its first send until someone updates the list, which is friction you have to be willing to own. The list also has to be maintained — a stale list fails good mail after a platform migration, and the temptation in that moment is to widen it rather than correct it.","customGovernanceNotes":"There is no community default here and there could not be one: your sending domains are facts about your organisation, not a standard anyone else can publish. The list should therefore be owned where domain and authentication records are owned, not where campaigns are built, and it should be updated as part of onboarding a new sending platform rather than after the first failed send. Record why each domain is on the list, because an entry nobody can account for is usually a tool somebody has forgotten is still sending.","customExamples":"A company sending marketing from its ESP and receipts from its application sets `allowedFromDomains` to both the marketing subdomain and the transactional one, and nothing else, so a new tool sending from a shared platform domain fails immediately. A brand that has delegated a subdomain to its agency lists that subdomain explicitly, which keeps the agency's mail passing while still failing anything sent from the agency's own domain. A group with several trading names lists each brand's sending domain rather than adding a wildcard, accepting the maintenance so that a send from a retired brand still surfaces.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-from-domain-match"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-from-domain-match","parameters":{"allowedFromDomains":[]}}]},"defaultClients":null},{"modelVersion":1,"id":"email-gmail-clip-size","slug":"not-clipped-by-gmail","name":"Email opens fully in Gmail","aka":["Gmail clipping","102KB limit","view entire message","message size"],"subjectType":"email","category":"deliverability","severity":"recommended","description":"Gmail truncates a message whose HTML source exceeds roughly 102KB and hides the rest behind \"View entire message\" — taking the footer, the unsubscribe link and the tracking pixel with it. The HTML body must stay under the configured byte limit. See docs/EMAIL-GMAIL-CLIPPING.md.","executionKind":"functional","checkLabel":"Not clipped by Gmail","checkValue":"Gmail hides everything past about 102KB of HTML behind a “View entire message” link. The footer, the unsubscribe link and the tracking pixel are what fall below the cut, so the send looks fine and quietly stops being measured.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-gmail-clip-size/custom","parameters":[{"name":"maxHtmlBytes","severity":"recommended","standardDefault":102400,"formatSummary":"positive-integer"}],"standards":[{"setId":"cold-outreach-standard","setName":"Cold outreach — standard","category":"cold-outreach","tier":"standard","severity":"required","rationale":"Gmail stops rendering a message at roughly 102KB of HTML and hides the rest behind a \"View entire message\" link, taking the end of the email with it — including your opt-out.\n\nA cold email should never come close to this. If one does, something is wrong with how it was built rather than with what it says: a pasted image encoded into the HTML, or a template that was meant to be light and is not. That is worth catching before it sends, because a cold email that arrives with a \"[Message clipped]\" banner reads as a mass blast in the first second, which is the one impression this category cannot afford.\n\nIt blocks for the same reason it will almost never fire.","parameters":null},{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"required","rationale":"Gmail stops rendering a message at roughly 102KB of HTML and hides the rest behind a \"View entire message\" link, taking the end of the email with it — including your opt-out.\n\nA cold email should never come close to this. If one does, something is wrong with how it was built rather than with what it says: a pasted image encoded into the HTML, or a template that was meant to be light and is not. That is worth catching before it sends, because a cold email that arrives with a \"[Message clipped]\" banner reads as a mass blast in the first second, which is the one impression this category cannot afford.\n\nIt blocks for the same reason it will almost never fire.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"Gmail stops rendering a message at roughly 102KB of HTML and hides the rest behind a \"View entire message\" link. What falls below that cut is the end of your email — the footer, the unsubscribe link, the tracking pixel. The campaign looks fine in your own inbox, and quietly stops being measured.\n\n10.7% of the 57,396 real marketing emails we measured are over the limit today. The number that matters more is which part goes missing: your opt-out link is at the bottom, and an unsubscribe mechanism a recipient cannot see is not the clear and conspicuous one CAN-SPAM asks for.\n\nIt blocks because the fix is almost always deleting something — a base64 image pasted into the HTML, a duplicated template, an analytics block copied twice — and because the alternative is sending mail whose legally required part is invisible to the largest mailbox provider there is.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"Gmail stops rendering a message at roughly 102KB of HTML and hides the rest behind a \"View entire message\" link. What falls below that cut is the end of your email — the footer, the unsubscribe link, the tracking pixel. The campaign looks fine in your own inbox, and quietly stops being measured.\n\n10.7% of the 57,396 real marketing emails we measured are over the limit today. The number that matters more is which part goes missing: your opt-out link is at the bottom, and an unsubscribe mechanism a recipient cannot see is not the clear and conspicuous one CAN-SPAM asks for.\n\nIt blocks because the fix is almost always deleting something — a base64 image pasted into the HTML, a duplicated template, an analytics block copied twice — and because the alternative is sending mail whose legally required part is invisible to the largest mailbox provider there is.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"required","rationale":"Gmail stops rendering a message at roughly 102KB of HTML and hides the rest behind a \"View entire message\" link. On a receipt or an order confirmation, the part below that cut is usually the part the reader came back for — the totals, the support route, the tracking link.\n\n2.6% of a real inbox is over the limit. Transactional mail is rarely the culprit, because it is generated rather than designed; when it happens it is almost always an item table that grew with the order, so the biggest orders are the ones that clip.\n\nIt blocks. A receipt the reader has to expand to finish reading is a receipt that did not do its job, and the fix is never a redesign — it is finding the one thing that made the document too big.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"required","rationale":"Gmail stops rendering a message at roughly 102KB of HTML and hides the rest behind a \"View entire message\" link. On a receipt or an order confirmation, the part below that cut is usually the part the reader came back for — the totals, the support route, the tracking link.\n\n2.6% of a real inbox is over the limit. Transactional mail is rarely the culprit, because it is generated rather than designed; when it happens it is almost always an item table that grew with the order, so the biggest orders are the ones that clip.\n\nIt blocks. A receipt the reader has to expand to finish reading is a receipt that did not do its job, and the fix is never a redesign — it is finding the one thing that made the document too big.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"required","rationale":"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.\n\nOn 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.\n\nIt 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.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"required","rationale":"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.\n\nOn 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.\n\nIt 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.","parameters":null}],"runStats":{"runCount":2,"failureRate":0,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-gmail-clip-size","slug":"not-clipped-by-gmail","aka":["Gmail clipping","102KB limit","view entire message","message size"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"deliverability","detects":["HTML large enough for Gmail to clip the message","a footer and unsubscribe link pushed below the cut","a tracking pixel that stops firing"],"commonlyPairedWith":["email-plaintext-alt-present","email-unsubscribe-present","email-tracking-integrity"],"triggersWhen":["a long or image-heavy campaign is built","a template accumulates inline styles","open rates drop without an obvious cause"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on long campaigns, digest newsletters, and any template that has been edited by many hands over time — those are the sends that drift over the limit. It is worth including whenever open tracking matters to you, because clipping cuts the bottom of the message where the tracking pixel usually sits, so the send looks fine and quietly stops being measured. It reads the HTML source and needs no render, so it costs almost nothing to leave in a set.","whenNotToUse":"Skip it for short transactional mail, which is nowhere near the boundary and will pass forever without teaching you anything. It is also not a general size or performance check: it answers one vendor-specific question about where Gmail draws its cut, so if your concern is total message weight including images, this is not measuring that. Senders whose audience is overwhelmingly not on Gmail get proportionally less from it, though the limit is close enough to other providers' practical limits to remain a reasonable proxy.","failureMeaning":"A failure means the HTML is large enough that Gmail will hide everything past its cutoff behind a \"View entire message\" link. What falls below the cut is the worst possible selection: the footer, the unsubscribe link and the tracking pixel. So a clipped send is simultaneously a compliance risk, because the opt-out is one extra click away and many recipients will not take it, and a measurement failure, because opens stop being recorded while the campaign appears to be performing normally.","thresholdRationale":"One parameter carries the check: `maxHtmlBytes`, defaulting to `102400`. That number is the published target for HTML source size rather than a constant anyone has measured Gmail applying exactly — the real cutoff drifts with transfer encoding, so treating it as a hard line would be false precision. Using the published target as the threshold keeps the check honest: clearing it means you are comfortably inside the behaviour, not that you have found the exact byte where clipping begins.","customWhenWarranted":"Override `maxHtmlBytes` when you want margin. Lowering it to something like 90,000 gives you a warning band before the real cutoff, which is sensible if your templates grow steadily and you would rather hear about it early than discover a clipped campaign. Raising it makes sense only in narrow cases — an audit of internal mail where clipping is understood and accepted, or a template you know is delivered to clients that do not clip.","customWhenToStayStandard":"Stay on the published target when the result is going to be cited to anyone outside the team, since its value is that it is not your number. Keep the default for ordinary campaign checking, where the extra margin buys little and the default already leaves room. If your sends are consistently far below the limit, tightening the threshold produces findings about a problem you do not have.","customTradeoffs":"Lowering the value trades quiet for early warning, and you will get failures on sends that Gmail would have delivered intact — acceptable if the team treats them as budget breaches, corrosive if they are dismissed. Raising it is the more dangerous direction, because the cutoff is not exactly where the published target sits and encoding can push a passing message over in transit. Any change also breaks comparability with previous runs, so a template that appears to have improved may only have been re-measured.","customGovernanceNotes":"The Standard value transcribes a vendor's published guidance, so it belongs to the vendor rather than to us or to you, and it is the version worth quoting in a report. A Custom value is an internal weight budget for your templates and should be owned wherever template standards live, with the margin's reasoning recorded. Note the value in any deliverability documentation you keep, because a threshold nobody can source is the first one raised when a big campaign fails it.","customExamples":"A newsletter team whose digest grows through the year sets `maxHtmlBytes` to `90000`, creating a warning band so the template gets a weight pass before a real send is clipped. A brand auditing an image-heavy campaign keeps the default, because the published target is what it will cite to the agency that built it. An internal communications team auditing all-staff mail delivered to a client known not to clip raises the value, accepting that the result no longer speaks to Gmail behaviour at all.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-gmail-clip-size"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-gmail-clip-size","parameters":{"maxHtmlBytes":102400}}]},"defaultClients":null},{"modelVersion":1,"id":"email-hero-image-renders","slug":"hero-image-loads","name":"Hero / banner image renders","aka":["hero image","banner image","broken image in email","top image not loading"],"subjectType":"email","category":"content-quality","severity":"recommended","description":"The primary hero or banner image in the email body must load and render fully.","executionKind":"visual","checkLabel":"Hero image loads","checkValue":"The hero is the first thing a reader sees and often the only thing above the fold. A reference that fails to resolve turns the top of your email into an empty box.","hasCustomConfig":false,"requiresConfiguration":false,"price":{"unitCredits":4,"unit":"per_capture","captureCount":4,"captureMailboxes":2,"captureCredits":20,"configuredCredits":16},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":null,"parameters":[],"standards":[],"runStats":{"runCount":572,"failureRate":0,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-hero-image-renders","slug":"hero-image-loads","aka":["hero image","banner image","broken image in email","top image not loading"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"content-quality","detects":["a hero image reference that fails to resolve","an empty box at the top of the message","an asset that renders in one client and not another"],"commonlyPairedWith":["email-image-source-integrity","email-logo-visible","email-image-rendering","email-image-alt-text"],"triggersWhen":["a campaign's main image is added or replaced","assets are moved to a new host or CDN","a template is reused for a new campaign"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on any campaign whose top image is doing the work — a product launch, a seasonal promotion, an event invitation. The hero is the first thing a reader sees and often the only thing above the fold, so a reference that fails turns the opening of your email into an empty box. It is worth running per client and width, since an asset can resolve in one environment and fail in another for reasons that have nothing to do with the file.","whenNotToUse":"Skip it on sends that have no hero by design: plain-styled outreach, transactional receipts, service notices. It is also not the check for whether the image is the *right* one, whether it is sized well, or whether the message survives with images blocked — those are the change-detection, image-rendering and images-off checks respectively. If your concern is specifically that assets are hosted somewhere insecure or unresolvable, the image-source check answers that at source level more cheaply.","failureMeaning":"A failure means the hero did not render in the captured client and width. The cause is usually the reference rather than the design: an asset that was never uploaded to the sending environment, a path that worked in staging, a host that will not serve over https, or a content-id left dangling by an export. Occasionally it is client-specific behaviour, in which case the same run passing elsewhere is the clue.","thresholdRationale":"This check has no tunable thresholds. It is a rendered presence judgement — the hero either resolved and appeared in the captured message or it did not — with no numbers, patterns or lists to configure. The only variables are which clients and widths you render, and those are job settings rather than parameters of the check.","customWhenWarranted":"Never, because there are no Custom Parameters on this check; its public custom page redirects to the Standard page. If you want to restrict which hosts your images may come from, that is configurable on the image-source integrity check.","customWhenToStayStandard":"Always — Standard is the only behaviour available here. The meaningful choice is client and viewport coverage, which decides how much of your audience the verdict speaks for.","customTradeoffs":"Nothing is configurable, so nothing is traded. The practical cost is render budget: broader client coverage catches environment-specific failures but adds a capture each time.","customGovernanceNotes":"With no local values to set, there is no configuration for a governance process to own. What is worth governing is where campaign assets are hosted, since that decision is the actual determinant of whether this check passes.","customExamples":"There are no override examples, as no parameters exist. In practice the useful variation is pairing: teams run this alongside the image-source check so a failure is immediately explained rather than merely reported.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-hero-image-renders"]},"agentContractCustom":null,"defaultClients":{"mobile":["gmail_chrome_mobile","outlook_chrome_mobile"],"desktop":["gmail_chrome","outlook_chrome"]}},{"modelVersion":1,"id":"email-image-alt-text","slug":"images-have-usable-alt-text","name":"Images have usable ALT text","aka":["alt text","image descriptions","missing alt attribute","placeholder alt"],"subjectType":"email","category":"accessibility-compliance","severity":"recommended","description":"Every image must carry an alt attribute: informative images with real alternative text (not filenames, URLs, or placeholders), decorative images marked alt=\"\", and image-only links must keep an accessible name. Spacers and tracking pixels are ignored.","executionKind":"functional","checkLabel":"Images have usable alt text","checkValue":"For a large share of your recipients the alt text is the email: your first send to any Outlook address renders with images off until they add you to their Safe Senders list. A hero and a CTA with empty alt render as blank rectangles to exactly the prospects you are trying to win.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-image-alt-text/custom","parameters":[{"name":"placeholderAltTexts","severity":"required","standardDefault":["image","img","photo","picture","graphic","icon","spacer","banner","untitled","alt text","placeholder"],"formatSummary":"non-empty-string-array"}],"standards":[{"setId":"cold-outreach-standard","setName":"Cold outreach — standard","category":"cold-outreach","tier":"standard","severity":"recommended","rationale":"Cold outreach should carry at most one image — the working guidance is roughly 95% text — and Gmail already treats images as a security risk. If you do include one, alt text is what the recipient sees when images are blocked, which is the default in many corporate mail clients. Missing alt text is a documented deliverability negative, not only an accessibility gap. Placeholder values like \"image\" or \"banner\" are rejected as no better than nothing. An email with no images passes at no cost.","parameters":null},{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"recommended","rationale":"Cold outreach should carry at most one image — the working guidance is roughly 95% text — and Gmail already treats images as a security risk. If you do include one, alt text is what the recipient sees when images are blocked, which is the default in many corporate mail clients. Missing alt text is a documented deliverability negative, not only an accessibility gap. Placeholder values like \"image\" or \"banner\" are rejected as no better than nothing. An email with no images passes at no cost.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"Marketing email bakes the offer into the image — the headline, the price, the discount code. Outlook blocks images by default until you are on the reader's Safe Senders list, so without alt text your campaign renders as blank boxes and communicates nothing at all. Not degraded: nothing.\n\nIt is also now a legal requirement. The European Accessibility Act has applied since 28 June 2025 and is being enforced through 2026, bringing WCAG 2.1 AA to marketing email for any company serving EU customers, and alt text is its most-named requirement.\n\nExpect this to fail. 61.9% of real marketing email has missing or unusable alt text, and where humans reviewed our verdicts they agreed 90% of the time — the industry genuinely has not caught up yet. Spacers and open-tracking pixels are excluded, since a 1×1 shim carries no message a reader can lose, and placeholder values like \"image\" or \"banner\" are rejected as no better than nothing at all.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"Marketing email bakes the offer into the image — the headline, the price, the discount code. Outlook blocks images by default until you are on the reader's Safe Senders list, so without alt text your campaign renders as blank boxes and communicates nothing at all. Not degraded: nothing.\n\nIt is also now a legal requirement. The European Accessibility Act has applied since 28 June 2025 and is being enforced through 2026, bringing WCAG 2.1 AA to marketing email for any company serving EU customers, and alt text is its most-named requirement.\n\nExpect this to fail. 61.9% of real marketing email has missing or unusable alt text, and where humans reviewed our verdicts they agreed 90% of the time — the industry genuinely has not caught up yet. Spacers and open-tracking pixels are excluded, since a 1×1 shim carries no message a reader can lose, and placeholder values like \"image\" or \"banner\" are rejected as no better than nothing at all.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"required","rationale":"Checks that the images in your email carry alt text a person can actually use — not missing, not `\"image\"`, not an unlabelled linked graphic.\n\nThis blocks, and the reason is the law rather than good practice. The European Accessibility Act has applied since 28 June 2025, enforced through EN 301 549, which adopts WCAG 2.1 AA. It covers services sold to EU consumers, and transactional email is in scope — an order confirmation is part of the service you sold, not an advertisement for it.\n\nThere is a practical reason too. Corporate Outlook blocks images by default, so alt text is what a large share of your recipients actually see. Most transactional email survives that because the order number is in the text — about 88% of the mail we checked — but roughly one sender in five puts details only in an image, and for their customers a blocked image is a receipt with the important part missing.\n\nExpect to fail this the first time. Across real transactional email, only about a third of images carry usable alt text at all. Most of the fix is one pass over your template, not per-send work — the same logo, the same icons, the same header image, every time.\n\nAn email with no images passes at no cost. Runs with no configuration and makes no model call.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"required","rationale":"Checks that the images in your email carry alt text a person can actually use — not missing, not `\"image\"`, not an unlabelled linked graphic.\n\nThis blocks, and the reason is the law rather than good practice. The European Accessibility Act has applied since 28 June 2025, enforced through EN 301 549, which adopts WCAG 2.1 AA. It covers services sold to EU consumers, and transactional email is in scope — an order confirmation is part of the service you sold, not an advertisement for it.\n\nThere is a practical reason too. Corporate Outlook blocks images by default, so alt text is what a large share of your recipients actually see. Most transactional email survives that because the order number is in the text — about 88% of the mail we checked — but roughly one sender in five puts details only in an image, and for their customers a blocked image is a receipt with the important part missing.\n\nExpect to fail this the first time. Across real transactional email, only about a third of images carry usable alt text at all. Most of the fix is one pass over your template, not per-send work — the same logo, the same icons, the same header image, every time.\n\nAn email with no images passes at no cost. Runs with no configuration and makes no model call.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"required","rationale":"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\".\n\nThis 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.\n\nIt 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.\n\nExpect 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.\n\n**An email with no images passes at no cost.** Runs with no configuration and makes no model call.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"required","rationale":"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\".\n\nThis 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.\n\nIt 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.\n\nExpect 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.\n\n**An email with no images passes at no cost.** Runs with no configuration and makes no model call.","parameters":null}],"runStats":{"runCount":14,"failureRate":0.7142857142857143,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-image-alt-text","slug":"images-have-usable-alt-text","aka":["alt text","image descriptions","missing alt attribute","placeholder alt"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"accessibility-compliance","detects":["images with empty or missing alt text","placeholder alt values such as 'image' or 'banner'","a hero or CTA that renders as a blank rectangle with images off"],"commonlyPairedWith":["email-images-off-legibility","email-accessibility","email-hero-image-renders","email-cta-button-visible"],"triggersWhen":["an image-heavy campaign is built","an accessibility review is scheduled","a template is certified for reuse"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on every image-bearing send, because for a large share of your recipients the alt text *is* the email — your first message to any Outlook address renders with images off until they add you to their Safe Senders list. That means a hero and a call to action with empty alt attributes render as blank rectangles to exactly the prospects you are trying to win. It is a source-level check, so it covers every image in the message rather than the ones that happen to be visible in a proof.","whenNotToUse":"Skip it on mail with no meaningful imagery. Note also that decorative images legitimately carry empty alt text — a spacer or a background flourish should be silent to a screen reader — so if your template is mostly decorative the findings will need triage rather than blanket fixing. It is not the check for whether the message as a whole still makes sense with images blocked; that is the images-off legibility check, and it asks a harder question this one cannot.","failureMeaning":"A failure means at least one image has no alt text, or has alt text that says nothing useful — one of the placeholder values that means someone filled the field to satisfy a tool. The consequence is concentrated rather than spread: screen reader users lose that content entirely, and every recipient with images blocked sees a blank space where your offer was. On a hero or a button the failure is total, which is why those are worth checking even when the rest of the template is decorative.","thresholdRationale":"Two parameters carry the check. `placeholderAltTexts` lists the values that count as filled-but-useless — `image`, `img`, `photo`, `picture`, `graphic`, `icon`, `spacer`, `banner`, `untitled`, `alt text`, `placeholder` — chosen because they appear in real templates and never actually describe anything. `visualAltTextReview` defaults to `false`: it is a deliberate opt-in because it costs a model call, and what it buys is accessibility and images-off legibility rather than deliverability.","customWhenWarranted":"Turn on `visualAltTextReview` when the answer needs judgement rather than pattern matching: when accessibility legislation applies to you, when a campaign is image-heavy enough that alt text carries the message, or when you are certifying a template for long-term reuse. Extend `placeholderAltTexts` when your own tooling stamps a house default — a CMS writing the filename, a design tool writing `Asset 1` — since those pass a presence check while telling a reader nothing.","customWhenToStayStandard":"Leave `visualAltTextReview` off for routine high-volume checking, where the source-level result is enough and the extra model call is not worth it on every send. Keep the default placeholder list if your templates are hand-authored and you have no house default value to add. If your images are largely decorative, adding more placeholder values will mostly generate findings on images that are correctly silent.","customTradeoffs":"Enabling the visual review adds cost per send, and because it involves judgement its findings are less mechanical than the pattern list's — they are worth more and are argued with more. Extending the placeholder list has the usual risk of over-reach: a short word added to the list will match alt text that legitimately uses it, and `banner` is already borderline for templates where a banner is what the image genuinely is. Supplying your own list replaces the default rather than extending it, so carry the original values forward unless you mean to drop them.","customGovernanceNotes":"The Standard placeholder list is drawn from values that appear in real templates and describe nothing, which is what keeps it defensible without configuration. Additions are specific to your tooling and belong with whoever owns the templates, retired when the tool that produced them is. Where the check is being run as accessibility evidence, record whether the visual review was enabled — the two settings answer different questions, and a source-only pass should not be presented as a judgement about the rendered experience.","customExamples":"A public-sector supplier under accessibility obligations sets `visualAltTextReview` to `true` on template certification runs, accepting the extra cost where the output is evidence. A team whose CMS stamps the filename into the alt attribute adds patterns for that convention to `placeholderAltTexts`, catching images that pass a presence check while saying `hero-final-v3`. A retailer running daily promotional sends keeps both defaults for routine checking and enables the visual review only on the seasonal campaigns where images carry the whole offer.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-image-alt-text"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-image-alt-text","parameters":{"placeholderAltTexts":["image","img","photo","picture","graphic","icon","spacer","banner","untitled","alt text","placeholder"]}}]},"defaultClients":null},{"modelVersion":1,"id":"email-image-clipping","slug":"images-not-cropped-or-clipped","name":"Images unclipped and displayed properly","aka":["cropped image","image cut off","clipped graphic","image overflow"],"subjectType":"email","category":"content-quality","severity":"recommended","description":"No image in the rendered email may be clipped, cropped, or scaled in a way that damages its message — cut-off text inside images, truncated faces or products, or visibly broken framing.","executionKind":"visual","checkLabel":"Images not cropped or clipped","checkValue":"An image cropped by the client cuts the text inside it, the product, or the face — and the reader sees a mistake instead of the offer. It happens per client and per width, so it survives a proof sent to one inbox.","hasCustomConfig":false,"requiresConfiguration":false,"price":{"unitCredits":7,"unit":"per_capture","captureCount":4,"captureMailboxes":2,"captureCredits":20,"configuredCredits":28},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":null,"parameters":[],"standards":[{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"recommended","rationale":"Judged visually per viewport and 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 face or product, framing broken badly enough to change what the image communicates. Cosmetic cropping passes.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"recommended","rationale":"For senders using imagery, judged visually per viewport and client. The question is not whether an image is cropped but whether the crop destroys its meaning: text cut off inside an image, a truncated face or product, framing broken badly enough to change what the image communicates. Deliberate art direction — full-bleed crops, edge bleeds, tight but clear framing — passes.\n\nThis matters more in marketing than in any other kind of email, because marketing images carry the words. A hero whose \"40% OFF\" is cut off at 320px renders with perfectly intact layout and sells nothing.\n\nUnlike the source-level image checks, this one costs a model call whether or not your email turns out to contain images.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"recommended","rationale":"For senders using imagery, judged visually per viewport and client. The question is not whether an image is cropped but whether the crop destroys its meaning: text cut off inside an image, a truncated face or product, framing broken badly enough to change what the image communicates. Deliberate art direction — full-bleed crops, edge bleeds, tight but clear framing — passes.\n\nThis matters more in marketing than in any other kind of email, because marketing images carry the words. A hero whose \"40% OFF\" is cut off at 320px renders with perfectly intact layout and sells nothing.\n\nUnlike the source-level image checks, this one costs a model call whether or not your email turns out to contain images.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"recommended","rationale":"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 product shot, framing broken badly enough to change what the picture communicates. Tight but deliberate crops pass.\n\nA clipped image in a receipt is not cosmetic when the image is the product your customer just bought, or a QR code they need at a counter, or a map of where their parcel is. Those are the cases worth paying a render to catch.\n\nAn email with no meaningful images passes at no cost.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"recommended","rationale":"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 product shot, framing broken badly enough to change what the picture communicates. Tight but deliberate crops pass.\n\nA clipped image in a receipt is not cosmetic when the image is the product your customer just bought, or a QR code they need at a counter, or a map of where their parcel is. Those are the cases worth paying a render to catch.\n\nAn email with no meaningful images passes at no cost.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"recommended","rationale":"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.\n\nFor 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.\n\nAn email with no meaningful images passes at no cost.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"recommended","rationale":"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.\n\nFor 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.\n\nAn email with no meaningful images passes at no cost.","parameters":null}],"runStats":{"runCount":56,"failureRate":0.017857142857142856,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-image-clipping","slug":"images-not-cropped-or-clipped","aka":["cropped image","image cut off","clipped graphic","image overflow"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"content-quality","detects":["an image cropped by the client","text inside an image cut off","a product or face partly outside the visible area"],"commonlyPairedWith":["email-layout-not-broken","email-image-rendering","email-cta-button-visible","email-hero-image-renders"],"triggersWhen":["an image-heavy campaign is built","a template is rendered at a new width","images carry text or key detail"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on image-heavy sends, and especially where images carry text, prices or a product's key detail — those are the cases where a crop changes the meaning rather than just the composition. It happens per client and per width, so it survives a proof sent to one inbox, which is the whole reason to render it across a client set. Add it whenever a template is being used at a new width or on a mobile-first list.","whenNotToUse":"Skip it on plain or text-led mail where images are decorative or absent, since a cropped spacer is not a finding worth anyone's time. It is also not the check for images that fail to load, which is the hero-render and image-source territory, nor for images declared at the wrong size, which is the rendering check. If your images are deliberately designed to be cropped at the edges — a full-bleed background pattern — the finding will be technically correct and practically unwanted.","failureMeaning":"A failure means an image was cut by the client in the captured width, and the cost depends entirely on what was cut. A crop through a price, a headline set inside the image, or a face is read by the recipient as a mistake instead of an offer; a crop through empty background is cosmetic. Because it is client and width specific, the finding tells you which slice of your audience saw the damaged version — usually the mobile one.","thresholdRationale":"This check has no tunable thresholds. It is a rendered judgement about whether an image was cut in the captured client and width, with no percentage tolerance or configurable list to set. The levers available are which clients and widths you render, which belong to the job rather than to the check.","customWhenWarranted":"Never, since the check exposes no Custom Parameters; its public custom page redirects to the Standard page. If you want to control declared-versus-natural image sizing, that is configurable on the image-rendering check instead.","customWhenToStayStandard":"Always — Standard is the only behaviour on offer. The choice that matters is the width and client coverage, because clipping is almost entirely a function of those.","customTradeoffs":"Nothing can be overridden, so nothing is traded. The real cost is render budget against coverage: narrow widths are where clipping lives, and skipping them saves credits at the price of missing the defect.","customGovernanceNotes":"With no configurable values, governance sits with the client and viewport matrix your standards render, not with the check. Keeping that matrix honest about your audience's real devices is what makes a pass meaningful.","customExamples":"There are no override examples, because no parameters exist. In practice teams vary this check only by rendering the narrowest widths their audience uses, since that is where crops appear first.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-image-clipping"]},"agentContractCustom":null,"defaultClients":{"mobile":["gmail_chrome_mobile","outlook_chrome_mobile"],"desktop":["gmail_chrome","outlook_chrome"]}},{"modelVersion":1,"id":"email-image-rendering","slug":"images-render-at-the-right-size","name":"Images render and scale correctly","aka":["image scaling","upscaled image","blurry image","squashed image","image dimensions"],"subjectType":"email","category":"content-quality","severity":"recommended","description":"Every image in the email must load, and must be displayed at a size its file can actually fill. Stretching an image beyond its own pixels forces the mail client to invent the ones it does not have, which is what makes an image look soft or blocky — so an image displayed more than a quarter larger than its file is reported, as is one squashed or stretched out of its true shape. Good practice is to export at twice the display size and set the width attribute to half, so images stay sharp on the high-resolution screens most email is read on.","executionKind":"functional","checkLabel":"Images render at the right size","checkValue":"Declared dimensions that squash or upscale an image make a careful send look careless, and a source that resolves to something other than image bytes renders as nothing at all.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-image-rendering/custom","parameters":[{"name":"maxUpscalePercent","severity":"required","standardDefault":125,"formatSummary":"positive-integer"}],"standards":[{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"recommended","rationale":"Resolves every image the email references — attached, embedded, or remote — and checks the dimensions you declared against the file's real ones. Fails when an image cannot be fetched at all, when declared width and height contradict its natural aspect ratio (the squashed or stretched logo), or when it is upscaled past 110% and will render soft and blurry.\n\nDeterministic checks only, from the source. An email with no images passes at no cost.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"Resolves every image your email references — attached, embedded or remote — and checks the dimensions you declared against the file's real ones.\n\nIt fails when an image cannot be fetched at all, when declared width and height contradict its natural aspect ratio (the squashed or stretched logo), or when an image is scaled up far enough that it will render soft and blurry.\n\nDeterministic, read from the source, with no model involved. Retina exports and ratio-preserving downscales are never flagged. An email with no images passes at no cost.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"Resolves every image your email references — attached, embedded or remote — and checks the dimensions you declared against the file's real ones.\n\nIt fails when an image cannot be fetched at all, when declared width and height contradict its natural aspect ratio (the squashed or stretched logo), or when an image is scaled up far enough that it will render soft and blurry.\n\nDeterministic, read from the source, with no model involved. Retina exports and ratio-preserving downscales are never flagged. An email with no images passes at no cost.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"required","rationale":"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.\n\n**Run this against a test send only.** It fetches every image, and 96% of transactional email carries a 1x1 open-tracking pixel — so on a live send this will register an open you did not earn, on an audience small enough for that to visibly distort your own numbers.\n\nOne 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.\n\nAn email with no images passes at no cost.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"required","rationale":"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.\n\n**Run this against a test send only.** It fetches every image, and 96% of transactional email carries a 1x1 open-tracking pixel — so on a live send this will register an open you did not earn, on an audience small enough for that to visibly distort your own numbers.\n\nOne 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.\n\nAn email with no images passes at no cost.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"required","rationale":"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.\n\n**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.\n\nOne 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.\n\nAn email with no images passes at no cost.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"required","rationale":"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.\n\n**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.\n\nOne 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.\n\nAn email with no images passes at no cost.","parameters":null}],"runStats":{"runCount":14,"failureRate":0.5,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-image-rendering","slug":"images-render-at-the-right-size","aka":["image scaling","upscaled image","blurry image","squashed image","image dimensions"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"content-quality","detects":["an image upscaled past its natural size","declared dimensions that squash or stretch an asset","a source that resolves to something other than image bytes"],"commonlyPairedWith":["email-hero-image-renders","email-image-source-integrity","email-image-clipping","email-logo-visible"],"triggersWhen":["images are added or replaced in a template","a template is resized for a new layout","assets are exported from a design tool"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on image-led campaigns, and on any template where the images were resized in the HTML rather than re-exported at the right dimensions. Declared dimensions that upscale or squash an asset make a careful send look careless, and the effect is worst on high-density screens, where a modestly upscaled image reads as visibly soft. It also catches a harder failure in the same pass: a source that resolves to something which is not image bytes at all, which renders as nothing.","whenNotToUse":"Skip it on sends with no meaningful imagery, and on templates where every image is a spacer or a tracking pixel — the findings there are technically true and practically irrelevant. It is also not a judgement about file weight or load time, nor about whether the image is cropped by the client, which is the clipping check's question. If you only want to know whether assets resolve and come from approved hosts, the image-source check answers that at lower cost.","failureMeaning":"A failure means an image's declared rendering size disagrees with its natural size beyond the allowed margin, or that the source did not resolve to image bytes. Upscaling is the common case and reads to a recipient as blur; squashing reads as distortion, and on a logo or a product shot it looks like a mistake rather than a compression artefact. The finding names the image, so it is directly actionable rather than a general complaint about the template.","thresholdRationale":"One parameter carries the check: `maxUpscalePercent`, defaulting to `125` — a quarter over the asset's own size. The value is scale-invariant on purpose, because blur is a ratio rather than a pixel count, so one number judges a 16px icon and a 600px hero the same way. A quarter is chosen as the point where upscaling becomes visible on ordinary screens rather than only on high-density ones, which keeps the finding meaningful without failing every asset that is slightly off.","customWhenWarranted":"Override `maxUpscalePercent` when your quality bar is genuinely different. Tighten it toward 100 when your brand is design-led and every asset is expected to be exported at its display size, which turns the check into an asset-pipeline gate. Loosen it when you knowingly reuse a library of fixed-size assets across layouts of varying widths, and your goal is to catch gross mistakes rather than every soft edge.","customWhenToStayStandard":"Stay on 125 when you have no explicit asset-export standard, because it is the value that separates visible blur from harmless imprecision. Keep it when several teams or agencies contribute templates and you want one comparable bar. If your real complaint is that images look bad on retina screens generally, tightening this threshold only addresses part of it — the export practice is the fix, and the threshold merely reports on it.","customTradeoffs":"Tightening toward 100 produces many findings on any template that reuses assets, and unless someone owns re-exporting them the check becomes a list nobody works through. Loosening it lets genuinely soft images pass, and because blur is gradual there is no point at which the failure announces itself — you simply stop hearing about it. Either change breaks comparison with earlier runs, so a template that looks improved may only be measured differently.","customGovernanceNotes":"The Standard value is a general visual-quality judgement rather than a vendor rule, chosen so a pass means something without configuration. A Custom value expresses your own asset-production standard and belongs wherever that standard lives, with the reasoning recorded so it is not quietly relaxed after one awkward campaign. If you tighten it, pair the change with an owner for asset re-export, because a threshold nobody acts on is noise.","customExamples":"A design-led brand sets `maxUpscalePercent` to `100`, requiring every asset to be exported at or above its display size and turning the check into a pipeline gate. A retailer reusing a fixed product-image library across several layout widths sets it to `150`, accepting mild softness to keep the findings limited to genuine mistakes. A team auditing an agency's template keeps `125`, because the value of the default there is that it is not a number either side chose.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-image-rendering"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-image-rendering","parameters":{"maxUpscalePercent":125}}]},"defaultClients":null},{"modelVersion":1,"id":"email-image-source-integrity","slug":"image-sources-resolve","name":"Image sources resolve and are permitted","aka":["broken image source","insecure image host","cid reference","asset host"],"subjectType":"email","category":"link-functional-testing","severity":"recommended","description":"Inventory img/background/style-block image references; resolve cid/data/remote with manual redirect following (chain recorded, capped at 5 hops); fail on unresolvable/undecodable sources, hosts outside approvedAssetHosts (source or redirect destination; empty list = no restriction), and http-only sources whose https upgrade fails.","executionKind":"functional","checkLabel":"Image sources resolve","checkValue":"An asset hosted somewhere that will not resolve over https, or a content-id left dangling by the export, is a hole in the email that only opens once it is in a real inbox.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-image-source-integrity/custom","parameters":[{"name":"approvedAssetHosts","severity":"recommended","standardDefault":[],"formatSummary":"domain-list"}],"standards":[{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"recommended","rationale":"The delivery-path half of image checking: every source must resolve to decodable image bytes over a sound path. Fails on dead references, dangling content-ids, redirect chains beyond five hops, and http-only sources whose https upgrade fails — the last is a common cause of images that work in testing and break in the recipient's client.\n\nOptionally restricts images to hosts you approve, checked at both the original source and the final redirect destination. Leave that list empty and there is no host restriction.\n\nOverlaps `email-image-rendering` 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.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"The delivery-path half of image checking: every image source must resolve to real, decodable image bytes over a sound path.\n\nIt fails on dead references, dangling embedded-image ids, redirect chains beyond five hops, and http:// sources whose secure equivalent does not work — that last one is a common cause of images that look fine in testing and break in the recipient's client, because many clients refuse insecure images outright.\n\nOptionally restrict images to hosts you approve, checked at both the original source and the final redirect destination, so a brand CDN URL that bounces to an off-list tracker fails.\n\nIt overlaps the rendering check on unresolvable images, so a broken URL is reported by both. Their unique halves differ: this one owns the delivery path, that one owns dimensions.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"The delivery-path half of image checking: every image source must resolve to real, decodable image bytes over a sound path.\n\nIt fails on dead references, dangling embedded-image ids, redirect chains beyond five hops, and http:// sources whose secure equivalent does not work — that last one is a common cause of images that look fine in testing and break in the recipient's client, because many clients refuse insecure images outright.\n\nOptionally restrict images to hosts you approve, checked at both the original source and the final redirect destination, so a brand CDN URL that bounces to an off-list tracker fails.\n\nIt overlaps the rendering check on unresolvable images, so a broken URL is reported by both. Their unique halves differ: this one owns the delivery path, that one owns dimensions.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"required","rationale":"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.\n\n**Run this against a test send only**, for the same reason as the image-rendering check: it fetches every image, and almost all transactional email carries an open-tracking pixel.\n\nOptionally restricts images to hosts you approve, checked at the original source and at the final redirect destination. Leave the list empty and there is no host restriction.\n\nIt 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.\n\nAn email with no images passes at no cost.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"required","rationale":"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.\n\n**Run this against a test send only**, for the same reason as the image-rendering check: it fetches every image, and almost all transactional email carries an open-tracking pixel.\n\nOptionally restricts images to hosts you approve, checked at the original source and at the final redirect destination. Leave the list empty and there is no host restriction.\n\nIt 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.\n\nAn email with no images passes at no cost.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"required","rationale":"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.\n\nThat 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.\n\n**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.\n\nOptionally 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.\n\nIt 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.\n\nAn email with no images passes at no cost.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"required","rationale":"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.\n\nThat 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.\n\n**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.\n\nOptionally 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.\n\nIt 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.\n\nAn email with no images passes at no cost.","parameters":null}],"runStats":{"runCount":14,"failureRate":0.35714285714285715,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-image-source-integrity","slug":"image-sources-resolve","aka":["broken image source","insecure image host","cid reference","asset host"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"link-functional-testing","detects":["an image source that will not resolve","an asset served over http rather than https","a dangling content-id left by an export","an image hosted somewhere unapproved"],"commonlyPairedWith":["email-hero-image-renders","email-image-rendering","email-link-integrity","email-logo-visible"],"triggersWhen":["assets are moved to a new host or CDN","a template is exported from a design tool","a campaign is built from an imported template"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on any send where images matter, and always after moving assets between hosts — an environment change is the single most common cause of a hole in the email that only opens once it is in a real inbox. Because it reads the sources rather than rendering the message, it answers the question cheaply and covers every image at once, including the ones below the fold nobody proofs. It is a natural companion to the render checks: this one explains failures those checks report.","whenNotToUse":"Skip it on text-only mail with no imagery. It is also not a judgement about how images look — size, cropping and blur belong to the rendering and clipping checks — nor about whether the image is the right one for the campaign. If your assets are hosted by a platform you cannot influence and you have no host policy to enforce, you will still get value from the broken-and-insecure findings, but the approved-host layer will have nothing to say.","failureMeaning":"A failure means at least one image source is not sound: it does not resolve, it is served over http rather than https, it is a dangling content-id the export never attached, or it comes from a host outside your approved list. The first three are functional defects that render as nothing in a real inbox regardless of client. An unapproved host is a policy finding rather than a broken one — the image may render perfectly and still be somewhere you do not want your brand's assets served from.","thresholdRationale":"One parameter carries the check: `approvedAssetHosts`, whose Standard default is an empty list. Empty means no host restriction while the broken and insecure-source checks still run, so the check is useful out of the box and only becomes a policy instrument when you say so. Its severity is deliberately not `required`, which is what keeps the empty default from routing the check into a needs-configuration skip — an unconfigured run should still tell you your images are broken.","customWhenWarranted":"Set `approvedAssetHosts` when you want images served only from places you control or have vetted. It is worth doing when brand assets have been scattered across ESP-hosted uploads, agency servers and personal cloud storage, because each of those is a future broken image with a different owner. It also has a security dimension: restricting hosts limits what a compromised or expired third-party domain can put inside your email.","customWhenToStayStandard":"Stay with the empty list while you genuinely do not know where your assets live, because a host list assembled from guesswork will fail correct campaigns immediately. Keep it empty when auditing mail you did not build — an agency's proof, a partner's co-branded send — since their hosting choices are not yours to fail. If your only concern is broken and insecure sources, the default already covers it and adding a list buys nothing.","customTradeoffs":"A configured host list means every legitimate new host is a failure until someone updates the list, which is friction you must be willing to own — and the temptation in a hurry is to add whatever appeared rather than to question it. Too permissive a list gives the appearance of a policy with none of its effect. Note also that adding a host list does not make the broken-source checks stricter; it adds a separate policy layer, and confusing the two leads people to think a passing host list means the images render.","customGovernanceNotes":"The Standard behaviour is written to be useful for everyone with no setup, which is why host restriction is opt-in rather than default. An approved-host list is your organisation's asset-hosting policy and belongs with whoever owns brand assets and security review, not with an individual campaign. Review it when a platform is retired, because a list still naming a decommissioned CDN both fails good mail and hides where assets have actually gone.","customExamples":"A brand consolidating on its own CDN sets `approvedAssetHosts` to that domain alone, so any campaign still pulling images from an old ESP upload or an agency server fails until the asset is moved. A company working with two agencies lists its CDN plus each agency's approved delivery domain, keeping the policy enforceable without blocking live work. A team auditing a partner's co-branded send leaves the list empty, since the useful findings there are broken and insecure sources rather than a hosting policy the partner never agreed to.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-image-source-integrity"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-image-source-integrity","parameters":{"approvedAssetHosts":[]}}]},"defaultClients":null},{"modelVersion":1,"id":"email-layout-not-broken","slug":"layout-holds-in-every-client","name":"Layout not broken at any viewport","aka":["broken layout","email rendering bug","collapsed table","client-specific breakage"],"subjectType":"email","category":"content-quality","severity":"required","description":"The overall email layout must not be broken at any selected viewport.","executionKind":"visual","checkLabel":"Layout holds in every client","checkValue":"One unsupported CSS property collapses a layout in a single client and leaves it perfect everywhere else. The recipients who see the broken version are never the ones you proofed to.","hasCustomConfig":false,"requiresConfiguration":false,"price":{"unitCredits":4,"unit":"per_capture","captureCount":6,"captureMailboxes":2,"captureCredits":20,"configuredCredits":24},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":null,"parameters":[],"standards":[{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"recommended","rationale":"Judged from the rendered capture at every viewport you selected, reporting what specifically broke. Cold outreach is minimal HTML by design, so there is less here to break than in a designed campaign — but Outlook renders through the Word engine, which breaks structures that look perfectly safe in a browser, and a cold email that arrives visibly broken reads as spam before a word of it is read.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"Judged from the rendered capture at every viewport and client you selected, reporting what specifically broke.\n\nThis is the classic email failure and the reason email testing exists: Outlook renders through the Word engine, which breaks table structures that are flawless in a browser, and mobile reflow collapses multi-column layouts. An email that arrives visibly broken is not a weakened campaign, it is a wasted one — multiplied across your entire list.\n\nIt is deliberately strict: any layout issue it identifies fails the check, even when its overall read of the email is favourable. It is not exhaustive, though, and subtle text overflow can still pass. Read a pass as \"nothing obviously broken\" rather than \"renders perfectly everywhere\".","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"Judged from the rendered capture at every viewport and client you selected, reporting what specifically broke.\n\nThis is the classic email failure and the reason email testing exists: Outlook renders through the Word engine, which breaks table structures that are flawless in a browser, and mobile reflow collapses multi-column layouts. An email that arrives visibly broken is not a weakened campaign, it is a wasted one — multiplied across your entire list.\n\nIt is deliberately strict: any layout issue it identifies fails the check, even when its overall read of the email is favourable. It is not exhaustive, though, and subtle text overflow can still pass. Read a pass as \"nothing obviously broken\" rather than \"renders perfectly everywhere\".","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"recommended","rationale":"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.\n\nTransactional email is opened on a phone more than anything else you send: the notification arrives and the person taps it. That is where layout breaks live. Across our own runs, every failure we have recorded 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 customer is holding. Outlook is the other half of the risk, because it renders through the Word engine and breaks structures that are perfectly safe in a browser.\n\nThis 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 a real mailbox, at three widths, in two clients — so it carries the cost of the renders as well as the judgement.\n\nIt reports rather than blocks, deliberately. It can tell you something is cut off; it cannot tell you whether the cut-off thing was a legal footnote or your \"Reset password\" button. That call is yours.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"recommended","rationale":"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.\n\nTransactional email is opened on a phone more than anything else you send: the notification arrives and the person taps it. That is where layout breaks live. Across our own runs, every failure we have recorded 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 customer is holding. Outlook is the other half of the risk, because it renders through the Word engine and breaks structures that are perfectly safe in a browser.\n\nThis 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 a real mailbox, at three widths, in two clients — so it carries the cost of the renders as well as the judgement.\n\nIt reports rather than blocks, deliberately. It can tell you something is cut off; it cannot tell you whether the cut-off thing was a legal footnote or your \"Reset password\" button. That call is yours.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"recommended","rationale":"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.\n\nOutlook 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.\n\nThis 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.\n\nIf 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.\n\nIt 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.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"recommended","rationale":"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.\n\nOutlook 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.\n\nThis 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.\n\nIf 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.\n\nIt 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.","parameters":null}],"runStats":{"runCount":867,"failureRate":0.011534025374855825,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-layout-not-broken","slug":"layout-holds-in-every-client","aka":["broken layout","email rendering bug","collapsed table","client-specific breakage"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"content-quality","detects":["a layout collapsed in one mail client","columns stacked or overlapping unintentionally","content pushed outside the message width"],"commonlyPairedWith":["email-cta-button-visible","email-image-clipping","email-logo-visible","email-typography"],"triggersWhen":["a template is built or substantially edited","a new mail client is added to the audit","an AI-generated or imported template is used"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on every template you have not previously proven across clients, and on any send generated by a tool rather than hand-built — imported and AI-written HTML is where unsupported CSS most often appears. One unsupported property collapses a layout in a single client and leaves it perfect everywhere else, so the recipients who see the broken version are never the ones you proofed to. Render it across the clients your list actually uses, because that is the only way the finding maps to real people.","whenNotToUse":"Skip it on plain, single-column text mail where there is effectively no layout to break — most transactional notices and much personal-styled outreach. It is also not a design review: it answers whether the structure held, not whether the composition is good or the hierarchy sensible. Because every client and width is a render, it is the wrong check to run broadly when you are only trying to answer a source-level question such as whether an image host resolves.","failureMeaning":"A failure means the structure did not hold in the client and width captured — columns collapsed, content overlapped, or elements ran outside the intended width. Read it as a statement about a slice of your audience, and note which slice, because the client named is usually also the explanation. A pass in other clients alongside the failure is the normal shape of this finding rather than a contradiction.","thresholdRationale":"This check has no tunable thresholds. It is a rendered structural judgement about the captured message, with no numeric limits or configurable lists — the only variables are which clients and widths the job renders, which are job settings rather than parameters. There is nothing here to calibrate per brand, because a collapsed layout is not a matter of preference.","customWhenWarranted":"Never — this check exposes no Custom Parameters and its public custom page redirects to the Standard page. The variation you may actually want is in client selection, which is set on the job rather than on the check.","customWhenToStayStandard":"Always, since there is no alternative configuration. Where you exercise judgement is coverage: which clients and widths your standard renders, and therefore which recipients your pass describes.","customTradeoffs":"There is nothing to override, so nothing to trade away. The genuine trade is cost against certainty — each client added is a render, and this defect lives entirely in the differences between them.","customGovernanceNotes":"Because the check has no configurable values, governance belongs to the client matrix rather than to the check itself. Keeping that matrix aligned with your actual audience mix is what keeps the verdict meaningful over time.","customExamples":"No override examples apply, as there are no parameters. Teams differentiate this check by rendering the clients with the most divergent engines, since a layout that survives those tends to survive everywhere.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-layout-not-broken"]},"agentContractCustom":null,"defaultClients":{"mobile":["gmail_chrome_mobile","outlook_chrome_mobile"],"tablet":["gmail_chrome_tablet","outlook_chrome_tablet"],"desktop":["gmail_chrome","outlook_chrome"]}},{"modelVersion":1,"id":"email-link-integrity","slug":"every-link-goes-where-it-should","name":"Links valid, reachable, and correctly redirected","aka":["broken links","dead link in email","link checker","redirect chain"],"subjectType":"email","category":"link-functional-testing","severity":"recommended","description":"Every link in the email must parse as a valid absolute URL with a legitimate scheme, resolve over HTTP (redirect chains followed and recorded), and land on an approved destination when a domain list is configured. Bot-protected links are reported unverifiable, never failed. See docs/EMAIL-LINK-INTEGRITY.md.","executionKind":"functional","checkLabel":"Every link goes where it should","checkValue":"Every link gets clicked by machine before a human clicks it. A dead link in a send cannot be recalled — the mail is already in the inbox, and the traffic you paid for lands on a 404.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-link-integrity/custom","parameters":[{"name":"approvedLinkDomains","severity":"recommended","standardDefault":[],"formatSummary":"domain-list"},{"name":"allowedSchemes","severity":"recommended","standardDefault":["https","http","mailto","tel"],"formatSummary":"non-empty-string-array"},{"name":"maxRedirectHops","severity":"required","standardDefault":20,"formatSummary":"positive-integer"},{"name":"fetchAccountActionLinks","severity":"recommended","standardDefault":false,"formatSummary":"boolean-flag"}],"standards":[{"setId":"cold-outreach-standard","setName":"Cold outreach — standard","category":"cold-outreach","tier":"standard","severity":"required","rationale":"A cold email gets one link and one chance. This clicks every link by machine before your prospect does. It catches dead destinations, but more valuably it catches what a human proofreading the copy cannot see: a personalisation token that never resolved inside an href (`{{...}}`, `%%...%%`), or a scheme-less URL that Outlook.com silently strips. A broken link here does not just lose a click — it wastes the only touch you get with that person.\n\nTwo kinds of link are never fetched, because fetching them would do something rather than read something: your unsubscribe and preference links, since following a one-click opt-out would actually opt someone out; and links whose path names an account action — verify, confirm, activate, reset, revoke and the like — since those endpoints complete on GET. Both are listed in the result with the reason they were skipped, so nothing disappears quietly.\n\nFailures 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. A FAIL means the link is provably broken for everyone.\n\nOne caveat: fetching a tracked link registers a click, and ESP click-redirectors are still followed. Validate a test send, not a live campaign — and note Salesforce Marketing Cloud has no native bot-click filtering.","parameters":{"fetchAccountActionLinks":true}},{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"required","rationale":"A cold email gets one link and one chance. This clicks every link by machine before your prospect does. It catches dead destinations, but more valuably it catches what a human proofreading the copy cannot see: a personalisation token that never resolved inside an href (`{{...}}`, `%%...%%`), or a scheme-less URL that Outlook.com silently strips. A broken link here does not just lose a click — it wastes the only touch you get with that person.\n\nTwo kinds of link are never fetched, because fetching them would do something rather than read something: your unsubscribe and preference links, since following a one-click opt-out would actually opt someone out; and links whose path names an account action — verify, confirm, activate, reset, revoke and the like — since those endpoints complete on GET. Both are listed in the result with the reason they were skipped, so nothing disappears quietly.\n\nFailures 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. A FAIL means the link is provably broken for everyone.\n\nOne caveat: fetching a tracked link registers a click, and ESP click-redirectors are still followed. Validate a test send, not a live campaign — and note Salesforce Marketing Cloud has no native bot-click filtering.","parameters":{"fetchAccountActionLinks":true}},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"Clicks every link by machine before your readers do. A marketing email is link-dense — hero, calls to action, product tiles, footer — and every one is a conversion path, so a dead link does not cost you a click, it costs you the campaign, across your whole list at once.\n\nBeyond dead destinations it catches what proofreading cannot see: a personalisation token that never resolved inside an href, a bare # placeholder, a scheme-less URL that Outlook.com silently strips, and malformed tel: or javascript: hrefs. It failed 10.3% of real marketing email, and every sampled failure was a genuine defect.\n\nFailures 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 person with a browser. A failure means the link is provably broken for everyone.\n\nSome links are actions rather than addresses, and those are never fetched. Your unsubscribe and preference links, because following a one-click opt-out would genuinely opt someone out. And links whose path names an account action — verify, confirm, activate, reset, revoke and the like — because those endpoints complete on GET, so requesting one can consume a single-use token. Everything skipped is listed in the result with the reason it was skipped, so you can see what was not checked instead of reading it as a clean pass.\n\n**Validate a test send, not a live campaign.** Two reasons that survive the skip rule. It works on the shape of a URL, so it cannot be complete — an action endpoint behind a neutral path will still be fetched. And every ESP click-redirector in your email is still followed, which registers a click in your own reporting; note that Salesforce Marketing Cloud has no native bot-click filtering. Links are inspected with HEAD only, and a destination that refuses HEAD is reported unverifiable rather than re-requested with GET, because getting that verdict would mean running the endpoint's GET handler.","parameters":{"fetchAccountActionLinks":true}},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"Clicks every link by machine before your readers do. A marketing email is link-dense — hero, calls to action, product tiles, footer — and every one is a conversion path, so a dead link does not cost you a click, it costs you the campaign, across your whole list at once.\n\nBeyond dead destinations it catches what proofreading cannot see: a personalisation token that never resolved inside an href, a bare # placeholder, a scheme-less URL that Outlook.com silently strips, and malformed tel: or javascript: hrefs. It failed 10.3% of real marketing email, and every sampled failure was a genuine defect.\n\nFailures 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 person with a browser. A failure means the link is provably broken for everyone.\n\nSome links are actions rather than addresses, and those are never fetched. Your unsubscribe and preference links, because following a one-click opt-out would genuinely opt someone out. And links whose path names an account action — verify, confirm, activate, reset, revoke and the like — because those endpoints complete on GET, so requesting one can consume a single-use token. Everything skipped is listed in the result with the reason it was skipped, so you can see what was not checked instead of reading it as a clean pass.\n\n**Validate a test send, not a live campaign.** Two reasons that survive the skip rule. It works on the shape of a URL, so it cannot be complete — an action endpoint behind a neutral path will still be fetched. And every ESP click-redirector in your email is still followed, which registers a click in your own reporting; note that Salesforce Marketing Cloud has no native bot-click filtering. Links are inspected with HEAD only, and a destination that refuses HEAD is reported unverifiable rather than re-requested with GET, because getting that verdict would mean running the endpoint's GET handler.","parameters":{"fetchAccountActionLinks":true}},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"required","rationale":"A dead link in a transactional email is a total failure. Your customer clicked something, they are waiting, and the reset link, the tracking link or the \"view your order\" button is the entire payload — there is no second touch and no campaign to make it up on.\n\n**Run this against a test send only.** This check follows the links in your email, and in transactional mail the links *do* things: they confirm addresses, sign people in, authenticate order access. Links whose path names an account action — auth, authenticate, verify, confirm, activate, revoke, reset, unlock, magic, passwordless — are refused before any request is made, and listed in the result with the reason, so the shapes we can recognise are no longer touched. Treat that as a mitigation, not a guarantee: the rule reads the shape of a URL, so an action endpoint behind a neutral path is still fetched, and every ESP click-redirector is still followed. We have seen this in shipped mail — a \"this isn't my account\" link that revokes the recipient's own email verification. Point it at a test message with test data. Never at a live send.\n\nLinks are inspected with HEAD only, and the GET fallback is suppressed: a destination that refuses HEAD is reported as *unverifiable* rather than re-requested with GET. RFC 9110 requires HEAD to be safe, but Express routes it into the GET handler, Rack strips the body after the action has already run, and Django aliases head to get — so on a real framework the only reliable protection is not making the second request.\n\nWithin that constraint it 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. In real transactional mail we found all three, including a `%%track%%` token that never rendered, sitting inside the href of a \"Confirm your email\" message. None of that requires the network — the source layer is pure and always safe.\n\nFailures 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.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"required","rationale":"A dead link in a transactional email is a total failure. Your customer clicked something, they are waiting, and the reset link, the tracking link or the \"view your order\" button is the entire payload — there is no second touch and no campaign to make it up on.\n\n**Run this against a test send only.** This check follows the links in your email, and in transactional mail the links *do* things: they confirm addresses, sign people in, authenticate order access. Links whose path names an account action — auth, authenticate, verify, confirm, activate, revoke, reset, unlock, magic, passwordless — are refused before any request is made, and listed in the result with the reason, so the shapes we can recognise are no longer touched. Treat that as a mitigation, not a guarantee: the rule reads the shape of a URL, so an action endpoint behind a neutral path is still fetched, and every ESP click-redirector is still followed. We have seen this in shipped mail — a \"this isn't my account\" link that revokes the recipient's own email verification. Point it at a test message with test data. Never at a live send.\n\nLinks are inspected with HEAD only, and the GET fallback is suppressed: a destination that refuses HEAD is reported as *unverifiable* rather than re-requested with GET. RFC 9110 requires HEAD to be safe, but Express routes it into the GET handler, Rack strips the body after the action has already run, and Django aliases head to get — so on a real framework the only reliable protection is not making the second request.\n\nWithin that constraint it 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. In real transactional mail we found all three, including a `%%track%%` token that never rendered, sitting inside the href of a \"Confirm your email\" message. None of that requires the network — the source layer is pure and always safe.\n\nFailures 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.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"required","rationale":"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.\n\nIt 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.\n\n**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.\n\nOne 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.\n\nFailures 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.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"required","rationale":"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.\n\nIt 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.\n\n**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.\n\nOne 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.\n\nFailures 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.","parameters":null}],"runStats":{"runCount":14,"failureRate":0.5714285714285714,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-link-integrity","slug":"every-link-goes-where-it-should","aka":["broken links","dead link in email","link checker","redirect chain"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"link-functional-testing","detects":["a link that resolves to an error","a destination outside your approved domains","a redirect chain longer than a browser will follow","a link using an unexpected scheme"],"commonlyPairedWith":["email-tracking-integrity","email-utm-inventory","email-image-source-integrity","email-cta-button-visible"],"triggersWhen":["a campaign with links is built","a landing page is moved or retired","a link-shortening or tracking domain changes"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on every send that contains links, because a dead link in a send cannot be recalled — the mail is already in the inbox and the traffic you paid for lands on a 404. Every link gets clicked by machine before a human clicks it, redirects and all, which is the only way to know a shortener or tracking wrapper still resolves. It is especially worth running when landing pages have been moved or retired, since that is how a campaign built from a proven template starts pointing at nothing.","whenNotToUse":"Be deliberate about running it on mail whose links act on an account. Unsubscribe and account-action links are never fetched by default, precisely because in real transactional email most messages carry a link that acts the moment something requests it — a confirmation, a cancellation, a one-click opt-out. It is also not a page-quality check: a link that resolves to a live page passes even if the page is the wrong one, and a wall that blocks bots never fails a link, so a failure means broken for everyone rather than merely awkward for us.","failureMeaning":"A failure means a link did not behave: it resolved to an error, exceeded the redirect limit, used a scheme you did not allow, or landed outside your approved destinations. The first two are functional defects with immediate revenue cost on any campaign driving clicks. A destination outside your list is a policy finding instead — the link may work perfectly and still be sending your recipients somewhere you did not intend, which is how tracking-domain and agency misconfigurations surface.","thresholdRationale":"Four parameters carry the check. `approvedLinkDomains` is empty by default, meaning no destination restriction while broken-link checking always runs. `allowedSchemes` defaults to `https`, `http`, `mailto` and `tel` — the four a marketing email legitimately uses. `maxRedirectHops` defaults to `20`, which is the Fetch specification's cap, so beyond it no browser follows either. `fetchAccountActionLinks` defaults to `false`, because the safe reading must be the one you get by saying nothing.","customWhenWarranted":"Set `fetchAccountActionLinks` to `true` for transactional and operational mail where the action link *is* the message — a password reset whose link is broken is a complete failure, and skipping it to be safe means never testing the only thing that matters. Use `approvedLinkDomains` when you want destinations restricted to your own properties and approved partners, which catches agency and affiliate links nobody sanctioned. Tighten `allowedSchemes` to `https` alone when your policy forbids insecure links.","customWhenToStayStandard":"Leave `fetchAccountActionLinks` off for marketing mail — the risk of triggering a real opt-out or account action for a real subscriber outweighs the coverage you would gain. Keep `approvedLinkDomains` empty when auditing sends you did not build, since someone else's legitimate destinations are not yours to fail. Keep `maxRedirectHops` at the specification cap unless you have a documented reason, because a lower value fails links that browsers follow perfectly well.","customTradeoffs":"Enabling action-link fetching is the consequential override: on a real recipient's message it can perform the action the link exists to perform, which is why it is framed as your assertion that no real person's account sits behind those links. A configured domain list means every new legitimate destination fails until the list is updated, and lists maintained under deadline pressure tend to be widened rather than corrected. Lowering the redirect cap catches sloppy chains but will also fail long-established shortener stacks that work.","customGovernanceNotes":"The Standard configuration transcribes outside authority where it exists — the Fetch specification's redirect cap, the safe-method discipline that governs machine fetching — and defaults to caution where it does not. The action-link flag is best treated as a per-send assertion made by someone who knows what is behind those links, not a global setting quietly switched on once. An approved-domain list is your own policy and belongs with whoever owns campaign destinations and tracking infrastructure.","customExamples":"A team auditing password-reset mail in a test environment sets `fetchAccountActionLinks` to `true`, since every link in the message is an account action and skipping them would test nothing. A brand consolidating tracking sets `approvedLinkDomains` to its own domains plus its single approved click-tracking domain, so an agency's own shortener fails until it is either sanctioned or removed. A security-conscious sender sets `allowedSchemes` to `[\"https\"]`, turning any surviving plain-http link into a failure rather than a footnote.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-link-integrity"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-link-integrity","parameters":{"approvedLinkDomains":[],"allowedSchemes":["https","http","mailto","tel"],"maxRedirectHops":20,"fetchAccountActionLinks":false}}]},"defaultClients":null},{"modelVersion":1,"id":"email-logo-visible","slug":"logo-visible-in-the-header","name":"Brand logo visible in header","aka":["email logo","header image","brand mark in email","logo not rendering"],"subjectType":"email","category":"brand-compliance","severity":"required","description":"The brand logo must be present and clearly visible in the header area of the email at all selected viewports.","executionKind":"visual","checkLabel":"Logo visible in the header","checkValue":"The logo is how a recipient decides in half a second that the mail is from you and not a phishing attempt. A header image that fails at one viewport removes that signal for everyone reading at that width.","hasCustomConfig":false,"requiresConfiguration":false,"price":{"unitCredits":4,"unit":"per_capture","captureCount":4,"captureMailboxes":2,"captureCredits":20,"configuredCredits":16},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":null,"parameters":[],"standards":[{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"recommended","rationale":"Confirms your brand logo is present and in the upper part of the email, judged from the rendered capture at each viewport and client.\n\nIt catches a logo image that fails to load at the top of a campaign, a logo pushed below the fold by a broken header, and a template that shipped without one — each of which costs you the recognition that gets your next send opened, and the trust that separates you from a phishing attempt.\n\nIt reports rather than blocks, because a logo in the header is a strong convention rather than a rule. Text-forward campaigns and live-text wordmarks are legitimate choices. Where your brand has its own header or footer standard, the footer check is the one you can configure to enforce it.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"recommended","rationale":"Confirms your brand logo is present and in the upper part of the email, judged from the rendered capture at each viewport and client.\n\nIt catches a logo image that fails to load at the top of a campaign, a logo pushed below the fold by a broken header, and a template that shipped without one — each of which costs you the recognition that gets your next send opened, and the trust that separates you from a phishing attempt.\n\nIt reports rather than blocks, because a logo in the header is a strong convention rather than a rule. Text-forward campaigns and live-text wordmarks are legitimate choices. Where your brand has its own header or footer standard, the footer check is the one you can configure to enforce it.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"recommended","rationale":"Confirms your logo is visible and fully rendered at the top of the email, in Gmail and Outlook, on mobile and desktop.\n\nOn a campaign this is a branding question. On transactional mail it is closer to a security one. Order confirmations, shipping notices and password resets are the most impersonated email there is — nobody bothers faking a newsletter. Your customer's ability to spot a fake depends on knowing what the real one looks like, and every unbranded receipt you send erodes that a little.\n\nIt also catches the plain failure: a logo hosted somewhere that stopped resolving, rendering as a broken-image icon or an empty box at the top of every receipt you send. That is the kind of defect nobody notices internally, because your own mail client has the image cached.\n\nIt reports rather than blocks. A missing logo is a real defect and not a fatal one.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"recommended","rationale":"Confirms your logo is visible and fully rendered at the top of the email, in Gmail and Outlook, on mobile and desktop.\n\nOn a campaign this is a branding question. On transactional mail it is closer to a security one. Order confirmations, shipping notices and password resets are the most impersonated email there is — nobody bothers faking a newsletter. Your customer's ability to spot a fake depends on knowing what the real one looks like, and every unbranded receipt you send erodes that a little.\n\nIt also catches the plain failure: a logo hosted somewhere that stopped resolving, rendering as a broken-image icon or an empty box at the top of every receipt you send. That is the kind of defect nobody notices internally, because your own mail client has the image cached.\n\nIt reports rather than blocks. A missing logo is a real defect and not a fatal one.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"recommended","rationale":"Confirms your logo is visible and fully rendered at the top of the email, in Gmail and Outlook, on mobile and desktop.\n\nOn 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.\n\nIt 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.\n\n**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.\n\nIt reports rather than blocks. A missing logo is a real defect and not a fatal one.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"recommended","rationale":"Confirms your logo is visible and fully rendered at the top of the email, in Gmail and Outlook, on mobile and desktop.\n\nOn 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.\n\nIt 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.\n\n**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.\n\nIt reports rather than blocks. A missing logo is a real defect and not a fatal one.","parameters":null}],"runStats":{"runCount":579,"failureRate":0.0690846286701209,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-logo-visible","slug":"logo-visible-in-the-header","aka":["email logo","header image","brand mark in email","logo not rendering"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"brand-compliance","detects":["a header logo that fails to render in a client","a mark broken at one viewport","a logo too small or obscured to recognise"],"commonlyPairedWith":["email-hero-image-renders","email-image-source-integrity","email-layout-not-broken","email-image-alt-text"],"triggersWhen":["a template header changes","brand assets are re-hosted","a new mail client or viewport is added to the audit"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on any send where the recipient's first judgement matters — cold outreach, first-touch onboarding, anything a reader might mistake for phishing if it does not look like you. It is rendered per client and per viewport, which is the whole reason it exists: a header that works in your own inbox can fail in the client half your list uses, and a proof sent to one address cannot see that. Include it whenever you have changed a template header or moved brand assets.","whenNotToUse":"Skip it on deliberately plain-text-styled mail, where a logo is intentionally absent — much cold outreach is written to look personal, and a missing header there is the design. It is also not the check for whether the *correct* logo variant was used against a given background or whether clear-space rules were honoured; it answers whether the mark is visibly there and recognisable. Because it is a rendered check, it costs a capture per client and viewport, so narrow the clients rather than running everything when budget is a concern.","failureMeaning":"A failure means the logo was not visibly present, or not recognisable, in the client and width that was captured. That removes the half-second signal a recipient uses to decide the mail is from you and not an impersonation, which matters most on exactly the sends where trust is thinnest. Because it is per client and per width, read the finding as a statement about a slice of your audience rather than about the campaign as a whole — and note which slice, because that is what tells you the cause.","thresholdRationale":"This check has no tunable thresholds. It is a rendered presence-and-recognisability judgement made against the captured message, with no numeric dial and no configurable list — what varies is which clients and viewports you choose to capture, and that is a job setting rather than a parameter of the check. There is consequently nothing here to calibrate to your brand.","customWhenWarranted":"Never — this check exposes no Custom Parameters, so its public custom page redirects to the Standard page. If you need rules about which logo variant belongs where, that judgement is configurable on the website logo check rather than here.","customWhenToStayStandard":"Always, since Standard is the only behaviour. The decisions available to you are which mail clients and widths to render, and whether the check belongs in the set for a send styled to look personal.","customTradeoffs":"There is nothing to trade away, because no value can be overridden. The real trade-off is cost against coverage: each additional client and viewport is another render, and a header defect is usually specific to one of them.","customGovernanceNotes":"Because nothing here is configurable, there is no local policy for a governance process to own — the verdict is the same question asked of every brand. What is worth governing is the client list your standards render against, since that is what decides which parts of your audience the answer covers.","customExamples":"There are no override examples, as the check has no parameters. The nearest equivalent choice is client selection: teams with Outlook-heavy audiences render there specifically, because that is where header images most often fail.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-logo-visible"]},"agentContractCustom":null,"defaultClients":{"mobile":["gmail_chrome_mobile","outlook_chrome_mobile"],"desktop":["gmail_chrome","outlook_chrome"]}},{"modelVersion":1,"id":"email-no-placeholder-text","slug":"no-unfilled-merge-tags","name":"No placeholder / merge-tag text","aka":["unmerged merge tags","personalization failure","{{first_name}}","unresolved tokens"],"subjectType":"email","category":"content-quality","severity":"required","description":"Scan subject, first 200 chars of text/plain (preheader proxy), and HTML body text against placeholderPatterns.","executionKind":"functional","checkLabel":"No unfilled merge tags","checkValue":"Placeholders like {{first_name}} or [COMPANY] reaching a real inbox mean the personalization data never filled in — one of the most visible email failures there is.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-no-placeholder-text/custom","parameters":[{"name":"placeholderPatterns","severity":"required","standardDefault":["\\{\\{[^}]+\\}\\}","\\[[A-Z ]{3,}\\]","lorem ipsum","\\[FIRST NAME\\]","\\[LAST NAME\\]","\\[COMPANY\\]","\\[DATE\\]"],"formatSummary":"regex-pattern-list"}],"standards":[{"setId":"cold-outreach-standard","setName":"Cold outreach — standard","category":"cold-outreach","tier":"standard","severity":"required","rationale":"Cold outreach only works if the message reads as though it was written to one person. A leaked merge tag — \"Hi {{firstName}}\" — proves the opposite in the first line, and nothing later in the email recovers it. This is the rare defect that makes a send worth less than not sending at all, which is why it blocks. Runs with no configuration; the default patterns cover `{{tokens}}`, `[COMPANY NAME]`, and placeholder filler.","parameters":null},{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"required","rationale":"Cold outreach only works if the message reads as though it was written to one person. A leaked merge tag — \"Hi {{firstName}}\" — proves the opposite in the first line, and nothing later in the email recovers it. This is the rare defect that makes a send worth less than not sending at all, which is why it blocks. Runs with no configuration; the default patterns cover `{{tokens}}`, `[COMPANY NAME]`, and placeholder filler.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"\"Hi {{first_name}}\" reaching your whole list is the most recognisable failure in email marketing, and it cannot be undone once sent.\n\nThis scans your subject line, preview text and body for unfilled merge tags and placeholder copy — {{tokens}}, [COMPANY NAME], lorem ipsum filler — with no configuration required, and you can supply your own patterns.\n\nOne limit worth knowing: it catches a token that did not render. It does not catch a token that resolved to nothing — \"Hi ,\" — which is the more common modern failure, because most platforms now substitute an empty string rather than leaving the raw tag behind.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"\"Hi {{first_name}}\" reaching your whole list is the most recognisable failure in email marketing, and it cannot be undone once sent.\n\nThis scans your subject line, preview text and body for unfilled merge tags and placeholder copy — {{tokens}}, [COMPANY NAME], lorem ipsum filler — with no configuration required, and you can supply your own patterns.\n\nOne limit worth knowing: it catches a token that did not render. It does not catch a token that resolved to nothing — \"Hi ,\" — which is the more common modern failure, because most platforms now substitute an empty string rather than leaving the raw tag behind.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"required","rationale":"Your customer is waiting for this email and about to act on it, and it carries more merge fields than anything else you send — order number, amount, date, tracking link, reset link. This catches the ones that did not fill in.\n\nThat is why it blocks. A receipt showing `{{order_total}}` or a confirmation whose button reads `%%reset_password_link%%` is worse than sending nothing: the recipient cannot complete what they started, and they learn not to trust your mail. We found exactly that in real mail — an unrendered reset link inside an email titled \"NEW ACCOUNT CONFIRMATION\". Across real transactional email we find this in about one message in thirty, roughly ten times the rate in marketing campaigns, because transactional templates have far more to fill in and get far less proofreading.\n\nRuns with no configuration. The default patterns cover the documented merge delimiters — `{{tokens}}`, `%%tokens%%`, `*|MAILCHIMP|*` — plus placeholder filler, across your subject line, preview text and body. If your platform uses its own delimiters, add them.\n\nOne limit worth stating: it finds tokens that never filled in, not values that filled in wrongly. A total rendering as `$0.00` is indistinguishable from free shipping, and free shipping is common — so this check will not catch it.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"required","rationale":"Your customer is waiting for this email and about to act on it, and it carries more merge fields than anything else you send — order number, amount, date, tracking link, reset link. This catches the ones that did not fill in.\n\nThat is why it blocks. A receipt showing `{{order_total}}` or a confirmation whose button reads `%%reset_password_link%%` is worse than sending nothing: the recipient cannot complete what they started, and they learn not to trust your mail. We found exactly that in real mail — an unrendered reset link inside an email titled \"NEW ACCOUNT CONFIRMATION\". Across real transactional email we find this in about one message in thirty, roughly ten times the rate in marketing campaigns, because transactional templates have far more to fill in and get far less proofreading.\n\nRuns with no configuration. The default patterns cover the documented merge delimiters — `{{tokens}}`, `%%tokens%%`, `*|MAILCHIMP|*` — plus placeholder filler, across your subject line, preview text and body. If your platform uses its own delimiters, add them.\n\nOne limit worth stating: it finds tokens that never filled in, not values that filled in wrongly. A total rendering as `$0.00` is indistinguishable from free shipping, and free shipping is common — so this check will not catch it.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"required","rationale":"Catches merge fields that never filled in — `{{first_name}}`, `%%reset_link%%`, `*|SUBJECT|*` — across your subject line, preview text and body.\n\nThat 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.\n\nWe 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.\n\nRuns 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.\n\nOne 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.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"required","rationale":"Catches merge fields that never filled in — `{{first_name}}`, `%%reset_link%%`, `*|SUBJECT|*` — across your subject line, preview text and body.\n\nThat 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.\n\nWe 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.\n\nRuns 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.\n\nOne 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.","parameters":null}],"runStats":{"runCount":150,"failureRate":0.05333333333333334,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-no-placeholder-text","slug":"no-unfilled-merge-tags","aka":["unmerged merge tags","personalization failure","{{first_name}}","unresolved tokens"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"content-quality","detects":["a merge tag that reached the inbox unresolved","ESP token syntax surviving the send","template filler left in the body"],"commonlyPairedWith":["email-subject-content","email-footer-complete","email-preheader"],"triggersWhen":["a personalised or cold-outreach send goes out","a list or field mapping changes","a template is imported from another ESP"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on every personalised send, and treat it as mandatory on cold outreach, where one unresolved `{{firstName}}` destroys the premise of the entire message. It reads the delivered message, which is the only place the answer exists — a preview populates from test data and will happily show a name that a real recipient's record does not have. It is a source-level check with no model call, so there is no reason to leave it out of a set.","whenNotToUse":"Skip it on mail that legitimately shows token-like syntax as content: developer documentation sent by email, a release note quoting template code, an internal message about the templates themselves. It is also not a check on whether the personalisation is *correct* — a tag that resolved to the wrong person's name passes, because the token is gone and nothing in the source says the value was wrong. That failure needs data review, not pattern matching.","failureMeaning":"A failure means unresolved token syntax or template filler is in the delivered message, and it quotes what it found. This is among the most visible email failures there is, because a recipient reads it instantly as automation that went wrong. The cause is usually a data gap rather than a template error — the field exists in the template and is empty or unmapped for that segment — so the finding points at your list as often as at your HTML.","thresholdRationale":"One parameter carries the check: `placeholderPatterns`, a list of regular expressions. Its Standard default covers the four common ESP token styles — double braces, double percent signs, asterisk-pipe delimiters — plus `lorem ipsum` and the specific bracketed merge fields `[FIRST NAME]`, `[LAST NAME]`, `[COMPANY]` and `[DATE]`. Those bracketed entries are specific for a measured reason: a generic bracket pattern flagged ordinary subject tags such as `[Webinar Today]` and `[Video]` across thousands of real emails, so the named fields carry the check instead.","customWhenWarranted":"Override `placeholderPatterns` when your stack's token syntax is not among the defaults, which is the common case for ESPs with distinctive delimiters or for in-house sending code. Add your own patterns when you have a house convention for unfinished copy in email, or when a migration has left a second token style in circulation that you want caught until it is cleaned out. Take the patterns from a real unresolved send rather than from documentation, since what reaches the inbox is what matters.","customWhenToStayStandard":"Stay on the defaults if your ESP uses one of the covered syntaxes and you have no house filler convention, because the list is already tuned against real mail. Keep them for editorial newsletters especially, where bracketed phrases appear legitimately in subject lines and body copy — this is exactly the case the generic bracket pattern was removed for. If your concern is placeholder *images* or unfilled links rather than text, widening this list will not reach them.","customTradeoffs":"Patterns compile case-insensitively, so a class written for uppercase letters cannot express \"uppercase placeholder\" — a mistake that turns a narrow rule into a broad one without any warning. Broad patterns are the real hazard here: a bracket or brace rule wide enough to catch every token style also catches legitimate editorial punctuation, and a check that fails good sends stops being read. Supplying your own list replaces the defaults rather than adding to them, so carry the originals forward unless you mean to drop them.","customGovernanceNotes":"The Standard list is deliberately shaped by measurement against a real corpus rather than by completeness, which is why it names specific merge fields instead of matching all brackets. A Custom list encodes your own sending stack and belongs with whoever owns the templates, reviewed when you change ESP — patterns for a platform you no longer use quietly stop protecting anything. Record why each added pattern exists, because the ones nobody can explain are the ones that later cause a false failure.","customExamples":"A team on an ESP using `${field}` syntax adds `\\\\$\\\\{[^}]+\\\\}` alongside the defaults, catching a token style the generic list has no view of. A company mid-migration keeps both its old and new platforms' delimiters in the list for a quarter, so any template still carrying the retired syntax surfaces before it goes to volume. A publisher whose newsletters routinely use bracketed labels in copy keeps the Standard list untouched rather than adding a general bracket rule, accepting narrower coverage in exchange for a check that never fails a legitimate issue.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-no-placeholder-text"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-no-placeholder-text","parameters":{"placeholderPatterns":["\\{\\{[^}]+\\}\\}","\\[[A-Z ]{3,}\\]","lorem ipsum","\\[FIRST NAME\\]","\\[LAST NAME\\]","\\[COMPANY\\]","\\[DATE\\]"]}}]},"defaultClients":null},{"modelVersion":1,"id":"email-physical-address-present","slug":"physical-address-included","name":"Physical mailing address present","aka":["postal address","CAN-SPAM address","mailing address in footer","sender address"],"subjectType":"email","category":"legal-privacy-compliance","severity":"required","description":"Strip HTML tags from body and match physical address patterns (street number + street + city/state/postal code).","executionKind":"functional","checkLabel":"Physical address included","checkValue":"CAN-SPAM requires commercial email to show the sender’s physical postal address (usually in the footer). Transactional email is exempt — check the email’s purpose before failing it.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-physical-address-present/custom","parameters":[{"name":"expectedAddressCountries","severity":"recommended","standardDefault":["US"],"formatSummary":"non-empty-string-array"},{"name":"senderPostalAddress","severity":"required","standardDefault":"","formatSummary":"optional-string"},{"name":"recipientAddressLabels","severity":"recommended","standardDefault":["ship to","shipping address","deliver to","delivery address","bill to","billing address","sold to","your address"],"formatSummary":"non-empty-string-array"}],"standards":[{"setId":"cold-outreach-standard","setName":"Cold outreach — standard","category":"cold-outreach","tier":"standard","severity":"required","rationale":"A valid physical postal address is mandatory in every commercial email, and cold outreach is commercial however personal it reads — CAN-SPAM sets no volume floor (15 U.S.C. §7704(a)(5)(A)(iii), 16 CFR §316.2(p)). It is also the requirement senders omit most often.\n\nUnlike a machine-readable unsubscribe, an address costs you nothing: there is no evidence it affects deliverability or reply rate, and it signals a real business behind the message. A street address, a PO box, or a registered private mailbox all satisfy the law.\n\nThe check anchors on a postcode that agrees with its region, and recognises US, UK, Canadian and European formats. It fails an incomplete address on purpose — telling you that you comply when you might not is the one error here that carries legal consequences.","parameters":null},{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"required","rationale":"A valid physical postal address is mandatory in every commercial email, and cold outreach is commercial however personal it reads — CAN-SPAM sets no volume floor (15 U.S.C. §7704(a)(5)(A)(iii), 16 CFR §316.2(p)). It is also the requirement senders omit most often.\n\nUnlike a machine-readable unsubscribe, an address costs you nothing: there is no evidence it affects deliverability or reply rate, and it signals a real business behind the message. A street address, a PO box, or a registered private mailbox all satisfy the law.\n\nThe check anchors on a postcode that agrees with its region, and recognises US, UK, Canadian and European formats. It fails an incomplete address on purpose — telling you that you comply when you might not is the one error here that carries legal consequences.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"A valid physical postal address is mandatory in every commercial email — CAN-SPAM 15 U.S.C. §7704(a)(5)(A)(iii), implemented at 16 CFR §316.2(p). Each non-compliant email is a separate violation, currently up to $53,088, so a single blast to a 50,000-person list is not one mistake.\n\nThe check anchors on a postcode that agrees with its region rather than on a street-address pattern, and recognises US, UK, Canadian, military and European formats. A street address, a PO box, or a registered private mailbox all satisfy the law. Measured against 1,000 real marketing emails it finds an address in about 90%, with the remainder hand-audited as genuine absences.\n\nIt fails an incomplete address on purpose: telling you that you comply when you might not is the one error here that carries legal consequences. Optionally, configure your own sending address and a store locator or event venue in the body will no longer be mistaken for it.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"A valid physical postal address is mandatory in every commercial email — CAN-SPAM 15 U.S.C. §7704(a)(5)(A)(iii), implemented at 16 CFR §316.2(p). Each non-compliant email is a separate violation, currently up to $53,088, so a single blast to a 50,000-person list is not one mistake.\n\nThe check anchors on a postcode that agrees with its region rather than on a street-address pattern, and recognises US, UK, Canadian, military and European formats. A street address, a PO box, or a registered private mailbox all satisfy the law. Measured against 1,000 real marketing emails it finds an address in about 90%, with the remainder hand-audited as genuine absences.\n\nIt fails an incomplete address on purpose: telling you that you comply when you might not is the one error here that carries legal consequences. Optionally, configure your own sending address and a store locator or event venue in the body will no longer be mistaken for it.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"recommended","rationale":"Reports whether your email carries a physical postal address. It reports rather than blocks, because most transactional mail genuinely does not need one — and yours may well be fine without it.\n\n**The exemption is real.** CAN-SPAM's postal-address duty applies to *commercial* email, and a message confirming a transaction the recipient agreed to is excluded (15 U.S.C. §7702(2)(B), §7704(a)(5)(A)(iii)). Across real transactional mail we found about 99% qualifying cleanly. Roughly half of senders include no address, and most of them are compliant.\n\n**The exemption is also per-message, and easy to lose without noticing.** Under 16 CFR §316.3 your receipt becomes commercial if a recipient reading the subject line would think it contains an ad, **or** if the transactional content is not at the beginning of the body. A promotional nav bar above the order summary is enough — we found a receipt sitting behind a `COUPONS · NEW TOOLS · DEALS` strip. Whoever added that block changed the email's legal status, and penalties run to $53,088 per email.\n\nSo the question to ask is not \"am I transactional?\" but \"is there promotional content in here, and is my receipt still at the top?\" If there is promotional content, treat the message as marketing — it owes an address, an unsubscribe, and the rest of that standard. Note also that Canada does not offer this exemption: CASL's transactional carve-out removes only the *consent* requirement, and its identification rules still ask for a mailing address.\n\nOne reason to include an address even when exempt: transactional email is the most impersonated mail there is, and a real postal address is a trust signal a phishing copy of your order confirmation usually will not carry.\n\nThe 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.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"recommended","rationale":"Reports whether your email carries a physical postal address. It reports rather than blocks, because most transactional mail genuinely does not need one — and yours may well be fine without it.\n\n**The exemption is real.** CAN-SPAM's postal-address duty applies to *commercial* email, and a message confirming a transaction the recipient agreed to is excluded (15 U.S.C. §7702(2)(B), §7704(a)(5)(A)(iii)). Across real transactional mail we found about 99% qualifying cleanly. Roughly half of senders include no address, and most of them are compliant.\n\n**The exemption is also per-message, and easy to lose without noticing.** Under 16 CFR §316.3 your receipt becomes commercial if a recipient reading the subject line would think it contains an ad, **or** if the transactional content is not at the beginning of the body. A promotional nav bar above the order summary is enough — we found a receipt sitting behind a `COUPONS · NEW TOOLS · DEALS` strip. Whoever added that block changed the email's legal status, and penalties run to $53,088 per email.\n\nSo the question to ask is not \"am I transactional?\" but \"is there promotional content in here, and is my receipt still at the top?\" If there is promotional content, treat the message as marketing — it owes an address, an unsubscribe, and the rest of that standard. Note also that Canada does not offer this exemption: CASL's transactional carve-out removes only the *consent* requirement, and its identification rules still ask for a mailing address.\n\nOne reason to include an address even when exempt: transactional email is the most impersonated mail there is, and a real postal address is a trust signal a phishing copy of your order confirmation usually will not carry.\n\nThe 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.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"recommended","rationale":"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.\n\n**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.\n\n**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.\n\nSo 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.\n\nOne 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.\n\nThe 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.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"recommended","rationale":"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.\n\n**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.\n\n**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.\n\nSo 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.\n\nOne 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.\n\nThe 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.","parameters":null}],"runStats":{"runCount":150,"failureRate":0.7333333333333333,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-physical-address-present","slug":"physical-address-included","aka":["postal address","CAN-SPAM address","mailing address in footer","sender address"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"legal-privacy-compliance","detects":["a commercial send with no postal address","a recipient's own shipping address mistaken for the sender's","an address dropped from an inherited footer"],"commonlyPairedWith":["email-unsubscribe-present","email-footer-complete","email-link-integrity"],"triggersWhen":["a commercial or marketing send goes out","a company address or entity changes","a legal or compliance review is scheduled"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on commercial mail to US recipients, where CAN-SPAM requires the sender's physical postal address in the message, and on Canadian sends under CASL. It belongs on the delivered message rather than the template, because the address usually lives in an inherited footer block — the part most likely to be carried forward from an old campaign and least likely to be re-read. Detection is postcode-anchored and uses postal addressing standards, so a real address counts in whatever format your footer writes it.","whenNotToUse":"Do not run it on transactional mail, which is exempt from the requirement — a receipt or password reset with no postal address is not a defect, and failing it produces compliance noise rather than compliance. Senders operating only under regimes that do not mandate an in-message address, such as UK PECR or the Australian Spam Act, should disable the check rather than configure it. Check the purpose of the mail before including it: the statute distinguishes commercial solicitation from service messages, and so should your audit set.","failureMeaning":"A failure means no sender postal address was found in the message. For commercial mail to US recipients that is a direct statutory exposure, and because footers are inherited it is rarely limited to the campaign you audited — one failure usually describes a family of templates. A subtler variant is worth knowing about: mail that contains the *recipient's* address, such as a shipping confirmation, can look addressed while carrying nothing about the sender, which is why recipient-address labels are recognised and excluded rather than counted.","thresholdRationale":"Three parameters carry the check. `expectedAddressCountries` defaults to `[\"US\"]` and selects which country anchor rules run, because only the US and Canada mandate an in-message address. `senderPostalAddress` defaults to empty, which falls back to presence-only detection — the statute requires the *sender's* address, not merely an address, and without knowing yours the check can only confirm that one is there. `recipientAddressLabels` defaults to the common shipping and billing labels so a recipient's own address is not mistaken for the sender's.","customWhenWarranted":"Set `senderPostalAddress` when you want the strong form of the check: with your real address supplied, a footer carrying somebody else's address, or a stale address from a previous office, fails instead of passing. Set `expectedAddressCountries` when you send from or to Canada, so CASL's anchors run alongside or instead of the US ones. Extend `recipientAddressLabels` if your templates label recipient addresses in wording the defaults do not cover, or in a language other than English.","customWhenToStayStandard":"Stay with presence-only detection while your address is genuinely in flux — mid-move, mid-restructure — because a check configured to an address you are about to leave will fail correct mail. Keep the default country list if you send only to US recipients, since adding anchors for regimes you are not subject to only widens what counts as a pass. If your mail is transactional, the right answer is not a narrower configuration but leaving the check out.","customTradeoffs":"Supplying `senderPostalAddress` is the strictest and therefore the most maintenance-sensitive setting: the moment your registered address changes, correct mail starts failing until someone updates the value, and the temptation is to clear it rather than correct it. Adding countries widens the set of formats that satisfy the check, which can let an address that is valid somewhere pass where you needed one valid locally. Extending recipient labels reduces false positives but each addition is also a phrase the check will now decline to count, so an over-broad label list can hide a genuinely missing sender address.","customGovernanceNotes":"The Standard configuration transcribes what the statute and postal standards require rather than what any organisation prefers, which is why presence-only is the default and country anchors are explicit. A Custom configuration — especially your own postal address — is legal information and should come from whoever owns the entity's registered details, not from a marketing template. Because this check's output is the kind of thing that ends up in a compliance file, record when the address value was last confirmed.","customExamples":"A US company sets `senderPostalAddress` to its registered office address, upgrading the check from \"an address is present\" to \"our address is present\" and catching footers still showing a previous office. A sender with Canadian subscribers sets `expectedAddressCountries` to `[\"US\", \"CA\"]` so CASL anchors run and Canadian-format addresses are recognised properly. An ecommerce brand whose confirmation templates print delivery details adds its own wording to `recipientAddressLabels`, so the buyer's address is never mistaken for the sender's when the footer block is missing.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-physical-address-present"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-physical-address-present","parameters":{"expectedAddressCountries":["US"],"senderPostalAddress":"","recipientAddressLabels":["ship to","shipping address","deliver to","delivery address","bill to","billing address","sold to","your address"]}}]},"defaultClients":null},{"modelVersion":1,"id":"email-plaintext-alt-present","slug":"plain-text-version-included","name":"Plain-text alternative part present","aka":["text part","multipart alternative","HTML-only email","plain text alternative"],"subjectType":"email","category":"deliverability","severity":"required","description":"Parse MIME structure. Fail when not multipart/alternative or text/plain part is absent/empty.","executionKind":"functional","checkLabel":"Plain-text version included","checkValue":"A plain-text alternative improves spam-filter reputation and accessibility. HTML-only email is a deliverability risk with some providers and unreadable in text-only clients.","hasCustomConfig":false,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":null,"parameters":[],"standards":[{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"Send both an HTML and a plain-text part. SpamAssassin has a named rule for missing one — MIME_HTML_ONLY — scoring between 0.723 and 1.2 against a spam threshold of 5.0. You are spending 15–24% of your spam budget before you write a word, and 24.1% of real marketing email is paying it right now.\n\nNothing here is illegal, and no mailbox provider mandates it: Gmail's bulk sender rules cover authentication, one-click unsubscribe and complaint rate, not multipart. The exposure is concentrated where SpamAssassin actually runs — corporate gateways, self-hosted mail and B2B filters. If you mail businesses this matters considerably more than if you mail consumers.\n\nIt blocks because the fix is one toggle in every major ESP, and there is no reason to carry a permanent penalty you can remove in a second.\n\nThe check reads your MIME structure rather than counting characters. That distinction is load-bearing: email parsers synthesise plain text from the HTML, so a message shipping no plain-text part still appears to have tens of thousands of characters of it.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"Send both an HTML and a plain-text part. SpamAssassin has a named rule for missing one — MIME_HTML_ONLY — scoring between 0.723 and 1.2 against a spam threshold of 5.0. You are spending 15–24% of your spam budget before you write a word, and 24.1% of real marketing email is paying it right now.\n\nNothing here is illegal, and no mailbox provider mandates it: Gmail's bulk sender rules cover authentication, one-click unsubscribe and complaint rate, not multipart. The exposure is concentrated where SpamAssassin actually runs — corporate gateways, self-hosted mail and B2B filters. If you mail businesses this matters considerably more than if you mail consumers.\n\nIt blocks because the fix is one toggle in every major ESP, and there is no reason to carry a permanent penalty you can remove in a second.\n\nThe check reads your MIME structure rather than counting characters. That distinction is load-bearing: email parsers synthesise plain text from the HTML, so a message shipping no plain-text part still appears to have tens of thousands of characters of it.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"required","rationale":"Every email you send should carry a plain-text version alongside the HTML one. This confirms yours does, and that it is not empty.\n\nIt matters more for transactional mail than for a campaign, because of what transactional mail carries. A verification code, an order number, a tracking link — these are the payload, not the packaging. Anywhere the HTML does not render, a plain-text part is the difference between the recipient getting what they asked for and being stuck: notification previews, smartwatches, plain-text-only corporate clients, and screen readers all read it. We found real login-verification emails shipping with no plain-text part at all, which means the code exists only inside markup the reader may never see. About a third of the transactional senders we measured have this defect.\n\nIt 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.\n\nRuns with no configuration. A quick 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.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"required","rationale":"Every email you send should carry a plain-text version alongside the HTML one. This confirms yours does, and that it is not empty.\n\nIt matters more for transactional mail than for a campaign, because of what transactional mail carries. A verification code, an order number, a tracking link — these are the payload, not the packaging. Anywhere the HTML does not render, a plain-text part is the difference between the recipient getting what they asked for and being stuck: notification previews, smartwatches, plain-text-only corporate clients, and screen readers all read it. We found real login-verification emails shipping with no plain-text part at all, which means the code exists only inside markup the reader may never see. About a third of the transactional senders we measured have this defect.\n\nIt 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.\n\nRuns with no configuration. A quick 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.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"required","rationale":"Confirms your email carries a plain-text version alongside the HTML one, and that it is not empty.\n\nIt 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.\n\nAcross 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.\n\nIt 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.\n\nRuns 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.\n\n⚠ **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.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"required","rationale":"Confirms your email carries a plain-text version alongside the HTML one, and that it is not empty.\n\nIt 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.\n\nAcross 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.\n\nIt 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.\n\nRuns 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.\n\n⚠ **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.","parameters":null}],"runStats":{"runCount":150,"failureRate":0.9,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-plaintext-alt-present","slug":"plain-text-version-included","aka":["text part","multipart alternative","HTML-only email","plain text alternative"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"deliverability","detects":["an HTML-only message with no text part","a text alternative dropped by the sending platform","mail unreadable in text-only clients"],"commonlyPairedWith":["email-gmail-clip-size","email-from-domain-match","email-unsubscribe-present"],"triggersWhen":["an ESP or sending platform is changed","a template is built or imported","deliverability is being investigated"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on any bulk or commercial send, and especially after changing how mail is generated. A missing text part is a classic platform-level defect: it is invisible in every preview, costs nothing to fix, and is one of the cheap signals spam filters weigh against you. Because it reads the delivered message structure, one audited send tells you whether the whole sending path is producing a proper multipart message or not.","whenNotToUse":"Skip it where a text alternative is genuinely irrelevant to the audit — internal notifications to a known client, machine-to-machine mail nobody reads in a mail client. It is also not a judgement of the text part's *quality*: a message carrying an empty or auto-stripped text version passes the structural question while still being useless to a human reading it. If the concern is that your text part is a garbled dump of the HTML, that needs a read rather than a check.","failureMeaning":"A failure means the message went out as HTML only, with no plain-text alternative. Some providers treat that as a mild spam signal, so the cost is paid in reputation across your sending rather than in this one campaign, and it accumulates. It also leaves the message unreadable to anyone using a text-only client or a screen reader configured to prefer the text part, which is a small audience with a total failure rather than a large one with an inconvenience.","thresholdRationale":"This check has no tunable thresholds. It is a structural presence check on the delivered message: the plain-text alternative is either part of the message or it is not, and there is no number or list to calibrate. Nothing about the answer varies by brand or campaign, which is why the check is entirely zero-configuration.","customWhenWarranted":"Never — this check has no Custom Parameters, so there is nothing to warrant. Its public custom page redirects to the Standard page.","customWhenToStayStandard":"Always, since Standard is the only behaviour available. There are no override knobs, and the only decision left is whether the check belongs in the set for the kind of mail you are auditing.","customTradeoffs":"None exist, because no value can be changed. The only related cost is a false sense of completeness: a passing verdict confirms a text part is present, not that its contents are readable.","customGovernanceNotes":"Whether a message should carry a text alternative is settled by mail standards and provider behaviour rather than by any organisation's policy, so there is nothing here for a governance process to own. What is worth governing is the sending platform's configuration, since that is where the answer is actually determined.","customExamples":"There are no override examples, as the check exposes no parameters. The useful comparison is operational: teams that fail this usually fix it once at the platform and never see it again.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-plaintext-alt-present"]},"agentContractCustom":null,"defaultClients":null},{"modelVersion":1,"id":"email-preheader","slug":"preview-text-is-intentional","name":"Preheader / inbox preview text intentional","aka":["preheader","preview text","inbox preview","snippet text"],"subjectType":"email","category":"content-quality","severity":"recommended","description":"The inbox preview snippet must be intentional: no boilerplate (\"view in browser\", unsubscribe) or leaked merge tokens next to the subject line, required preheader content present within the visible window, and no preview-garbling defects in the source.","executionKind":"functional","checkLabel":"Preview text is intentional","checkValue":"The preheader is the line beside your subject in the inbox, and when it is not set the client takes whatever comes first — usually “View in browser” or an unsubscribe link. It is the most-read copy in the send and the most often left to chance.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-preheader/custom","parameters":[{"name":"requiredPreheaderContent","severity":"required","standardDefault":"","formatSummary":"optional-string"},{"name":"prohibitedPreviewPatterns","severity":"required","standardDefault":["view (this |the )?(e-?mail|message|it)? ?(in|on) ?(your )?(web ?)?browser","trouble (viewing|displaying)","sent in html only","online version","unsubscribe","lorem ipsum"],"formatSummary":"regex-pattern-list"},{"name":"maxPreheaderChars","severity":"required","standardDefault":130,"formatSummary":"positive-integer"},{"name":"previewWindowChars","severity":"required","standardDefault":90,"formatSummary":"positive-integer"}],"standards":[{"setId":"cold-outreach-standard","setName":"Cold outreach — standard","category":"cold-outreach","tier":"standard","severity":"recommended","rationale":"The text beside your subject line in the inbox is the second thing a prospect reads, and in a plain email it is simply your opening sentence. This checks that preview is not working against you: no leftover \"view in browser\" boilerplate, no merge token that failed to resolve, no bare URL, nothing cut off mid-thought.\n\nIt does **not** ask you to add a hidden preheader block. That is a marketing-automation pattern a genuine one-to-one email would not have, and adding one earns you nothing here.","parameters":null},{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"recommended","rationale":"The text beside your subject line in the inbox is the second thing a prospect reads, and in a plain email it is simply your opening sentence. This checks that preview is not working against you: no leftover \"view in browser\" boilerplate, no merge token that failed to resolve, no bare URL, nothing cut off mid-thought.\n\nIt does **not** ask you to add a hidden preheader block. That is a marketing-automation pattern a genuine one-to-one email would not have, and adding one earns you nothing here.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"The text beside your subject line is the third thing a reader sees, after who it is from and what it says, and it is the most commonly wasted asset in marketing email.\n\nThis computes what your preview will actually say and checks it is not working against you: no \"view this email in your browser\" boilerplate leading the preview, no merge token that failed to resolve, no bare URL or undecoded entity garbage, nothing cut off mid-thought.\n\nIt has no opinion on whether your preheader is any good. It fails only on defects, and it passes every legitimate choice — including having no hidden preheader at all, since leading with a visible headline is a sanctioned pattern rather than a mistake.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"The text beside your subject line is the third thing a reader sees, after who it is from and what it says, and it is the most commonly wasted asset in marketing email.\n\nThis computes what your preview will actually say and checks it is not working against you: no \"view this email in your browser\" boilerplate leading the preview, no merge token that failed to resolve, no bare URL or undecoded entity garbage, nothing cut off mid-thought.\n\nIt has no opinion on whether your preheader is any good. It fails only on defects, and it passes every legitimate choice — including having no hidden preheader at all, since leading with a visible headline is a sanctioned pattern rather than a mistake.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"recommended","rationale":"The line of text beside your subject in the inbox is the second thing your customer reads, and for transactional mail it is often all they need: *\"Order #4821 has been delivered\"* answers the question without them opening anything.\n\nThis predicts what that line will actually show and checks that your own boilerplate has not got in front of it. The common failure is a \"View in browser\" link sitting at the top of the template, which then becomes the first thing in the preview — we have found it 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.\n\n**You almost certainly do not need to add a hidden preheader block.** Fewer than one in ten of the real transactional emails we checked uses one, and they do not need it — the first visible line of a shipping notice or a receipt is already the confirmation. If your preview is wrong, the fix is usually to move boilerplate below your opening line, not to bolt a preheader on top.\n\nRuns with no configuration. One thing it does not check: whether your preview is *appropriate* to show. We have seen account emails put the recipient's own email address in the preview, where anyone glancing at their phone can read it — this check will not flag that.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"recommended","rationale":"The line of text beside your subject in the inbox is the second thing your customer reads, and for transactional mail it is often all they need: *\"Order #4821 has been delivered\"* answers the question without them opening anything.\n\nThis predicts what that line will actually show and checks that your own boilerplate has not got in front of it. The common failure is a \"View in browser\" link sitting at the top of the template, which then becomes the first thing in the preview — we have found it 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.\n\n**You almost certainly do not need to add a hidden preheader block.** Fewer than one in ten of the real transactional emails we checked uses one, and they do not need it — the first visible line of a shipping notice or a receipt is already the confirmation. If your preview is wrong, the fix is usually to move boilerplate below your opening line, not to bolt a preheader on top.\n\nRuns with no configuration. One thing it does not check: whether your preview is *appropriate* to show. We have seen account emails put the recipient's own email address in the preview, where anyone glancing at their phone can read it — this check will not flag that.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"recommended","rationale":"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.\n\nThis 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.\n\n**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.\n\nRuns 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.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"recommended","rationale":"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.\n\nThis 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.\n\n**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.\n\nRuns 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.","parameters":null}],"runStats":{"runCount":14,"failureRate":0.07142857142857142,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-preheader","slug":"preview-text-is-intentional","aka":["preheader","preview text","inbox preview","snippet text"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"content-quality","detects":["no preheader set","so the client picks its own","'View in browser' or an unsubscribe link used as preview text","preview text too long to be read where it appears"],"commonlyPairedWith":["email-subject-line-length","email-subject-content","email-no-placeholder-text"],"triggersWhen":["a campaign is built or its subject is edited","a template is imported or reused","inbox performance is being reviewed"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on every campaign where getting opened is the point. The preheader is the line beside your subject in the inbox, and when it is not set the client takes whatever text comes first — usually \"View in browser\" or an unsubscribe link. It is the most-read copy in the send and the most often left to chance, so it is worth checking on the delivered message rather than trusting the editor's preview field.","whenNotToUse":"Skip it on transactional mail whose preview line is inherently functional and unremarkable, and on operational notices where the subject alone carries everything the recipient needs. It is also not a judgement about whether the preheader is *persuasive*, only whether it is present, intentional and sized to be read. If your ESP composes preview text in a way the delivered message does not reveal, verify with a real send rather than assuming the check can see a field it never receives.","failureMeaning":"A failure means the preview line is missing, is one of the phrases that indicate the client fell back to boilerplate, or is longer than the window that will actually display it. In inbox terms that means the second-most prominent piece of copy in your send is either wasted on a utility link or truncated mid-thought. Because it comes from the top of the message body, a failure usually points at template structure rather than at the campaign copy.","thresholdRationale":"Four parameters carry the check. `requiredPreheaderContent` is empty by default, so no particular wording is demanded. `prohibitedPreviewPatterns` holds the phrases that betray a fallback — variants of \"view this email in your browser\", \"trouble viewing\", \"sent in html only\", \"online version\", plus `unsubscribe` and `lorem ipsum`. `maxPreheaderChars` defaults to `130`, the practical ceiling before clients stop carrying it, and `previewWindowChars` to `90`, the narrower span that is actually read — two numbers because the limit you may write to and the span you should front-load into are different questions.","customWhenWarranted":"Set `requiredPreheaderContent` when a campaign family must always carry a specific phrase in the preview — a legally required qualifier, a programme name, an offer identifier. Extend `prohibitedPreviewPatterns` when your templates have their own boilerplate first line that the defaults do not know, such as a mandatory disclaimer or a mirror-page label. Adjust `previewWindowChars` when you know your audience's dominant client and want the front-loading window to match what it really shows.","customWhenToStayStandard":"Keep the defaults when your concern is simply that preview text exists and is not boilerplate, which is what most senders need. Leave `requiredPreheaderContent` empty unless a phrase is genuinely mandatory, because demanding fixed wording in the most valuable line in the inbox is a heavy constraint on copy. Keep both numbers if you have a mixed audience, since 130 and 90 are chosen to be reasonable across clients rather than tuned to one.","customTradeoffs":"Requiring fixed content trades open-rate flexibility for consistency, and every required phrase consumes part of a window that is already short. Extending the prohibited list risks failing legitimate copy — a campaign that genuinely offers an online version early in the body will trip a pattern written to catch boilerplate. Tightening `previewWindowChars` produces more failures on perfectly deliverable preheaders, which is useful only if your team accepts front-loading as a rule rather than a suggestion.","customGovernanceNotes":"The Standard configuration is written from observed client behaviour and from the boilerplate that real templates actually leak, which is why the required-content field is empty and the prohibited list is not. Custom values are campaign or brand policy and belong with whoever owns campaign standards; a required phrase in particular should be traceable to the obligation or programme that demands it. Review the numbers when your audience's client mix shifts, since both are claims about where a reader stops reading.","customExamples":"A financial services sender sets `requiredPreheaderContent` to the qualifier its compliance team requires in the preview line, so a campaign that omits it fails before sending. A team whose templates open with a mandatory legal disclaimer adds that phrasing to `prohibitedPreviewPatterns`, catching sends where the disclaimer became the preview text. A mobile-dominant consumer brand lowers `previewWindowChars` to `60` to force sharper front-loading, accepting more findings in exchange for preview lines that are read in full on a phone.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-preheader"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-preheader","parameters":{"requiredPreheaderContent":"","prohibitedPreviewPatterns":["view (this |the )?(e-?mail|message|it)? ?(in|on) ?(your )?(web ?)?browser","trouble (viewing|displaying)","sent in html only","online version","unsubscribe","lorem ipsum"],"maxPreheaderChars":130,"previewWindowChars":90}}]},"defaultClients":null},{"modelVersion":1,"id":"email-subject-content","slug":"subject-line-is-the-approved-one","name":"Subject line matches approved content","aka":["approved subject","subject verification","subject line approval","subject drift"],"subjectType":"email","category":"content-quality","severity":"optional","description":"Customer-configured subject verification: the received subject must exactly match an approved subject, contain required phrases, avoid prohibited patterns, and match a required pattern when configured. Skips until approvedSubjects is configured. See docs/EMAIL-SUBJECT-CONTENT.md.","executionKind":"functional","checkLabel":"Subject line is the approved one","checkValue":"The subject is the one line that has to clear legal, brand and campaign approval, and the one most often edited after it did. This holds what actually shipped against what was approved.","hasCustomConfig":true,"requiresConfiguration":true,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-subject-content/custom","parameters":[{"name":"approvedSubjects","severity":"required","standardDefault":[],"formatSummary":"non-empty-string-array"},{"name":"requiredSubjectPhrases","severity":"recommended","standardDefault":[],"formatSummary":"non-empty-string-array"},{"name":"prohibitedSubjectPatterns","severity":"recommended","standardDefault":[],"formatSummary":"regex-pattern-list"},{"name":"requiredSubjectPattern","severity":"required","standardDefault":"","formatSummary":"optional-string"}],"standards":[{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"recommended","rationale":"Verifies that the subject line which actually arrived is the one you approved.\n\nFour criteria, each of them yours to define: an exact match against approved subjects, phrases that must appear, patterns that must not — spam triggers, banned claims, [DRAFT] markers and merge-tag leftovers — and a pattern your campaign naming convention has to satisfy.\n\nThis is the check that catches a draft subject line shipping to the list, or a campaign going out under last month's approved copy. It is also the only place you can encode your own prohibited-word policy rather than inherit ours.\n\nEvery criterion requires you to supply the answer, so until you configure it the check is skipped rather than failed. Verified accurate in both directions across 1,200 real emails, including 440 whose subject lines were encoded and had to be decoded before they could be matched.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"recommended","rationale":"Verifies that the subject line which actually arrived is the one you approved.\n\nFour criteria, all of them yours to define: an exact match against approved subjects, phrases that must appear, patterns that must not — draft markers, merge-tag leftovers, banned claims — and a pattern your naming convention has to satisfy.\n\nFor transactional mail the last one is the useful one. Your subject is a label your customer scans for and searches later, so a rule like \"every shipping notice subject must contain the order number\" is worth enforcing — and this is the only place you can enforce it. It also catches a draft subject shipping from a live template, and lets you encode your own prohibited-word policy rather than inherit ours.\n\nEvery criterion requires you to supply the answer, so until you configure it the check is skipped rather than failed, and it is not charged. Verified accurate in both directions across 1,200 real emails, including 440 whose subject lines were encoded and had to be decoded before they could be matched.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"recommended","rationale":"Verifies that the subject line which actually arrived is the one you approved.\n\nFour criteria, all of them yours to define: an exact match against approved subjects, phrases that must appear, patterns that must not — draft markers, merge-tag leftovers, banned claims — and a pattern your naming convention has to satisfy.\n\nFor operational mail the required-phrase and pattern criteria are the useful ones, and they are the only place you can enforce a rule like \"every maintenance notice subject must name the affected region\" or \"every security notice must contain the word Security\". Service notices are the mail most likely to be sent under pressure by whoever is on call, and a subject convention is the cheapest guard-rail there is. It also catches a draft subject shipping from a live template.\n\nEvery criterion requires you to supply the answer, so until you configure it the check is skipped rather than failed, and it is not charged. Verified accurate in both directions across 1,200 real emails, including 440 whose subject lines were encoded and had to be decoded before they could be matched.","parameters":null}],"runStats":null,"content":{"id":"email-subject-content","slug":"subject-line-is-the-approved-one","aka":["approved subject","subject verification","subject line approval","subject drift"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"content-quality","detects":["a subject edited after approval","a required disclosure phrase missing from the subject","prohibited wording reaching the inbox"],"commonlyPairedWith":["email-subject-line-length","email-preheader","email-no-placeholder-text"],"triggersWhen":["a campaign subject is approved and then edited","a regulated or legally reviewed send goes out","an AI-generated send is gated before delivery"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this when the subject is something that had to be approved, and therefore something that can drift. The subject is the one line that has to clear legal, brand and campaign review, and the one most often edited after it did — usually in a hurry, usually by someone who was not in the review. It is also the cleanest gate for AI-generated sends, where a plausible rewrite of an approved line is exactly the failure you cannot spot by reading.","whenNotToUse":"Skip it when there is no approved subject to hold the send against, which is most routine marketing where the subject is written and sent in one motion. It is also not a length check — a subject can be exactly the approved one and still be cut off in the inbox, which is the subject-length check's question. And it cannot judge quality: an approved subject that performs badly passes, because approval is the standard being enforced, not effectiveness.","failureMeaning":"A failure means the delivered subject is not the approved one, or breaks a rule you set about its contents — a required phrase absent, a prohibited pattern present, or a required shape unmatched. On a regulated send that is a compliance exposure rather than a copy defect, since the subject is frequently the line a disclosure obligation attaches to. In practice the most common cause is an edit made after sign-off, which is precisely the event the check exists to catch.","thresholdRationale":"Four parameters carry the check. `approvedSubjects` defaults to an empty list at `required` severity, which is a deliberate gate: with nothing approved there is nothing to verify, so the check reports as needing configuration rather than passing vacuously. `requiredSubjectPhrases` and `prohibitedSubjectPatterns` are empty by default, adding phrase-level rules only when you set them, and `requiredSubjectPattern` is an optional expression for senders whose subjects must follow a shape rather than an exact wording.","customWhenWarranted":"Configuring this check is what switches it on, so the values are always yours. Set `approvedSubjects` for sends that went through review, and reach for `requiredSubjectPhrases` when an obligation attaches to wording rather than to the whole line — a promotional disclosure, a programme identifier, an advertising label. `prohibitedSubjectPatterns` is the right tool for wording your brand or legal team has ruled out, and `requiredSubjectPattern` suits structured subjects such as a mandatory prefix or ticket reference.","customWhenToStayStandard":"There is no meaningful Standard state to stay on, because the unconfigured default is a skip rather than a verdict. The real decision is whether to include the check at all: if your subjects are not formally approved, leave it out rather than pasting in a list you will not maintain. For the common case of wanting to know whether the subject will survive the inbox, the length check is the one you want.","customTradeoffs":"An exact approved-subject list is the strictest form and the most maintenance-hungry: every legitimate late edit becomes a failure until the list is updated, and a team that updates the list to make the check pass has inverted the control. Phrase and pattern rules are more durable but blunter, and a pattern written under pressure will eventually fail a correct subject in a way nobody can quickly explain. Prohibited patterns carry the usual over-reach risk, since a short prohibited string matches inside ordinary words.","customGovernanceNotes":"Everything here is your organisation's own policy — there is no community default for what your subject line must say — so ownership matters more than usual. The approved list should come from wherever campaign sign-off is recorded, and required or prohibited wording from legal or brand, with each rule traceable to the obligation behind it. Because the output can serve as evidence that an approved subject actually shipped, keep a record of when the list was last reconciled with the review process.","customExamples":"A regulated sender sets `approvedSubjects` to the exact lines legal signed off, so any post-approval edit fails before the send completes. An advertiser required to label promotional mail sets `requiredSubjectPhrases` to that label instead of an exact-subject list, keeping copy freedom while enforcing the obligation. A team gating AI-generated sends sets `requiredSubjectPattern` to the structure its templates must follow and `prohibitedSubjectPatterns` to the superlatives its brand guide bans, catching plausible-looking rewrites deterministically.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-subject-content"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-subject-content","parameters":{"approvedSubjects":[],"requiredSubjectPhrases":[],"prohibitedSubjectPatterns":[],"requiredSubjectPattern":""}}]},"defaultClients":null},{"modelVersion":1,"id":"email-subject-line-length","slug":"subject-line-fits-the-inbox","name":"Subject line within length limit","aka":["subject length","truncated subject","inbox preview length"],"subjectType":"email","category":"content-quality","severity":"recommended","description":"Extract Subject header; count Unicode characters; fail when count exceeds maxSubjectLength.","executionKind":"functional","checkLabel":"Subject line fits the inbox","checkValue":"Inboxes cut off long subject lines: desktop Gmail shows about 70 characters, mobile apps as few as 30–40. Staying under the limit keeps the whole subject visible.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-subject-line-length/custom","parameters":[{"name":"maxSubjectLength","severity":"required","standardDefault":60,"formatSummary":"positive-integer"}],"standards":[{"setId":"cold-outreach-standard","setName":"Cold outreach — standard","category":"cold-outreach","tier":"standard","severity":"recommended","rationale":"Mobile clients cut the subject line at 35–40 characters, and an analysis of roughly 12 million outreach emails found the 36–50 character band drew about a third more replies than very short ones. This flags subjects past 60 characters — a loose outer bound rather than the ideal, so read a pass as \"not obviously too long\" rather than \"optimal\". It cannot tell you a subject is too short or too vague; that judgement stays yours.","parameters":null},{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"recommended","rationale":"Mobile clients cut the subject line at 35–40 characters, and an analysis of roughly 12 million outreach emails found the 36–50 character band drew about a third more replies than very short ones. This flags subjects past 60 characters — a loose outer bound rather than the ideal, so read a pass as \"not obviously too long\" rather than \"optimal\". It cannot tell you a subject is too short or too vague; that judgement stays yours.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"recommended","rationale":"Mobile is now 68% of email opens, and mobile inboxes cut the subject line between roughly 28 and 50 characters — Gmail's app at about 30, an iPhone at about 41. Subject lines in the 21–40 character band see open rates near 49%, against about 39% above 60 characters.\n\nThis flags subjects past 60 characters: a loose outer bound, deliberately well above the range the data actually favours. 18% of real marketing email exceeds it.\n\nRead a pass as \"not obviously too long\" rather than \"good\". It cannot tell you a subject is vague, weak or spammy — that judgement stays yours, which is why it reports rather than blocks.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"recommended","rationale":"Mobile is now 68% of email opens, and mobile inboxes cut the subject line between roughly 28 and 50 characters — Gmail's app at about 30, an iPhone at about 41. Subject lines in the 21–40 character band see open rates near 49%, against about 39% above 60 characters.\n\nThis flags subjects past 60 characters: a loose outer bound, deliberately well above the range the data actually favours. 18% of real marketing email exceeds it.\n\nRead a pass as \"not obviously too long\" rather than \"good\". It cannot tell you a subject is vague, weak or spammy — that judgement stays yours, which is why it reports rather than blocks.","parameters":null},{"setId":"transactional-standard","setName":"Transactional email — standard","category":"transactional","tier":"standard","severity":"recommended","rationale":"Flags subject lines longer than 60 characters. For transactional mail the subject is not a headline, it is a label — the thing your customer scans for in a crowded inbox and searches for weeks later when they need the receipt.\n\nWhich is why what matters most here is *where your order number sits*, not 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 identifier is already invisible on a phone. Read a pass as \"not obviously too long\", never as \"your customer can see the order number\". Front-load it: **\"Order #4821 shipped — arriving Tuesday\"** survives the cut; **\"Your order from Acme Supply Co. has shipped, #4821\"** does not.\n\nMost transactional senders already do this well — in real mail we see the identifier survive the clip about 97% of the time. This is a cheap safety net for the few that do not, not a common failure.\n\nRuns with no configuration, and it cannot tell you a subject is too vague or too short. That judgement stays yours.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"recommended","rationale":"Flags subject lines longer than 60 characters. For transactional mail the subject is not a headline, it is a label — the thing your customer scans for in a crowded inbox and searches for weeks later when they need the receipt.\n\nWhich is why what matters most here is *where your order number sits*, not 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 identifier is already invisible on a phone. Read a pass as \"not obviously too long\", never as \"your customer can see the order number\". Front-load it: **\"Order #4821 shipped — arriving Tuesday\"** survives the cut; **\"Your order from Acme Supply Co. has shipped, #4821\"** does not.\n\nMost transactional senders already do this well — in real mail we see the identifier survive the clip about 97% of the time. This is a cheap safety net for the few that do not, not a common failure.\n\nRuns with no configuration, and it cannot tell you a subject is too vague or too short. That judgement stays yours.","parameters":null},{"setId":"operational-standard","setName":"Operational email — standard","category":"operational","tier":"standard","severity":"recommended","rationale":"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.\n\nWhich 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\".\n\nThe 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.\n\nMost 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.\n\nRuns 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.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"recommended","rationale":"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.\n\nWhich 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\".\n\nThe 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.\n\nMost 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.\n\nRuns 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.","parameters":null}],"runStats":{"runCount":150,"failureRate":0.1,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-subject-line-length","slug":"subject-line-fits-the-inbox","aka":["subject length","truncated subject","inbox preview length"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"content-quality","detects":["a subject line long enough to be cut off in the inbox","the offer landing past the visible window","subject drift after an editing pass"],"commonlyPairedWith":["email-preheader","email-subject-content","email-no-placeholder-text"],"triggersWhen":["a campaign subject is written or edited","a personalisation token is added to the subject","an A/B subject variant is created"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on every campaign where the subject is doing sales work, which is most marketing and all cold outreach. It is most useful when subjects carry personalisation, because a token that reads as fifteen characters in the editor becomes thirty for some recipients and pushes the point of the line out of view. Include it whenever subject variants are being tested, since variants are written quickly and length is the thing nobody re-measures.","whenNotToUse":"Skip it for transactional mail whose subject is a functional label — an order number, a reset notice — where being cut off costs nothing because the recipient already knows what the message is. It is also the wrong check if your question is whether the subject is *good*; length is a mechanical constraint, not a judgement about the copy. And if you are targeting a specific client's exact rendering, note that this measures characters rather than pixels, so a wide-character subject can still be cut early.","failureMeaning":"A failure means the subject exceeds the length that reliably survives the inbox, and it reports the measured length. Inboxes cut long subjects at different points — desktop Gmail shows roughly seventy characters, mobile apps as few as thirty to forty — so a long subject is not invisible, it is unpredictable. The practical consequence is that whatever you put at the end of the line is read by some recipients and not others, and the ones on mobile are usually the majority.","thresholdRationale":"One parameter carries the check: `maxSubjectLength`, defaulting to `60` characters. Sixty sits deliberately below desktop Gmail's roughly seventy, because the boundary that matters is the mobile one and most opens happen there — a subject that fits sixty survives nearly everywhere, while one tuned to seventy is cut on phones. It is a single one-sided limit rather than a range, since there is no failure mode in a subject being short.","customWhenWarranted":"Override `maxSubjectLength` when you know your audience's clients better than a general default can. A sender whose analytics show overwhelmingly mobile opens might tighten it to forty, which is the honest limit for those apps and produces subjects that never truncate for the people actually reading. A team with desktop-heavy business readership might raise it toward seventy, accepting mobile truncation as a considered choice rather than an accident.","customWhenToStayStandard":"Stay on sixty when you do not have reliable client mix data, because it is the value that is least wrong across a mixed audience. Keep the default when several teams or brands share the check and you want their results comparable. If you are tempted to raise the limit to make a specific subject pass, that is a signal to edit the subject rather than the threshold — the inbox does not read your configuration.","customTradeoffs":"Tightening to a mobile-honest number produces far more failures and real editorial constraint, which is the point but also the cost: copywriters have to work inside it, and a limit nobody accepts gets ignored. Raising the value quietly reintroduces the failure it was meant to catch, since a passing verdict then means \"fits some inboxes\" rather than most. Because the measurement is characters rather than rendered width, a very tight custom limit still cannot promise a specific client's exact cut point.","customGovernanceNotes":"The Standard sixty is a conservative reading of published client behaviour, chosen so a pass means something without configuration. A Custom limit is a claim about your own audience and should be sourced from your open data, with a note of when it was measured — client mix shifts, and a limit set from three-year-old analytics is a guess wearing evidence's clothing. Keep it with the rest of your campaign standards so copywriters see it before they write, not after they fail.","customExamples":"A consumer brand whose opens are 80% mobile sets `maxSubjectLength` to `40`, forcing front-loaded subjects that survive the smallest window its real audience uses. A B2B sender with desktop-heavy readership raises it to `70`, matching desktop Gmail and accepting truncation on phones as a deliberate trade. A team running heavy personalisation keeps `60` but measures with the longest realistic token value, so the limit is tested against the worst case rather than the average recipient.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-subject-line-length"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-subject-line-length","parameters":{"maxSubjectLength":60}}]},"defaultClients":null},{"modelVersion":1,"id":"email-tracking-integrity","slug":"tracking-parameters-intact","name":"Tracking parameters present, well-formed, and preserved","aka":["UTM hygiene","attribution check","tracking parameters","campaign tagging"],"subjectType":"email","category":"link-functional-testing","severity":"recommended","description":"Tracking on email links must be intact: no unresolved merge tags, empty UTM values, typo'd utm_ keys, duplicate parameters, ad-platform click-ids, or raw email addresses in query strings. When tracked domains are configured, marketing links must carry the required parameters (UTM or custom names), match the required link pattern, and keep their parameters through redirect chains; a required tracking pixel can also be enforced. See docs/EMAIL-TRACKING-INTEGRITY.md.","executionKind":"functional","checkLabel":"Tracking parameters intact","checkValue":"Two things hide in a link’s query string. One is your attribution: a parameter that shipped unresolved, got dropped through a redirect, or names a channel Google does not recognise means the campaign has no attribution when someone asks what it earned — and that question is always asked after the send. The other is your subscribers: an email address written into a link travels into browser history, server logs and the next site’s analytics, and no send can be recalled once it has gone.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-tracking-integrity/custom","parameters":[{"name":"trackedLinkDomains","severity":"recommended","standardDefault":[],"formatSummary":"domain-list"},{"name":"requiredTrackingParams","severity":"recommended","standardDefault":[],"formatSummary":"non-empty-string-array"},{"name":"requiredUtmMedium","severity":"required","standardDefault":"","formatSummary":"optional-string"},{"name":"requiredLinkPattern","severity":"required","standardDefault":"","formatSummary":"optional-string"},{"name":"requiredTrackingPixelPattern","severity":"required","standardDefault":"","formatSummary":"optional-string"},{"name":"enforceGa4Channels","severity":"recommended","standardDefault":false,"formatSummary":"boolean-flag"},{"name":"allowedCustomUtmParams","severity":"recommended","standardDefault":[],"formatSummary":"non-empty-string-array"},{"name":"allowedUtmSources","severity":"recommended","standardDefault":[],"formatSummary":"non-empty-string-array"},{"name":"allowedUtmMediums","severity":"recommended","standardDefault":[],"formatSummary":"non-empty-string-array"}],"standards":[{"setId":"cold-outreach-standard","setName":"Cold outreach — standard","category":"cold-outreach","tier":"standard","severity":"recommended","rationale":"If you track clicks, this makes sure you will actually get the data. It grades only the tracking already on your links and never asks you to add any: unresolved merge tokens such as `utm_campaign={{campaign.name}}`, empty or duplicated parameters, misspelled UTM keys that analytics silently ignores, a raw email address sitting in a query string, and stray `gclid` or `fbclid` parameters that reveal a URL was pasted from a browser after an ad click. No links are fetched, so nothing here registers a click.\n\nWorth knowing: click tracking is **not** penalised by sending volume. The real risk is the reputation of the domain your links redirect through — a shared tracking domain pools reputation with every other sender on your platform. A custom tracking domain on your own subdomain isolates you from that.","parameters":null},{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"recommended","rationale":"If you track clicks, this makes sure you will actually get the data. It grades only the tracking already on your links and never asks you to add any: unresolved merge tokens such as `utm_campaign={{campaign.name}}`, empty or duplicated parameters, misspelled UTM keys that analytics silently ignores, a raw email address sitting in a query string, and stray `gclid` or `fbclid` parameters that reveal a URL was pasted from a browser after an ad click. No links are fetched, so nothing here registers a click.\n\nWorth knowing: click tracking is **not** penalised by sending volume. The real risk is the reputation of the domain your links redirect through — a shared tracking domain pools reputation with every other sender on your platform. A custom tracking domain on your own subdomain isolates you from that.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"recommended","rationale":"If you track your campaigns, this makes sure you will actually get the data. It grades the tracking already on your links and never asks you to add any: unresolved merge tokens such as utm_campaign={{campaign.name}}, empty or duplicated parameters, misspelled UTM keys that analytics silently ignores, a raw email address sitting in a query string, and stray gclid or fbclid parameters that reveal a URL was pasted from a browser after an ad click.\n\nA misspelled utm_medium does not raise an error — it disappears, and you find out at the monthly review when the campaign shows no sessions.\n\nOne finding is heavier than the rest: a recipient's email address in a query string is a Google Analytics terms violation, and under GDPR it is personal data leaked into a third-party system and into every downstream referrer header.\n\nNo links are fetched, so nothing here registers a click and it is safe against a live campaign. It reports rather than blocks, because broken tracking costs you data rather than revenue.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"recommended","rationale":"If you track your campaigns, this makes sure you will actually get the data. It grades the tracking already on your links and never asks you to add any: unresolved merge tokens such as utm_campaign={{campaign.name}}, empty or duplicated parameters, misspelled UTM keys that analytics silently ignores, a raw email address sitting in a query string, and stray gclid or fbclid parameters that reveal a URL was pasted from a browser after an ad click.\n\nA misspelled utm_medium does not raise an error — it disappears, and you find out at the monthly review when the campaign shows no sessions.\n\nOne finding is heavier than the rest: a recipient's email address in a query string is a Google Analytics terms violation, and under GDPR it is personal data leaked into a third-party system and into every downstream referrer header.\n\nNo links are fetched, so nothing here registers a click and it is safe against a live campaign. It reports rather than blocks, because broken tracking costs you data rather than revenue.","parameters":null}],"runStats":{"runCount":14,"failureRate":0,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-tracking-integrity","slug":"tracking-parameters-intact","aka":["UTM hygiene","attribution check","tracking parameters","campaign tagging"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"link-functional-testing","detects":["a tracking parameter that shipped unresolved","parameters dropped through a redirect","an email address or merge token written into a link","a click id or UTM value outside your taxonomy"],"commonlyPairedWith":["email-utm-inventory","email-link-integrity","email-no-placeholder-text"],"triggersWhen":["a campaign is tagged for attribution","a tracking or redirect domain changes","analytics shows unattributed email traffic"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on any campaign whose performance you will be asked to account for. Two things hide in a link's query string: your attribution, and your subscribers. A parameter that shipped unresolved or was dropped through a redirect means the campaign has no attribution when someone asks what it earned — and that question is always asked after the send, when nothing can be changed. It runs source-only with no network by default, so it is cheap to include everywhere.","whenNotToUse":"Skip it on mail that carries no tracking by design — plain transactional notices, internal messages. Note it is a judgement check rather than an inventory: if you only want to see what every link actually carries, without any verdict, the UTM inventory check is the instrument for that. Be aware too that unsubscribe and preference links are exempt from this check entirely, because they are per-recipient functional URLs and a raw address in one is a defect of the unsubscribe mechanism, owned by the opt-out check instead.","failureMeaning":"A failure falls into two very different classes. Attribution findings mean a parameter is missing, unresolved or lost through a redirect, and the cost is measurement — traffic arrives unattributed and the campaign cannot be defended. Privacy findings are more serious and are name-agnostic: an email address, a merge token or a click id written into any query parameter travels into browser history, server logs and the next site's analytics, and no send can be recalled once it has gone. The corpus's most common personal-data hit is not in a `utm_` parameter at all.","thresholdRationale":"Nine parameters carry the check, and almost all are empty by default so it runs zero-config. `trackedLinkDomains` scopes the strictness layer and is the only trigger for fetching — empty means source-only hygiene with no clicks registered. `requiredTrackingParams` is empty so name-level enforcement is opt-in, and fully custom-nameable, because the UTM trio is Google's \"always use\" default rather than a constraint. `requiredUtmMedium`, `requiredLinkPattern` and `requiredTrackingPixelPattern` add optional shape rules. `enforceGa4Channels` defaults to `false` deliberately: UTM predates Google — the parameters are Urchin's — and GA4's channel groupings are one vendor's reading, so `utm_medium=newsletter` is correct on Matomo or Plausible and failing it would be our error. `allowedCustomUtmParams`, `allowedUtmSources` and `allowedUtmMediums` are the taxonomy hooks, empty until you declare your scheme.","customWhenWarranted":"Turn on `enforceGa4Channels` when GA4 really is your analytics and you want every value judged by where Google will actually file it — measured over a large marketing corpus, 9.7% of tagged links land outside the Email channel, concentrated in house conventions rather than scattered typos. Set `allowedUtmSources` and `allowedUtmMediums` when you have a documented taxonomy, and `allowedCustomUtmParams` when you deliberately ship `utm_`-prefixed names outside Google's nine. Set `trackedLinkDomains` when you want the strictness layer scoped to the domains you actually own.","customWhenToStayStandard":"Leave `enforceGa4Channels` off if you use Matomo, Plausible, Fathom, Umami or anything else that reports the value verbatim, because those tools have no channel taxonomy and your tagging is correct as written. Keep the taxonomy lists empty until your scheme is genuinely documented — a list invented during an audit will fail correct links and be relaxed within a week. Note that declaring `allowedUtmMediums` also switches the GA4 rules off, on the reasoning that whoever wrote down their approved mediums knows which tool they run.","customTradeoffs":"Enforcing GA4 channels imports another vendor's opinion into your verdicts, and its precedence rules are unpublished — the classifier returns the set of matching definitions and never predicts a winner, and the four channels whose rules test against site lists Google does not publish are declared unevaluable rather than guessed. Setting `trackedLinkDomains` enables fetching, which registers clicks on those domains and can pollute your own analytics if you point it carelessly. Taxonomy lists are maintenance: each addition is a value the check will never question again, and a stale list fails a legitimate new campaign type.","customGovernanceNotes":"The zero-config behaviour is deliberately vendor-neutral, because there is no standard for UTM — the parameters predate the company whose rules are most often quoted about them. Enabling GA4 enforcement is a statement about your analytics stack and should be recorded as such, so a later reader knows why a value was failed. The privacy checks are not configurable in the same way and should not be treated as taxonomy: they are link-integrity rules that apply to every parameter, and a finding there belongs to whoever owns data protection rather than to campaign operations.","customExamples":"A GA4 shop with a documented scheme sets `enforceGa4Channels` to `true` and `allowedUtmMediums` to `[\"email\"]`, narrowing an already-enforced field to the single value its taxonomy permits. A Matomo user leaves GA4 enforcement off and sets `allowedUtmSources` to its own source list, getting taxonomy enforcement without importing channel rules its analytics never applies. A sender shipping deliberate house parameters sets `allowedCustomUtmParams` to those names, so its intentional scheme stops being reported while genuinely unrecognised parameters still are.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-tracking-integrity"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-tracking-integrity","parameters":{"trackedLinkDomains":[],"requiredTrackingParams":[],"requiredUtmMedium":"","requiredLinkPattern":"","requiredTrackingPixelPattern":"","enforceGa4Channels":false,"allowedCustomUtmParams":[],"allowedUtmSources":[],"allowedUtmMediums":[]}}]},"defaultClients":null},{"modelVersion":1,"id":"email-typography","slug":"type-matches-your-brand","name":"Typography follows approved brand rules","aka":["brand fonts","font stack","Times New Roman fallback","email typography"],"subjectType":"email","category":"brand-compliance","severity":"optional","description":"Customer-configured typography verification: every font stack in the email must match an approved brand stack, webfonts must ship an Outlook defense, and weights/sizes must use client-safe vocabulary. Skips until approvedFontStacks is configured. See docs/EMAIL-TYPOGRAPHY.md.","executionKind":"functional","checkLabel":"Type matches your brand","checkValue":"Outlook’s Word engine ignores your fallback stack entirely and substitutes Times New Roman for any font it does not know. Configure your approved stacks once and every send is held to them — including the ones an AI agent wrote, where brand drift shows up in the type before anywhere else.","hasCustomConfig":true,"requiresConfiguration":true,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/email-typography/custom","parameters":[{"name":"approvedFontStacks","severity":"required","standardDefault":[],"formatSummary":"non-empty-string-array"},{"name":"webSafeFonts","severity":"recommended","standardDefault":["Arial","Verdana","Georgia","Times New Roman","Courier New","Courier","Trebuchet MS","Tahoma","Helvetica"],"formatSummary":"non-empty-string-array"},{"name":"minFontSizePx","severity":"required","standardDefault":13,"formatSummary":"positive-integer"}],"standards":[{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"recommended","rationale":"Checks that your email uses the font stacks your brand approves, and flags body copy set too small, size units the Word-based Outlook engine does not support, and webfonts left undefended in Outlook.\n\nNeeds configuration you have to compose: the full stacks exactly as your brand authors them, where order matters and Courier is not Courier New. Until you provide them the check is skipped rather than failed.\n\nIt is built to act as a brand-governance gate for AI-generated email. When an agent writes a campaign from a brief, typography is where brand drift shows up first — a plausible-looking Helvetica Neue, sans-serif that is not your stack, or body copy quietly set at 12px. Configure it once and every generated email gets a deterministic, zero-model verdict precise enough to hand straight back to the agent as a correction.\n\nEvery rule is scoped to the clients that actually apply it, which took its false-failure rate from 93.4% to 37.5% on real email. It still fails more than a third of messages, which is why it sits in this tier rather than the standard one.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"recommended","rationale":"Checks that your email uses the font stacks your brand approves, and flags body copy set too small, size units the Word-based Outlook engine does not support, and webfonts left undefended in Outlook.\n\nNeeds configuration you have to compose: your full stacks exactly as your brand authors them, where order matters and `Courier` is not `Courier New`. Until you provide them the check is skipped rather than failed, and it is not charged.\n\nIt sits in the thorough tier for a reason specific to this kind of mail. A transactional template is written once and changed rarely, so the font drift this catches is mostly a campaign-production problem. Where it earns its place here is governance — if your receipts are generated or edited by an agent, or maintained by a team that did not build the template, this gives you a deterministic, zero-model verdict precise enough to hand straight back as a correction.\n\nEvery rule is scoped to the clients that actually apply it, which took its false-failure rate from 93.4% to 37.5% on real email. It still fails more than a third of messages, which is the other reason it is here rather than in the standard set.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"recommended","rationale":"Checks that your email uses the font stacks your brand approves, and flags body copy set too small, size units the Word-based Outlook engine does not support, and webfonts left undefended in Outlook.\n\nNeeds configuration you have to compose: your full stacks exactly as your brand authors them, where order matters and `Courier` is not `Courier New`. Until you provide them the check is skipped rather than failed, and it is not charged.\n\nIt sits in the thorough tier for a reason specific to this kind of mail. An operational template is written once, often years ago, and changed rarely — so the font drift this catches is mostly a campaign-production problem. Where it earns its place here is governance: service notices are frequently generated by systems rather than composed by a person, and often by a team that did not build the template. This gives you a deterministic, zero-model verdict precise enough to hand straight back as a correction.\n\nEvery rule is scoped to the clients that actually apply it, which took its false-failure rate from 93.4% to 37.5% on real email. It still fails more than a third of messages, which is the other reason it is here rather than in the standard set.","parameters":null}],"runStats":null,"content":{"id":"email-typography","slug":"type-matches-your-brand","aka":["brand fonts","font stack","Times New Roman fallback","email typography"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"brand-compliance","detects":["a font stack that is not one of your approved ones","a webfont with no web-safe fallback for Outlook","body copy set below a readable size"],"commonlyPairedWith":["email-layout-not-broken","email-no-placeholder-text","email-subject-content","email-accessibility"],"triggersWhen":["a template is built, imported or AI-generated","brand typography changes","a new agency or tool contributes templates"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this once you have written down your approved font stacks, and put it in the path of anything that generates email for you. Outlook's Word engine ignores your fallback stack entirely and substitutes Times New Roman for any font it does not know, so a stack that looks fine in every other client can arrive looking like a legal notice. It is the sharpest gate available for AI-written sends, because brand drift shows up in the type before it shows up anywhere else — a plausible font stack that is simply not yours.","whenNotToUse":"Skip it while you have not agreed your stacks, since the check reports as needing configuration until they are supplied. It is also not a layout or hierarchy review: it holds declared type against your list and against a readable floor, not whether the heading sizes make sense. Deliberately plain-text-styled outreach, which is meant to look like a personal message written in the client's default font, is usually better left out of the set than configured around.","failureMeaning":"A failure names the type problem: a stack outside your approved list, a webfont declared with no web-safe fallback behind it, or copy set below the readable minimum. The stack failure matters because it is invisible to whoever built the template — it renders correctly on their machine and substitutes on a large share of business inboxes. A missing fallback is the same failure waiting to happen, and the size failure is the one recipients feel immediately on a phone.","thresholdRationale":"Three parameters carry the check. `approvedFontStacks` defaults to an empty list at `required` severity, a deliberate gate: there is no universal correct typeface, so rather than guess, the check reports as needing configuration until your brand supplies its stacks. `webSafeFonts` defaults to the consensus canon shared by the major email typography references and feeds the Outlook-defence check, and `minFontSizePx` defaults to `13`, the vendor-tested threshold below which iOS Mail begins auto-upscaling text.","customWhenWarranted":"Setting `approvedFontStacks` is what switches this check on, and it should be a transcription of your brand's real declarations rather than a list of family names. Adjust `webSafeFonts` when your judgement of what is safe differs from the consensus list — a sender whose audience skews to one platform may reasonably widen or narrow it. Raise `minFontSizePx` when your accessibility or design standard sets a higher floor than the auto-upscale trigger, which is common for brands with older audiences.","customWhenToStayStandard":"There is no useful unconfigured state for the stacks, so the question is whether to run the check at all rather than whether to override it. Keep `webSafeFonts` at the consensus list unless you have specific evidence to change it, because that list exists precisely to be defensible without knowing your audience. Keep `minFontSizePx` at 13 if your only concern is the auto-upscale behaviour rather than a broader readability policy.","customTradeoffs":"An approved-stack list is only as useful as it is narrow: listing every family anyone has used makes the check unable to detect drift, which is its main purpose. Widening `webSafeFonts` weakens the Outlook-defence finding, since a font you have declared safe will no longer be flagged as needing a fallback — and vendor lists drift, so a list widened once tends to stay widened. Raising the size floor generates findings on legitimate small print such as disclaimers and footers, so decide in advance whether those are in scope.","customGovernanceNotes":"The stacks are entirely yours; the web-safe list is a transcription of vendor-tested consensus, and the size floor is a transcription of observed client behaviour. That split matters for ownership: brand owns the first, and the other two should only be edited with a reason you can point to, because they represent the outside world rather than your preferences. Review the stacks whenever brand typography changes, since a check enforcing last year's typeface fails correct sends and looks like a tooling fault.","customExamples":"A brand whose email typography is a webfont with an Arial fallback sets `approvedFontStacks` to the exact declaration used in its templates, so an imported block using Helvetica alone fails immediately. A company with an older customer base raises `minFontSizePx` to `16`, treating readability as a brand commitment rather than a client-behaviour workaround. A team gating AI-generated sends keeps both other defaults and relies on the stack list alone, because the failure it is guarding against is a plausible font stack that was never theirs.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-typography"]},"agentContractCustom":{"type":"email","validations":[{"id":"email-typography","parameters":{"approvedFontStacks":[],"webSafeFonts":["Arial","Verdana","Georgia","Times New Roman","Courier New","Courier","Trebuchet MS","Tahoma","Helvetica"],"minFontSizePx":13}}]},"defaultClients":null},{"modelVersion":1,"id":"email-unsubscribe-present","slug":"unsubscribe-link-present","name":"Unsubscribe mechanism present","aka":["opt-out link","List-Unsubscribe header","one-click unsubscribe","CAN-SPAM opt-out"],"subjectType":"email","category":"legal-privacy-compliance","severity":"required","description":"Check MIME List-Unsubscribe header and rendered HTML anchors for unsubscribe URL/text patterns. Pass if either check passes.","executionKind":"functional","checkLabel":"Unsubscribe link present","checkValue":"CAN-SPAM requires a working opt-out in commercial email. The List-Unsubscribe header also powers the inbox’s native “Unsubscribe” button in Gmail and Apple Mail.","hasCustomConfig":false,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":null,"parameters":[],"standards":[{"setId":"cold-outreach-standard","setName":"Cold outreach — standard","category":"cold-outreach","tier":"standard","severity":"required","rationale":"An opt-out is legally required for cold outreach. CAN-SPAM applies to commercial email at any volume — there is no bulk threshold, and a one-to-one prospecting email is commercial however personal it looks (15 U.S.C. §7704(a)(3), §7704(a)(5)(A)(ii)).\n\nThis check is deliberately stricter than the minimum. The statute accepts opt-out by reply — §7704(a)(3)(A)(i) names \"a reply electronic mail message\" as a valid mechanism — and Gmail only mandates the one-click `List-Unsubscribe` header above 5,000 messages a day, a threshold cold outreach rarely crosses. We still hold this line, because of how complaints are weighted: deliverability guidance consistently holds that a spam complaint costs far more than an unsubscribe — commonly put at 5–10× — though neither Google nor Microsoft publishes the ratio, and a recipient who cannot find an easy way out reaches for the spam button instead. A machine-readable opt-out is the cheapest insurance your sending reputation has.\n\nWorth knowing: some evidence suggests Gmail applies extra scrutiny when a one-to-one-shaped email carries bulk-sender headers. If you opt out by reply instead, you remain compliant — override this check, or build a custom set.","parameters":null},{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"required","rationale":"An opt-out is legally required for cold outreach. CAN-SPAM applies to commercial email at any volume — there is no bulk threshold, and a one-to-one prospecting email is commercial however personal it looks (15 U.S.C. §7704(a)(3), §7704(a)(5)(A)(ii)).\n\nThis check is deliberately stricter than the minimum. The statute accepts opt-out by reply — §7704(a)(3)(A)(i) names \"a reply electronic mail message\" as a valid mechanism — and Gmail only mandates the one-click `List-Unsubscribe` header above 5,000 messages a day, a threshold cold outreach rarely crosses. We still hold this line, because of how complaints are weighted: deliverability guidance consistently holds that a spam complaint costs far more than an unsubscribe — commonly put at 5–10× — though neither Google nor Microsoft publishes the ratio, and a recipient who cannot find an easy way out reaches for the spam button instead. A machine-readable opt-out is the cheapest insurance your sending reputation has.\n\nWorth knowing: some evidence suggests Gmail applies extra scrutiny when a one-to-one-shaped email carries bulk-sender headers. If you opt out by reply instead, you remain compliant — override this check, or build a custom set.","parameters":null},{"setId":"marketing-standard","setName":"Marketing email — standard","category":"marketing","tier":"standard","severity":"required","rationale":"Every marketing email must offer a way out. CAN-SPAM requires a working opt-out honoured within 10 business days (15 U.S.C. §7704(a)(3)), CASL requires the mechanism stay live for 60 days, and Gmail, Yahoo and Microsoft all require one from bulk senders.\n\nThis confirms an opt-out exists — either a List-Unsubscribe header or an unsubscribe link in the body. It found one in 99.1% of a 57,000-email marketing corpus, so a failure here is rare and serious: it means the send has no exit at all.\n\nWhat it does not check is RFC 8058 one-click compliance. A mailto:-only header passes this check, and since May 2026 Google and Microsoft issue permanent 550 rejections for bulk marketing mail that lacks an HTTPS List-Unsubscribe together with List-Unsubscribe-Post. Read a pass here as \"you have an opt-out\", not as \"Gmail will accept this\".","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"required","rationale":"Every marketing email must offer a way out. CAN-SPAM requires a working opt-out honoured within 10 business days (15 U.S.C. §7704(a)(3)), CASL requires the mechanism stay live for 60 days, and Gmail, Yahoo and Microsoft all require one from bulk senders.\n\nThis confirms an opt-out exists — either a List-Unsubscribe header or an unsubscribe link in the body. It found one in 99.1% of a 57,000-email marketing corpus, so a failure here is rare and serious: it means the send has no exit at all.\n\nWhat it does not check is RFC 8058 one-click compliance. A mailto:-only header passes this check, and since May 2026 Google and Microsoft issue permanent 550 rejections for bulk marketing mail that lacks an HTTPS List-Unsubscribe together with List-Unsubscribe-Post. Read a pass here as \"you have an opt-out\", not as \"Gmail will accept this\".","parameters":null}],"runStats":{"runCount":150,"failureRate":0.04666666666666667,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"email-unsubscribe-present","slug":"unsubscribe-link-present","aka":["opt-out link","List-Unsubscribe header","one-click unsubscribe","CAN-SPAM opt-out"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"legal-privacy-compliance","detects":["a commercial send with no working opt-out","a missing List-Unsubscribe header","an unsubscribe route lost in a template edit"],"commonlyPairedWith":["email-physical-address-present","email-footer-complete","email-no-placeholder-text"],"triggersWhen":["a commercial or marketing send goes out","a template or ESP wrapper changes","a legal or compliance review is scheduled"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on every commercial send, on the mail that actually reached the inbox rather than on the template. The template had an opt-out in it last quarter too; what matters is whether the message survived the merge, the ESP wrapper and whatever the campaign editor changed on the way out. It also reads the `List-Unsubscribe` header, which is what powers the native Unsubscribe button in Gmail and Apple Mail — the route most recipients now use, and the one a footer-only review never looks at.","whenNotToUse":"Do not run it on operational mail where an opt-out is itself the defect. Nobody may unsubscribe from a security notice, a password reset or a service outage warning, so a passing verdict on that mail would be recording the wrong outcome. Transactional receipts and confirmations sit in the same category: they are not commercial solicitations, and the honest audit choice is to leave this check out of the set rather than to configure your way around it.","failureMeaning":"A failure means the message offered no working opt-out where the audit looked for one. For commercial mail that is a legal exposure under CAN-SPAM and an immediate deliverability problem, because recipients with no unsubscribe route use the spam button instead — which is the single most damaging signal you can teach a mailbox provider. The usual cause is mechanical: a wrapper that did not apply, a merge that dropped a footer block, or a header the sending platform stopped adding.","thresholdRationale":"This check has no tunable thresholds. It is a presence check against the message as delivered — the header and the visible opt-out route are either there or they are not — so there is nothing to calibrate and no numeric dial to argue about. What varies is not the threshold but whether the check belongs in the set at all, which is a decision about the kind of mail you are sending.","customWhenWarranted":"Never — this check has no Custom Parameters. Its public custom page redirects to the Standard page, because there is no override that would make sense: an opt-out requirement you could tune down is not a requirement.","customWhenToStayStandard":"Always. There are no override knobs here, so the Standard behaviour is the only behaviour; the decision you actually have is whether to include the check for a given kind of send.","customTradeoffs":"There is nothing to trade away, because there is nothing to configure. The only real trade-off sits outside the check: putting it in the set for a service notice records a verdict that misrepresents what the send was allowed to be.","customGovernanceNotes":"The requirement here comes from statute and from mailbox-provider behaviour rather than from anything an organisation sets locally, which is why no part of it is left to configuration. Governance of this check is therefore about scope — which sends it runs on — not about values.","customExamples":"There are no override examples to give, since the check exposes no parameters. The nearest equivalent decision is illustrated by the curated sets: it belongs in marketing and cold-outreach standards, and is deliberately absent from operational ones.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-unsubscribe-present"]},"agentContractCustom":null,"defaultClients":null},{"modelVersion":1,"id":"email-utm-inventory","slug":"every-links-tracking-parameters-listed","name":"Link UTM and query parameters inventoried","aka":["UTM inventory","query parameter list","link parameter audit","tagging discovery"],"subjectType":"email","category":"link-functional-testing","severity":"recommended","description":"Lists every http(s) link in the email and returns its decoded query parameters, with utm_-prefixed keys surfaced separately. Does not judge correctness — inventory only. See docs/EMAIL-UTM-INVENTORY.md.","executionKind":"functional","checkLabel":"Every link’s tracking parameters listed","checkValue":"Before you argue about whether the tagging is right, you need to see what every link actually carries — every query key, every utm_ name, including the custom ones your ESP or analytics stack invented. This check lists them and stops there.","hasCustomConfig":false,"requiresConfiguration":false,"price":null,"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":null,"parameters":[],"standards":[],"runStats":null,"content":{"id":"email-utm-inventory","slug":"every-links-tracking-parameters-listed","aka":["UTM inventory","query parameter list","link parameter audit","tagging discovery"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"link-functional-testing","detects":["every query key on every link","utm_-prefixed parameters in use","custom tracking names your stack invented"],"commonlyPairedWith":["email-tracking-integrity","email-link-integrity"],"triggersWhen":["a tagging convention is being documented","analytics attribution is being investigated","a taxonomy is being agreed before enforcement"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this before you argue about whether the tagging is right. It lists every http and https link's decoded query bag and the `utm_`-prefixed subset within it, including the custom names your ESP or analytics stack invented, and then stops. That makes it the natural first step when you are documenting a convention or preparing to enforce one, because you cannot write a taxonomy against tagging you have not seen. It performs no network requests and reports no findings, so it never fails a send.","whenNotToUse":"Skip it when you already know your scheme and want a verdict, since this check deliberately offers none — the grade lives in the tracking-integrity check. It is also not a privacy scan: it will show you a parameter containing an email address because it shows you everything, but the judgement that such a parameter is a defect belongs elsewhere. Running it on mail with no links produces an empty inventory, which is accurate and not useful.","failureMeaning":"There is no failure. This check always passes by design, because its output is a record rather than a judgement — the value is in reading what it lists, not in a verdict. If you want a pass or fail on tagging quality, pair it with the tracking-integrity check in the same run and read this one as the evidence behind that one's findings.","thresholdRationale":"This check has no tunable thresholds, and it could not have any — it is pure discovery, with nothing to judge and therefore nothing to calibrate. Every link's query bag is reported as it is found, decoded but not interpreted, which is the whole point: a discovery tool that filtered its output would hide exactly the unexpected parameter you were looking for.","customWhenWarranted":"Never, since there are no Custom Parameters on this check; its public custom page redirects to the Standard page. Everything configurable about tracking lives on the tracking-integrity check, which is where enforcement belongs.","customWhenToStayStandard":"Always — there is only one behaviour, and it is the correct one for a discovery check. The decision available to you is whether you are at the discovery stage or the enforcement stage, which is a choice between this check and its judging counterpart.","customTradeoffs":"Nothing can be configured, so nothing is traded. The only cost is attention: this check produces a list somebody has to read, and an inventory nobody reads is a run spent for nothing.","customGovernanceNotes":"Because it reports rather than judges, there is no policy embedded here and nothing for a governance process to own. Its role in governance is upstream: it produces the evidence from which a tagging taxonomy is written, and that taxonomy is what later gets configured and owned.","customExamples":"There are no override examples, as the check exposes no parameters. The intended workflow is the example: inventory a handful of real campaigns, write down the conventions you find, then configure the tracking-integrity check with the taxonomy that emerges.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-utm-inventory"]},"agentContractCustom":null,"defaultClients":null},{"modelVersion":1,"id":"font-size-body-min-max","slug":"body-text-large-enough-to-read","name":"Minimum font size for body text","aka":["minimum font size","body copy size","unreadable text"],"subjectType":"url","category":"accessibility-compliance","severity":"required","description":"In order for any webpage to be minimally readable, a font size minimum and maximum should be set","executionKind":"functional","checkLabel":"Body text large enough to read","checkValue":"Text below the minimum size is effectively unreadable (an accessibility failure); text far above the maximum usually signals a broken layout or stylesheet.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":3,"captureMailboxes":3,"captureCredits":1,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/font-size-body-min-max/custom","parameters":[{"name":"minPx","severity":"required","standardDefault":"6px","formatSummary":"pixel-size"},{"name":"maxPx","severity":"required","standardDefault":"48px","formatSummary":"pixel-size"}],"standards":[],"runStats":{"runCount":99,"failureRate":0.09090909090909091,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"font-size-body-min-max","slug":"body-text-large-enough-to-read","aka":["minimum font size","body copy size","unreadable text"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"accessibility-compliance","detects":["body copy rendered below a readable size","text blown far past its intended size by a broken rule","a stylesheet change that shrank copy sitewide"],"commonlyPairedWith":["no-lorem-ipsum","visual-diff","logo-usage"],"triggersWhen":["a stylesheet or design-token change ships","a page is migrated to a new template","a page is watched on a schedule"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on any page where the body copy is the product — documentation, articles, pricing tables, legal pages, checkout copy. It is most valuable as a standing check on pages you do not open often, because a shrunk paragraph is invisible to whoever shipped it and obvious to the person trying to read it. It costs nothing to leave on, so the usual pattern is to include it in every page audit rather than reaching for it after a complaint.","whenNotToUse":"Skip it on pages that are deliberately typographic experiments — a poster-style campaign landing page or a splash screen where oversized display type is the design, not a defect. It is also the wrong instrument for judging whether your type scale is *good*: it answers whether text is readable at all, not whether 15px was the right reading size. If you are auditing a design system's hierarchy, review it against your own tokens instead.","failureMeaning":"A failure names the measured size and which end of the range it broke. A size under the floor means text on the live page is effectively unreadable, which is an accessibility defect and usually the result of a cascade problem rather than an intentional choice. A size far over the ceiling almost never means \"someone chose 90px body copy\" — it means a rule that should have applied to a heading leaked onto the paragraph, or a stylesheet failed to load and the browser is rendering unstyled defaults.","thresholdRationale":"Two parameters carry the check: `minPx` and `maxPx`, defaulting to `6px` and `48px`. The floor is deliberately permissive — it is not a design opinion about your reading size, it is a one-sided test for text that has genuinely stopped being text, so a page setting 14px body copy passes and nobody argues with the tool. The ceiling exists for the same reason in the other direction: it catches the broken-layout and missing-stylesheet cases, where copy renders at heading or unstyled-default scale, without failing legitimate large-type design.","customWhenWarranted":"Override when you have an accessibility commitment stricter than \"not unreadable\" and want the check to enforce it. Raising `minPx` to 14 or 16 turns a defect detector into a design-system gate, which is the right move when your team has published a minimum reading size and wants every page held to it automatically. Lowering `maxPx` is worth it on templates where you know the largest legitimate body element and want tighter detection of cascade leaks.","customWhenToStayStandard":"Stay on the defaults if you have not actually agreed a minimum reading size internally, because the check will start failing pages over a number nobody signed off on and the findings will be argued with instead of fixed. Keep the Standard range on third-party or marketing pages you do not control the CSS for — you cannot change CSS you do not own, and a permanently failing check trains people to ignore it. If your goal is simply \"tell me when a page breaks\", the defaults already do that.","customTradeoffs":"A raised `minPx` produces more findings, and the findings become opinions rather than defects — you have to be willing to treat them as work. Because a tighter floor fires on pages that are perfectly usable, the cost is credibility: a check that fails on something the team will not fix is worse than no check. Tightening `maxPx` has the opposite risk, quietly passing a genuine cascade leak that happens to land inside your narrowed window.","customGovernanceNotes":"The Standard range is a shared floor: it is written to be defensible on any page, from any organisation, without configuration. Your Custom range is a statement about *your* type system and belongs to you — it should come from a published design token or accessibility policy you can point at, not from a number chosen during one audit. Record where the value came from, because a threshold nobody can source is the first thing relaxed the next time it fails.","customExamples":"A documentation site with a published 16px minimum sets `minPx` to `16px` and leaves `maxPx` alone, turning the check into an enforcement of its own standard. A marketing team whose templates cap body copy at 20px sets `maxPx` to `24px` to catch heading rules leaking into paragraphs early, accepting that legitimate display type must then be excluded from the audited pages. A team auditing a partner-hosted page they cannot edit keeps both defaults, because the only actionable finding there is text that has genuinely broken.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"url","url":"https://example.com","validations":["font-size-body-min-max"]},"agentContractCustom":{"type":"url","url":"https://example.com","validations":[{"id":"font-size-body-min-max","parameters":{"minPx":"6px","maxPx":"48px"}}]},"defaultClients":null},{"modelVersion":1,"id":"footer-compliance","slug":"footer-has-the-required-links","name":"Footer Compliance","aka":["footer links","privacy policy link","terms link","copyright notice"],"subjectType":"url","category":"brand-compliance","severity":"required","description":"Verify footer includes required brand elements","executionKind":"visual","checkLabel":"Footer has the required links","checkValue":"The footer is where the legal links, the copyright and the contact route live. A template change that drops one of them takes it off every page at once, and nobody notices until it is asked for.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":5,"unit":"per_capture","captureCount":3,"captureMailboxes":3,"captureCredits":1,"configuredCredits":15},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/footer-compliance/custom","parameters":[{"name":"footerRequirements","severity":"required","standardDefault":"Footer must be visible and include a copyright notice, a privacy policy link, and terms or conditions link.","formatSummary":"non-blank-string"}],"standards":[],"runStats":{"runCount":93,"failureRate":0.8709677419354839,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"footer-compliance","slug":"footer-has-the-required-links","aka":["footer links","privacy policy link","terms link","copyright notice"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"brand-compliance","detects":["a missing privacy policy or terms link","a dropped copyright notice","a footer that stopped rendering on one template"],"commonlyPairedWith":["logo-usage","visual-diff","no-lorem-ipsum"],"triggersWhen":["a shared layout or footer partial changes","a new page template ships","a legal or policy review is scheduled"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this whenever the footer is inherited rather than authored — which is nearly always. The footer is a shared partial, so a change to it lands on every page at once, and the elements it carries are exactly the ones nobody looks at until someone official asks for them. It is worth running across a spread of templates rather than one page, because footers most often break per-template: the marketing pages keep theirs and the app or checkout pages quietly lose it.","whenNotToUse":"Skip it on pages that intentionally have no footer — a full-screen checkout step, an embedded widget, a print or export view, a bare confirmation screen. It is also the wrong check for verifying that your privacy policy is *correct* or current; it confirms the route to it exists on the page. If the question is whether the policy content satisfies a regulation, that is a legal review, not a page audit.","failureMeaning":"A failure names which required element it could not find. The likely cause is structural rather than editorial: a layout that does not include the footer partial, a conditional that hides it on this template, or a link that was renamed and no longer reads as the thing being looked for. Because the footer is shared, one failing page usually means a class of pages is failing — treat the finding as a question about the template, not the URL.","thresholdRationale":"One parameter carries the check: `footerRequirements`, a written requirement rather than a numeric threshold. Its Standard default asks that the footer be visible and include a copyright notice, a privacy policy link, and a terms or conditions link — the three elements common to almost every commercial site, stated in plain language rather than as a selector. There is no tunable number here because the check is a presence judgement against a stated rule; the rule itself is the dial.","customWhenWarranted":"Override `footerRequirements` when your footer carries obligations the generic three do not cover. Regulated industries are the clearest case — a financial services site that must show a regulator registration number, a healthcare site with a required disclaimer, an EU-facing site that must route to cookie preferences. Write the requirement as you would explain it to a new employee, naming each element you expect to see, and the check holds every audited page to that sentence instead of the default one.","customWhenToStayStandard":"Stay on Standard if your footer requirement is genuinely the common three, because rewriting the sentence to say the same thing only creates a second version to keep current. Keep the default when you are auditing many sites or brands at once and want one comparable baseline across them. If your real question is whether the footer *looks* right rather than whether it carries the required routes, the change-detection check answers that better than a rewritten requirement.","customTradeoffs":"A custom requirement is only as good as its wording: the more elements you name in one sentence, the more ways a page can fail it and the less precisely the finding tells you which part was missing. Long, densely conditional requirements (\"unless the page is transactional, in which case…\") tend to produce findings people argue with rather than fix. You also take on maintenance — a requirement listing your regulator's number format is now something that must be updated when the regime changes, and a stale requirement fails good pages.","customGovernanceNotes":"The Standard requirement is written to be defensible on any commercial page without configuration, which is why it stops at the three near-universal elements. A Custom requirement is your organisation's own compliance statement and should be sourced from wherever that lives — a legal checklist, a brand standard, a regulator's guidance — with an owner who reviews it. Keep the wording plain: the requirement is read by the check and by whoever has to act on the failure, and both are better served by a sentence than by a specification.","customExamples":"A regulated lender extends `footerRequirements` so that the three usual elements are joined by its regulatory registration number, turning one audit into evidence for a compliance file. A publisher operating in the EU adds a cookie-preferences route to the requirement, because its obligation is to offer ongoing consent management, not just a policy page. A product team whose app shell deliberately ships a minimal footer narrows the requirement for those templates to a copyright notice and a privacy link, and keeps the full requirement on marketing pages.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"url","url":"https://example.com","validations":["footer-compliance"]},"agentContractCustom":{"type":"url","url":"https://example.com","validations":[{"id":"footer-compliance","parameters":{"footerRequirements":"Footer must be visible and include a copyright notice, a privacy policy link, and terms or conditions link."}}]},"defaultClients":null},{"modelVersion":1,"id":"logo-usage","slug":"logo-used-correctly","name":"Logo Usage","aka":["logo check","brand mark","header logo","stretched logo"],"subjectType":"url","category":"brand-compliance","severity":"required","description":"Verify logo is present and follows brand guidelines","executionKind":"visual","checkLabel":"Logo used correctly","checkValue":"A stretched, cropped or missing logo is the first thing a visitor reads as sloppy — and it usually arrives through a stylesheet change nobody connected to the header.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":5,"unit":"per_capture","captureCount":3,"captureMailboxes":3,"captureCredits":1,"configuredCredits":15},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/logo-usage/custom","parameters":[{"name":"logoRequirement","severity":"required","standardDefault":"A brand or company logo must be present, clearly visible, and readable in the header or primary brand area at every captured viewport.","formatSummary":"non-blank-string"}],"standards":[],"runStats":{"runCount":93,"failureRate":0.17204301075268819,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"logo-usage","slug":"logo-used-correctly","aka":["logo check","brand mark","header logo","stretched logo"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"brand-compliance","detects":["a missing or unrendered header logo","a logo stretched or squashed out of proportion","a mark too small or obscured to read"],"commonlyPairedWith":["visual-diff","footer-compliance","font-size-body-min-max"],"triggersWhen":["a header or navigation component changes","brand assets are replaced or re-hosted","a new page template ships"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on any page a customer might land on cold, where the header is doing the work of saying whose site this is. It earns its place most on sites with several templates or sub-brands, because the header is a shared component and a change to it either fixes or breaks every page at once. Include it in scheduled runs on key landing pages, since logos break through asset moves and stylesheet changes far more often than through anyone editing the header.","whenNotToUse":"Skip it on pages that deliberately have no logo — an embedded widget, an iframe destination, a whitelabelled surface, a print stylesheet. It is also not the right check for brand-guideline questions it cannot see, like whether the correct colour variant was used against a given background, or whether clear-space rules were respected to the millimetre. Those need a human against the brand book; this check answers whether the mark is present, whole and readable.","failureMeaning":"A failure says what was wrong with the mark: absent, distorted, cropped, or too small or low-contrast to read. The common cause is not a designer's choice but an inherited one — a width or height set on one axis, a container that changed size, an asset that moved and now resolves to nothing. Because the header is shared, a failure here usually describes how every page in that template currently greets its visitors.","thresholdRationale":"One parameter carries the check: `logoRequirement`, a written rule rather than a number. Its Standard default asks that a brand or company logo be present, clearly visible, and readable in the header or primary brand area — deliberately broad, because \"correct logo usage\" differs by brand and a universal numeric rule would be wrong for most of them. There is no threshold to tune; the requirement sentence is what the check judges against.","customWhenWarranted":"Override `logoRequirement` when your brand has a specific, visible rule you want held automatically. Good candidates are rules a reader could verify from a screenshot: which variant belongs on a dark background, that the mark must appear top-left rather than centred, that the wordmark must accompany the symbol, or that a sub-brand lockup must appear alongside the parent. Write it as an instruction to a careful reviewer, naming what you expect to see and where.","customWhenToStayStandard":"Stay on Standard when your question is \"is the logo there and intact\", which is what most audits actually need and what the default answers well. Keep the default when auditing sites you do not control the brand of — agency work in progress, partner pages, acquisitions mid-migration — because holding someone else's page to your lockup rules produces findings nobody can act on. If your rule depends on facts a capture cannot show, such as the source file format or the exact hex of an asset, a page audit is the wrong instrument.","customTradeoffs":"The more specific the requirement, the more judgement each verdict carries, and the more likely a legitimate variant reads as a failure — a responsive header that switches to the symbol alone at narrow widths will fail a rule demanding the full lockup unless you say so. Very long requirements also blunt the finding: when one sentence names five rules, the failure tells you the sentence was not met rather than which part. Keep each requirement to the rules you would actually reject a page over.","customGovernanceNotes":"The Standard requirement is written to be defensible for any brand without configuration, which is why it stops at present, visible and readable. A Custom requirement is a transcription of your brand book and should cite it — the value belongs to your brand team, with a named owner, not to whoever last ran an audit. When the brand book changes, this string is one of the things that has to change with it, so keep it somewhere that review touches.","customExamples":"A company with a dark-and-light lockup pair sets `logoRequirement` to state that the light-on-dark variant must appear in the header when the header background is dark, and the dark variant otherwise — a rule a capture can genuinely settle. A group brand requires that a sub-brand mark appear alongside the parent wordmark in the header, catching pages migrated from an acquisition before the lockup was applied. An agency auditing a client's live site before handover keeps the Standard requirement, because the useful finding at that stage is a broken or missing mark, not a guideline argument.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"url","url":"https://example.com","validations":["logo-usage"]},"agentContractCustom":{"type":"url","url":"https://example.com","validations":[{"id":"logo-usage","parameters":{"logoRequirement":"A brand or company logo must be present, clearly visible, and readable in the header or primary brand area at every captured viewport."}}]},"defaultClients":null},{"modelVersion":1,"id":"no-lorem-ipsum","slug":"no-placeholder-text-left-in","name":"No Lorem Ipsum","aka":["lorem ipsum","FPO copy","unfinished content","placeholder copy"],"subjectType":"url","category":"content-quality","severity":"required","description":"No placeholder text - prohibited phrases must not be present","executionKind":"functional","checkLabel":"No placeholder text left in","checkValue":"Copy like “lorem ipsum” on a live page means unfinished template content shipped to the public.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":1,"captureMailboxes":1,"captureCredits":1,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/no-lorem-ipsum/custom","parameters":[{"name":"prohibitedPhrases","severity":"prohibited","standardDefault":["lorem","ipsum","fpo","content goes here"],"formatSummary":"non-empty-string-array"}],"standards":[],"runStats":{"runCount":33,"failureRate":0.15151515151515152,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"no-lorem-ipsum","slug":"no-placeholder-text-left-in","aka":["lorem ipsum","FPO copy","unfinished content","placeholder copy"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"content-quality","detects":["lorem ipsum surviving to a live page","FPO and 'content goes here' filler","a template section nobody replaced before launch"],"commonlyPairedWith":["font-size-body-min-max","visual-diff","footer-compliance"],"triggersWhen":["a new page or template goes live","a CMS section is duplicated from a template","a page is watched on a schedule"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on anything newly published, and on any page built by duplicating a template — that is where filler survives. It is also worth leaving on permanently for large CMS-driven sites, because the failure mode is not \"someone forgot at launch\", it is \"a section added eighteen months later inherited the template's placeholder and nobody scrolled that far\". It reads the page source and makes no model call, so it is cheap enough to run on every page every time.","whenNotToUse":"Skip it on pages that legitimately discuss placeholder text — a design system's typography specimen, a CSS tutorial, a blog post about lorem ipsum itself. In those cases the phrase is the content, and the check has no way to tell subject from accident. If you only have one or two such pages, exclude them from the audit rather than weakening the phrase list for the whole site.","failureMeaning":"A failure means one of the prohibited phrases appears in the page's own text, and it quotes what it found. This is one of the few findings with no interpretation attached: unfinished template content is on a public page. It usually points at a section that was never reviewed rather than a mistake in a section that was, so treat the finding as a signal to read the whole block, not just replace the sentence.","thresholdRationale":"One parameter carries the check: `prohibitedPhrases`, defaulting to `lorem`, `ipsum`, `fpo` and `content goes here`. These are the four that appear in real unfinished work and effectively never appear in finished copy, which is what makes the check quiet enough to leave on. The list is deliberately short — every phrase added is a new chance to fail a page that legitimately uses the word, and a placeholder detector that cries wolf gets switched off.","customWhenWarranted":"Override `prohibitedPhrases` when your own tooling has a house filler that the defaults do not know: a CMS that stamps `TK`, an agency that writes `TBD` or `[COPY HERE]`, an export pipeline that leaves `xxx` in unfilled fields. This is the highest-value override in the catalog, because your filler is the one most likely to actually reach production and the one least likely to be in a generic list. Add the strings your team really types, taken from a real unfinished page rather than from imagination.","customWhenToStayStandard":"Stay on the defaults if you cannot name a house placeholder convention, because guessing produces false failures on ordinary words. Keep the Standard list on sites with heavy editorial copy, where short additions like `tbd` or `draft` appear inside legitimate sentences far more often than they appear as filler. If your problem is unmerged personalisation rather than filler prose, this is the wrong check to widen — that behaviour lives in the email placeholder check.","customTradeoffs":"Every phrase you add trades quiet for coverage, and the loss is asymmetric: one false failure on a real article costs more trust than one caught placeholder buys. Short or common strings are the dangerous ones, because they match inside longer words and ordinary sentences. Note also that supplying your own list replaces the defaults rather than extending them, so include the original four alongside your additions unless you genuinely want them gone.","customGovernanceNotes":"The Standard list is meant to be true for everyone, which is why it is limited to phrases that only ever appear in unfinished work. A Custom list encodes something only your organisation knows — the filler your own tools and agencies produce — and it should be maintained wherever your content conventions are documented, not rediscovered per audit. When you add a phrase, write down which pipeline produces it, so the entry can be retired when that pipeline is.","customExamples":"An agency whose writers mark gaps with `TK` sets `prohibitedPhrases` to `[\"lorem\", \"ipsum\", \"fpo\", \"content goes here\", \"tk-copy\", \"[copy here]\"]`, keeping the defaults and adding its own two. A product team whose CMS stamps `Untitled section` on new blocks adds that exact string, which catches an entire class of half-built pages the generic list misses. A design system site that publishes a typography specimen instead removes `lorem` and `ipsum` from its list for that one page's audit, keeping `fpo` and `content goes here` so the check still has teeth.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"url","url":"https://example.com","validations":["no-lorem-ipsum"]},"agentContractCustom":{"type":"url","url":"https://example.com","validations":[{"id":"no-lorem-ipsum","parameters":{"prohibitedPhrases":["lorem","ipsum","fpo","content goes here"]}}]},"defaultClients":null},{"modelVersion":1,"id":"page-load-speed","slug":"page-loads-fast-enough","name":"Page load speed within budget","aka":["largest contentful paint","LCP","load time","page speed"],"subjectType":"url","category":"performance-testing","severity":"recommended","description":"Measures the page load from the browser's own performance timeline: Largest Contentful Paint, time to first byte, first paint, page weight and a per-resource-type breakdown of bytes and time, plus the heaviest and slowest resources. Only LCP is judged, against the configurable maxLcpMs budget (2500 ms by default); everything else is reported, because the harness measures one unthrottled load and no published threshold settles them. See docs/PAGE-LOAD-SPEED.md.","executionKind":"functional","checkLabel":"Page loads fast enough","checkValue":"A visitor decides whether to wait long before the page finishes. This times the load from the browser’s own clock and names the file that held it up — on a fast connection with nothing cached, so a page that is slow even here has a real problem.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":1,"unit":"per_run","captureCount":1,"captureMailboxes":1,"captureCredits":1,"configuredCredits":1},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/page-load-speed/custom","parameters":[{"name":"maxLcpMs","severity":"required","standardDefault":2500,"formatSummary":"positive-integer"}],"standards":[],"runStats":{"runCount":1,"failureRate":0,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"page-load-speed","slug":"page-loads-fast-enough","aka":["largest contentful paint","LCP","load time","page speed"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"performance-testing","detects":["main content appearing later than the target","a single asset holding up the render","a regression in load time after a release"],"commonlyPairedWith":["visual-diff","logo-usage","font-size-body-min-max"],"triggersWhen":["a page is watched on a schedule","a release or asset change ships","a paid campaign points at a landing page"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on pages where a visitor's patience is the budget — paid landing pages, product pages, signup flows, anywhere a bounce costs you money directly. It times the load from the browser's own clock and names the file that held it up, which makes it useful for the argument as well as the alarm: you get the number and the culprit in the same finding. It is most informative on a schedule, because performance regresses through accumulated asset and tag changes rather than in one visible release.","whenNotToUse":"Do not use it as a substitute for field data. The measurement is a single clean load on a fast connection with nothing cached, so it tells you whether the page is slow by construction, not what your actual visitors experience on their own devices and networks. Skip it on pages behind authentication that the audit cannot reach in a representative state, and on pages whose slowness you already know and have accepted — a heavy interactive tool will fail this every time without teaching you anything new.","failureMeaning":"A failure means the page's largest contentful paint landed later than the target, and the finding names the element or file responsible. Because the run is unthrottled and uncached, a failure here is a strong statement: the page is slow in the most favourable conditions it will ever see, so it is slower for everyone else. A pass is a weaker statement in the other direction — it means nothing structural is wrong, not that real users are having a fast experience.","thresholdRationale":"One parameter carries the check: `maxLcpMs`, defaulting to `2500`. That is web.dev's \"good\" largest-contentful-paint boundary, and it is worth knowing the boundary was defined at the 75th percentile of *field* data while this applies it to a single unthrottled lab load. That is intentional and one-sided: a page that cannot clear the field threshold in laboratory conditions is too slow everywhere, which makes a failure meaningful and a pass deliberately unambitious.","customWhenWarranted":"Override `maxLcpMs` when you know something about your audience or your origin that the default cannot. Tighten it — 1500 or 2000 — when you are enforcing an internal performance budget and want the lab test to fail before field data would, which is the whole point of a budget. Loosen it when the audited page is genuinely heavy by design and your goal is regression detection rather than a grade, so the check fires when the page gets worse instead of failing constantly.","customWhenToStayStandard":"Stay on 2500 when you want a defensible external number rather than a local one, especially if the result is going into a report someone outside the team will read. Keep the default when you are comparing many pages or sites, since a shared threshold is what makes those numbers comparable at all. If your real problem is that visitors on slow networks suffer, changing this number does not address it — that needs field measurement, not a different lab boundary.","customTradeoffs":"A tightened threshold produces failures on pages that real users would find acceptable, and the team has to be willing to treat a budget breach as work rather than noise. A loosened threshold costs you the external reference: the finding no longer maps to a published boundary, so \"we pass\" means only that you cleared your own bar. Either direction breaks comparability with earlier runs, so change the value deliberately and note when you did, or a trend line will show an improvement that was really an edit.","customGovernanceNotes":"The Standard value is a transcription of a published web performance boundary, which is precisely why it is worth keeping when the audience for the result is external. A Custom value is your performance budget and should come from wherever that budget is agreed and reviewed, with the reasoning recorded — a threshold loosened once during a bad release tends to stay loosened. Because this is the only judged number on the check, it deserves an owner.","customExamples":"A team with a published 2-second budget sets `maxLcpMs` to `2000`, so the lab check fails before field data would and the budget is enforced in the pipeline rather than in a monthly review. A media site with an intentionally heavy interactive feature sets `maxLcpMs` to `4000` on that page only, using the check as a regression detector while keeping the default everywhere else. A team preparing an external performance report keeps `2500` unchanged, because the value of the result there is that the boundary is not theirs.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"url","url":"https://example.com","validations":["page-load-speed"]},"agentContractCustom":{"type":"url","url":"https://example.com","validations":[{"id":"page-load-speed","parameters":{"maxLcpMs":2500}}]},"defaultClients":null},{"modelVersion":1,"id":"visual-diff","slug":"nothing-changed-since-last-time","name":"Visual Diff Detection","aka":["visual regression","screenshot comparison","change detection","page drift"],"subjectType":"url","category":"change-detection","severity":"recommended","description":"Optional monitoring check for pages that should not change. Compares the current screenshot against the previous capture of the same URL and viewport; fails when a meaningful difference is detected so a human can confirm whether the change was intended. Requires a prior capture — the first run always passes. Best used on a recurring schedule.","executionKind":"visual","checkLabel":"Nothing changed since last time","checkValue":"A page can change without anyone shipping a change: a CMS edit, an expired asset, a third-party widget that updated itself. Comparing each capture against the last turns that into a finding instead of a discovery.","hasCustomConfig":true,"requiresConfiguration":false,"price":{"unitCredits":5,"unit":"per_capture","captureCount":3,"captureMailboxes":3,"captureCredits":1,"configuredCredits":15},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":"https://app.arbiterqa.com/validations/visual-diff/custom","parameters":[{"name":"comparisonCriteria","severity":"required","standardDefault":"Report any visually significant layout, branding, or content changes compared to the previous screenshot for this URL and viewport.","formatSummary":"non-blank-string"}],"standards":[],"runStats":{"runCount":93,"failureRate":0.15053763440860216,"topFailureCause":null,"asOf":"2026-08-16T20:54:32.705Z"},"content":{"id":"visual-diff","slug":"nothing-changed-since-last-time","aka":["visual regression","screenshot comparison","change detection","page drift"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"change-detection","detects":["a CMS edit nobody shipped","an expired or removed asset","a third-party widget that updated itself","unintended layout drift between releases"],"commonlyPairedWith":["logo-usage","no-lorem-ipsum","font-size-body-min-max","page-load-speed"],"triggersWhen":["a page is watched on a schedule","a release goes out","a third-party script or embed is in use"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Use this on pages whose appearance is a commitment: a signed-off landing page, a pricing table, a regulated disclosure, a campaign destination you are paying to send traffic to. Its value is highest on a schedule rather than on demand, because the changes it catches are the ones nobody announced — a CMS edit, an expired asset, an embed that updated itself overnight. It needs a previous capture of the same page at the same width to compare against, so the first run establishes the baseline and the second one starts earning.","whenNotToUse":"Do not point it at pages that are supposed to change: a homepage with rotating hero content, a feed, a personalised dashboard, anything with a carousel or a live counter. On those, every run reports a difference and the check becomes noise you learn to dismiss. It is also the wrong tool for verifying an intended redesign — after a deliberate change, the comparison will fail by definition, and what you want then is a fresh baseline rather than a finding.","failureMeaning":"A failure means this capture differs visibly from the last one taken of the same page at the same width, and the finding describes what moved. It is a neutral report, not a defect claim: the change may be exactly what someone intended and forgot to mention. That is the point — it converts a silent change into something you have to look at once, which is cheaper than discovering it from a customer.","thresholdRationale":"One parameter carries the check: `comparisonCriteria`, a written instruction rather than a numeric tolerance. Its Standard default asks for any visually significant layout, branding or content change compared to the previous screenshot for this URL and viewport — significance is judged rather than counted, which is why there is no pixel-percentage dial to turn. That is deliberate: a percentage threshold treats a shifted legal disclaimer and a re-compressed background photo as the same size of event, and they are not.","customWhenWarranted":"Override `comparisonCriteria` when you know which parts of the page you actually care about, or which parts always move. Naming a region — \"compare the pricing table and the header; ignore the testimonial carousel\" — turns an unusable check into a usable one on pages that are partly dynamic. It is also the way to raise sensitivity where drift matters most, for example asking that any change to legal or price text be reported however small, while allowing photographic content to vary.","customWhenToStayStandard":"Stay on Standard for pages that are genuinely static, where the honest answer is \"tell me about anything that moved\". Keep the default when you are establishing a baseline across many pages at once and do not yet know which regions are volatile — run it broadly first, then write criteria only for the pages that prove noisy. If a page moves on every run no matter how you word the criteria, the right answer is usually to stop watching that page rather than to keep refining the sentence.","customTradeoffs":"Every exclusion you write is a region that can now break silently, and exclusions tend to be written in a hurry after a noisy run — the carousel you ignored is also where the campaign's main call to action lives. Narrowing to named regions likewise means a change anywhere else goes unreported, which is the opposite of what a change detector is for. The more conditional your criteria, the more the verdict depends on interpretation, and the less two runs a month apart can be compared with confidence.","customGovernanceNotes":"The Standard criteria are written so the check means the same thing on any page without setup, which is what makes a series of results comparable over time. Custom criteria are a statement about one page's structure and belong with whoever owns that page, reviewed when the page is redesigned — criteria describing a layout that no longer exists will pass a broken page happily. Because this check's output is often used as evidence that a page did not change, record when the criteria were last edited: a comparison is only as trustworthy as the instruction behind it.","customExamples":"A pricing page with a rotating customer-logo strip sets `comparisonCriteria` to compare the plan cards, prices and header while ignoring the logo strip, so the check stays quiet until a price moves. A regulated disclosure page raises sensitivity by asking that any difference in body or legal text be reported however minor, while allowing image re-compression to pass. A campaign landing page under active editing narrows the criteria to the hero headline, the form and the call to action, accepting that changes further down the page will not be reported until the campaign settles.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"url","url":"https://example.com","validations":["visual-diff"]},"agentContractCustom":{"type":"url","url":"https://example.com","validations":[{"id":"visual-diff","parameters":{"comparisonCriteria":"Report any visually significant layout, branding, or content changes compared to the previous screenshot for this URL and viewport."}}]},"defaultClients":null},{"modelVersion":1,"id":"email-images-off-legibility","slug":"still-works-with-images-off","name":"Email still legible with images off","aka":["images blocked","images disabled","Outlook images off","image blocking"],"subjectType":"email","category":"accessibility-compliance","severity":"optional","description":"With images blocked — what Outlook shows every recipient who has not added you to their Safe Senders list — the email must still convey what it is offering and give the reader a way to act. Requires the Images have usable ALT text check, which supplies the free half of the same question.","executionKind":"visual","checkLabel":"Still works with images off","checkValue":"Images blocked is what Outlook shows every recipient who has not added you to Safe Senders. This asks the harder question alt text alone cannot: with them off, does the email still say what it is offering and give the reader a way to act?","hasCustomConfig":false,"requiresConfiguration":false,"price":{"unitCredits":5,"unit":"per_capture","captureCount":2,"captureMailboxes":2,"captureCredits":20,"configuredCredits":10},"schemaStandardUrl":"https://www.schemafirst.org","customPublicUrl":null,"parameters":[],"standards":[{"setId":"cold-outreach-maximum","setName":"Cold outreach — maximum","category":"cold-outreach","tier":"maximum","severity":"optional","rationale":"Answers one question: with images blocked, does your email still make sense? That matters most in exactly the inboxes cold outreach lands in — corporate Outlook blocks images by default, so if your one image carries the message, your prospect sees nothing.\n\nThis is a model call and an explicit opt-in, which is why it lives in this tier. It runs alongside the alt-text check, which supplies what a recipient sees in place of a blocked image.","parameters":null},{"setId":"marketing-maximum","setName":"Marketing email — thorough","category":"marketing","tier":"maximum","severity":"recommended","rationale":"With images blocked, does your email still make its offer and give the reader a way to act?\n\nOutlook blocks images by default until you are on the Safe Senders list, and marketing email puts the offer inside the image — so this tells you what a large share of your audience actually receives, rather than what you designed.\n\nIt is a different question from alt text, which confirms an attribute exists. This reads your whole email as a reader with images switched off would experience it, and asks whether the message survives the trip.\n\nAn opt-in add-on that runs alongside the alt-text check and costs a model call, which is why it lives in this tier. The call is text-only — no images are fetched, and no capture is taken.","parameters":null},{"setId":"transactional-maximum","setName":"Transactional email — thorough","category":"transactional","tier":"maximum","severity":"recommended","rationale":"Answers one question: with images blocked, can your customer still get what they came for?\n\nThat matters more for transactional mail than for a campaign, and in exactly the inboxes it lands in — Outlook blocks remote images until you are on the recipient's Safe Senders list, which for a receipt from a shop they bought from once you very often are not. If your order number, tracking link or verification code is inside an image, that customer sees nothing.\n\nMost transactional email passes this easily: about 88% of the mail we checked keeps the order details in text. It is here for the roughly one sender in five who does not — for them it is the difference between a working receipt and a blank one.\n\nIt reads your whole email as a reader with images switched off would experience it, which is a different question from whether alt text exists. It is an opt-in add-on that runs alongside the alt-text check and costs a model call, which is why it lives in this tier.","parameters":null},{"setId":"operational-maximum","setName":"Operational email — thorough","category":"operational","tier":"maximum","severity":"recommended","rationale":"Answers one question: with images blocked, can your user still get what they came for?\n\nIt belongs in this tier for an honest reason — **on the operational mail we measured, it passes.** Every one of 52 real service notices kept its substance in text, with a median of around 1,500 characters surviving with every image removed. That is a property of the category rather than luck: a maintenance notice is a schedule and a policy update is an explanation, and neither payload has a natural home inside a graphic the way a product shot or a receipt total does.\n\nSo do not buy this tier expecting this to be the check that earns it. It is here for the sender who knows their own template is the exception — the one that renders the affected-region list as an image, or puts the effective date inside a header graphic. For them it is the difference between a notice that works in Outlook and one that arrives blank, because Outlook blocks remote images until you are on the recipient's safe-senders list, which for a service notice you very often are not.\n\nIt reads your whole email as a reader with images switched off would experience it, which is a different question from whether alt text exists. It is an opt-in add-on that runs alongside the alt-text check and costs a model call, which is the other reason it lives in this tier.","parameters":null}],"runStats":null,"content":{"id":"email-images-off-legibility","slug":"still-works-with-images-off","aka":["images blocked","images disabled","Outlook images off","image blocking"],"reviewedBy":"ArbiterQA","reviewedAt":"2026-08-14","riskDomain":"accessibility-compliance","detects":["an email that says nothing with images blocked","an offer that exists only inside an image","no route to act when images do not load"],"commonlyPairedWith":["email-image-alt-text","email-cta-button-visible","email-accessibility","email-hero-image-renders"],"triggersWhen":["an image-led campaign is built","a first-touch or cold send goes to a new list","a template is certified for reuse"],"prerequisiteOf":[],"supersedes":[],"whenToUse":"Run this on image-led campaigns and on any first send to a new audience. Images blocked is what Outlook shows every recipient who has not added you to Safe Senders, so this is not an edge case — it is the default experience for a meaningful share of business inboxes on the send that matters most. It asks the harder question alt text alone cannot: with images off, does the email still say what it is offering and give the reader a way to act?","whenNotToUse":"Skip it on text-led mail that barely uses imagery, where the answer is obviously yes and the check spends budget confirming it. It is also not a substitute for the alt-text check — that one finds missing and useless alt values across every image cheaply, while this one judges the resulting experience as a whole. If you have not yet fixed known alt-text failures, run that check first: this one will simply tell you the consequence of them.","failureMeaning":"A failure means that with images blocked, the message does not communicate its offer or does not present a usable way to act on it. That is the strongest form of image-dependency finding, because it does not depend on any single asset being broken — the email is working exactly as built and still saying nothing. The recipients affected are precisely the ones least familiar with you, since they are the ones who have not yet marked you as safe.","thresholdRationale":"This check has no tunable thresholds. It is a rendered judgement about the message with images blocked, and there is no numeric limit or configurable list that would meaningfully calibrate \"does this still communicate\" — the answer is holistic by nature. The variables available are which clients and widths you render, which are job settings rather than parameters.","customWhenWarranted":"Never, since this check exposes no Custom Parameters; its public custom page redirects to the Standard page. The configurable neighbours are the alt-text check, which has both a placeholder list and an opt-in visual review.","customWhenToStayStandard":"Always — Standard is the only behaviour available. What you can decide is scope: which sends this runs on, and whether the cheaper alt-text check is the better instrument for routine volume.","customTradeoffs":"There is nothing to configure and therefore nothing to trade. The real trade-off is between cost and depth: this check costs more than the source-level alt-text check and answers a question that one cannot.","customGovernanceNotes":"Because nothing is configurable, there is no local policy to own here. Where the result is used as accessibility or quality evidence, what matters is recording which sends it was run on, since an image-led campaign and a text newsletter give very different weight to the same verdict.","customExamples":"There are no override examples, as the check has no parameters. In practice teams reserve it for image-heavy campaigns and template certification, and rely on the alt-text check for everyday coverage.","standardGovernance":"Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.","author":"ArbiterQA"},"agentContractStandard":{"type":"email","validations":["email-images-off-legibility"]},"agentContractCustom":null,"defaultClients":{"desktop":["gmail_chrome","outlook_chrome"]}}],"count":30}