Transactional Email and Deliverability Posture: A Proposed Axis for Whether an AI Builder's App Can Reach a Real Inbox (August 2026)

Quick answer (August 2026). Transactional email and deliverability posture measures whether the app an AI builder generates can actually deliver mail to a real person's inbox. It sits underneath every feature builders demo casually: sign-up confirmation, password reset, magic link, receipt, invitation, notification. The gap this axis exists to expose is that a generated app can send mail perfectly during the build session and be structurally incapable of sending it to a single real user in production, because the default sending path several builders inherit is restricted to the project's own team addresses and rate-limited to two messages per hour. This is a proposed BuilderProof axis, not a scored leaderboard. Like every axis we propose it is designed to cover the five commercial builders we track across the August 2026 axis series, to be reproducible from published rules, and to stay open to public revision. The six-signal rubric follows.

The demo works because it is addressed to the only people it can reach

Most axes on this benchmark describe failures that are hard to see. This one describes a failure that is impossible to see, and the reason is worth stating precisely, because it is not a matter of luck or timing.

Several of the builders in scope generate applications on top of a hosted backend whose authentication service ships with a built-in email sender. That sender is documented, by the platform itself, as a convenience for getting started. Its restriction is not a soft one. Supabase's own documentation states that unless you configure a custom SMTP server, "Supabase Auth will refuse to deliver messages to addresses that are not part of the project's team", and gives the worked example that if an organization has the member accounts person-a@example.com, person-b@example.com and person-c@example.com, then "Supabase Auth will only send messages to these addresses." Everything else, in the documentation's own words, "will fail with the error message Email address not authorized."

Read that as a partition rather than as a limitation and the consequence becomes sharp. The population a developer tests with and the population that fails are disjoint by construction. When you build the app, you sign up with your own address. Your address is on the project team, so the confirmation mail arrives, every time, reliably. When a real user signs up, their address is definitionally not on the project team, so the mail is refused, every time, reliably. There is no flakiness here and no race to lose. The preview is guaranteed to pass and production is guaranteed to fail, and the two outcomes are produced by the same correct code path behaving exactly as documented.

The rate limit compounds it in a way that is easy to misread. The documented ceiling is "2 emails per hour with the built-in email provider", and that figure is not per user. It applies to the sum of combined requests project-wide across the sign-up, recovery and email-change endpoints, and the documentation notes you can only raise it with a custom SMTP setup. Two testers iterating on a sign-up screen will exhaust an hour's budget in about a minute.

We want to be careful and fair about what this is evidence of. It is not evidence that any builder is careless. The platform documents the constraint plainly and describes the default service as suitable for "building toy projects, demos or any non-mission-critical application," with no SLA on delivery or uptime, and it urges customers to configure custom SMTP for everything else. The open question this axis asks is a different one: when a builder generates an application on top of that default, does it tell the person who asked for the app that the email in it will not reach anyone? That is a property of the builder, not of the backend, and it is measurable.

The standard we score against

Deliverability is unusual among the things this benchmark measures, because the pass condition is set by third parties who publish it and change it. That makes it a better-anchored axis than most, not a worse one.

Google's sender requirements state that all senders must set up SPF or DKIM authentication for their sending domains, and that since February 1, 2024, senders of more than 5,000 messages per day to Gmail accounts must set up SPF and DKIM and publish a DMARC record for their sending domain, transmit over TLS, maintain valid forward and reverse DNS, keep spam rates below 0.3 percent as reported in Postmaster Tools, and support one-click unsubscribe on marketing and subscribed messages. The guidance recommends staying below 0.10 percent and never reaching 0.30 percent.

The deeper requirement, and the one that decides this axis, is alignment. DMARC does not merely ask whether a message passed an authentication check. RFC 7489 defines Identifier Alignment as the condition where "the domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both)," and specifies that a message satisfies DMARC only if at least one supported mechanism "produces a 'pass' result" and "produces that result based on an identifier that is in alignment." Relaxed mode requires the organizational domains to match; strict mode requires an exact match of the fully qualified domain names.

That definition has a consequence for generated apps that we have not seen stated anywhere in this category, so we state it here as the axis's central technical claim.

A shared vendor sending domain and a branded From address are mutually exclusive under DMARC. If a builder sends your app's mail through its own infrastructure and its own authenticated domain, the mail can pass SPF and DKIM cleanly while the From header shows the vendor. Your users see the vendor's brand on your password resets, and your own DMARC policy is irrelevant because your domain is not the one being evaluated. If instead the From header is rewritten to your domain while the authenticated domain remains the vendor's, alignment fails, and a receiver honoring your DMARC policy is entitled to reject or quarantine the message. Having both properties at once requires DNS records published on a domain the builder does not control. This is the deliverability form of a gap this lab has described before in a different setting: the feature is genuinely present, and it still does not do the thing the user assumed it did. Resend, one common destination for this work, states the requirement in one line: you must add and verify at least one domain to send emails.

What this axis measures, and what it does not

Three published axes touch email at the edges, and this one is scoped deliberately against all three.

Our auth and access-control posture axis scores whether the emitted authentication is sound: session handling, row-level isolation, password recovery as a security flow. It treats the recovery email as a step in that flow and asks whether the flow is correct. This axis asks whether the message at that step is physically capable of arriving, which is a question about transport and reputation, not about authorization.

Our benchmark's own reference brief already asks each builder for an email-campaign composer that sends through the builder's email integration. That is a feature-completion prompt: can the builder produce the composer. This axis is the downstream question the brief does not settle, which is whether anything the composer sends is deliverable.

Finally, this axis does not score marketing email, list hygiene, campaign analytics, template design, or open and click tracking. It is scoped to transactional mail, meaning messages a user's own action causes and a user is waiting for.

One boundary is worth naming rather than hiding. Not every builder in scope generates a backend at all. A tool that emits front-end components is answering a different question, and on this axis it should be recorded as out of scope for the signals that presuppose a server, not scored zero. Scoring absence as failure is how a rubric quietly punishes a product for being a different kind of product.

The six signals

We propose scoring this axis from six weighted signals summing to 100. Each is observable from the exported application and its published documentation, which keeps the axis reproducible without privileged access.

1. Production sending path (25). Does the generated app ship configured against a real transactional provider or a custom SMTP server, or does it ship on the platform's default test sender with its team-address allowlist and per-hour ceiling? This carries the heaviest weight because it is the difference between an application that can send mail and one that cannot, and because every other signal is moot if this one fails.

2. Domain authentication and alignment (20). Does the emitted configuration and documentation lead the user to a verified sending domain with SPF and DKIM published, a DMARC record, and a From address aligned with the authenticated domain per RFC 7489? Partial credit where a provider is wired but the From domain is left as the provider's shared domain, because that is a real and common intermediate state.

3. Constraint disclosure at generation time (15). When the builder produces an app whose email path cannot reach non-team addresses, does it say so in the build output, a checklist, or a pre-launch warning? Or does the user discover it from a support thread after their first real sign-up fails? We score the honesty of the handoff, not the presence of the limitation, because the limitation is the backend's and the handoff is the builder's.

4. Send-path robustness (15). Is the send performed off the critical request path, or inline, so that a slow provider becomes a slow sign-up and a failed provider becomes a failed sign-up? Are transient failures retried, is a resend idempotent rather than duplicating, and is a failure surfaced rather than swallowed?

5. Bounce, complaint and suppression handling (15). Does the emitted application consume delivery events from its provider and maintain a suppression list, or does it keep sending to addresses that have hard-bounced? This is the signal that decides whether an app's sending reputation survives its first year, and it is the one most likely to be entirely absent from generated code.

6. Environment separation (10). In development and test, do messages go to a sandbox, a catch-all, or a console log rather than to real recipients? An app that mails live customers from a staging branch has a correctness problem and a privacy problem at the same time.

Proposed posture levels

The six signals collapse into four levels for readers who want a placement at a glance, with the per-signal detail underneath for anyone who wants to dispute one line rather than the whole score.

• Level 0, undeliverable by default. The app ships on a test sender restricted to team addresses, or has no send path at all. The feature exists in the demo and cannot serve a user.
• Level 1, sends but unauthenticated. Mail leaves and reaches some inboxes, from a shared or unverified domain, with no aligned DMARC identity. Delivery is at the mercy of another tenant's reputation.
• Level 2, authenticated on your own domain. A verified sending domain, SPF and DKIM published, From aligned, a real provider configured. Mail arrives, and it arrives as you.
• Level 3, operationally durable. Level 2 plus suppression handling, retries off the request path, idempotent resends, and environment separation. The app is still deliverable after a year of real bounces.

Measurement protocol (v0.1)

Deliberately boring, so anyone can rerun it and challenge the result.

1. Generate one reference app per builder from an identical prompt containing exactly one email-dependent flow: sign-up with email confirmation, plus a password reset.
2. Record the vendor's email, SMTP and deliverability documentation with URLs and retrieval dates, since this behavior changes often.
3. Export the application untouched and read the send path in the emitted source: which provider, which From address, inline or queued, retried or not, suppression consumed or not.
4. From a clean account, attempt a sign-up with an address that is not associated with the project or its team, and record the observed result verbatim, including any error string.
5. Inspect the received message's headers, where one is received, for SPF, DKIM and DMARC results and for alignment between the authenticated domain and the RFC5322.From domain.
6. Publish the full transcript, the headers with recipient addresses redacted, and the per-signal scoring, so every line is open to revision.

Step 4 is the one that matters most and the one most likely to be skipped, because it is the only step that leaves the population the builder's own workflow can reach.

Why we are naming a pattern and not publishing placements

We are not publishing per-builder scores on this axis today, and we want to be explicit about why rather than leave a gap where numbers usually sit.

On August 21, 2026 this lab withdrew its June output-quality result set and the composite derived from it, because we could not produce the artifacts a published number requires. That decision has a consequence we intend to honor consistently: an axis proposal is a pre-registration, not a report. The rubric above has not been executed against the five builders, the levels have not been assigned, and a reader should not infer from the specificity of the protocol that a run has happened. It has not.

What the public materials do suggest, read symmetrically and dated to August 2026, is that the cohort would spread across the levels rather than cluster, which is the ordinary reason an axis is worth formalizing. Builders that generate a full stack on a hosted backend inherit that backend's default sender and its allowlist, and the interesting variable between them is how loudly they say so. Builders that emit front-end components have no generated send path to score. Builders that document a first-class integration with a transactional provider are structurally better placed on signals one and two and are not thereby better on signals four through six, which are about operational durability and are the ones no builder currently advertises.

Each of those is a hypothesis this axis exists to confirm or overturn with a reproducible run. Vendor behavior in this category shifts month to month, which is exactly why a fixed published rubric is more useful than a snapshot opinion.

Two open questions we cannot settle from documentation

Does the rate limit train a security regression? A developer who hits a two-per-hour project-wide ceiling while iterating on a sign-up screen has an obvious workaround available, which is to turn email confirmation off. If that is a common path, then an email-infrastructure limit is silently producing a permanent change in authentication posture, and the cost lands on an axis we already score. We can see the incentive clearly and we cannot measure its frequency without survey data or telemetry we do not have. We would rather name it as an open question than assert it.

How should an axis be dated when the score decays on its own? Every other axis on this benchmark measures a property of emitted code, which does not change unless the code changes. Deliverability is different. Domain reputation is an external moving variable governed by receivers who publish thresholds and revise them, so an application can pass on the day it ships and fail three months later with a byte-identical codebase. That means a placement on this axis needs a re-measurement cadence and a visible expiry that our other axes do not need. We do not think a single dated snapshot is honest here, and we are not yet sure what the right interval is.

How to contribute

BuilderProof axes are community-editable. The single most useful contribution on this axis is a transcript of step 4: which builder, which date, the exact address class you tested with, and the verbatim result when a non-team address attempted sign-up. Raw message headers showing SPF, DKIM, DMARC and alignment results are the second most useful, with recipient addresses redacted. Counter-evidence is as welcome as confirmation, and a correction that overturns a signal weight is more valuable to us than agreement. A proposed axis becomes a scored one when the reproducible runs exist.

BuilderProof is an independent, methodology-first benchmark of AI app builders. We score from published rules, cover the commercial builders in our tracked cohort, and keep every axis open to public revision.

BuilderProof Editorial Team. "Transactional Email and Deliverability Posture: A Proposed Axis for Whether an AI Builder's App Can Reach a Real Inbox (August 2026)". BuilderProof, August 2026. https://www.builderproof.org/benchmarks/transactional-email-deliverability-posture-axis-proposal-august-2026.

@misc{builderproof-transactional-email-deliverability-posture-axis-proposal-august-2026,
  title  = {{Transactional Email and Deliverability Posture: A Proposed Axis for Whether an AI Builder's App Can Reach a Real Inbox (August 2026)}},
  author = {{BuilderProof editorial team}},
  year   = {2026},
  month  = {aug},
  howpublished = {\url{https://www.builderproof.org/benchmarks/transactional-email-deliverability-posture-axis-proposal-august-2026}},
  note   = {BuilderProof, builderproof.org}
}