Where the RDP Pattern Came From — DMARC as Precedent for Autonomous Execution Authorization

Whenever a team describes a new architectural pattern for a hard problem — authorization at the moment before execution, evaluated against merchant-authored policy, cryptographically attested, rolled out from monitoring to enforcement over weeks — a reasonable person asks the reasonable question:

Does this architectural shape have precedent, or is it just an interesting idea?

It's a fair thing to ask. The Runtime Decision Point pattern that Aiyo is built around, our @aiyoplane/mcp-authz reference implementation, and the Shadow Mode → Enforce onboarding discipline we use for the merchant surfaces we ship into — all of it is genuinely new to the autonomous-execution substrate. But the underlying architectural shape is not new to the internet. A pattern with the same essential structure has been deployed across the global email ecosystem for more than a decade, at a scale measured in billions of mailboxes and enormous daily message volumes.

That protocol is DMARC — Domain-based Message Authentication, Reporting & Conformance. Published as RFC 7489 in 2015 and in production deployment since 2012, DMARC is the mechanism by which a domain owner tells receiving mail systems what to do with messages that claim to originate from the domain but fail authentication. It's the reason a message from @your-bank.com that isn't actually from your bank tends to be rejected at the receiving server or quarantined to spam rather than delivered to the inbox with a green checkmark. Major mailbox providers, including Google, Microsoft, Yahoo, Fastmail, and Proton, support and enforce DMARC policies at their receiving infrastructure. By early 2013 — a year into production deployment — DMARC.org reported the standard protecting roughly 60% of the world's consumer mailboxes and mailbox providers rejecting more than 325 million messages in November and December 2012 alone based on DMARC checks. A 2026 Internet Society Pulse measurement of 99,300 domains found 58.1% publishing DMARC policies with 64% of those in enforcement modes — meaningful deployment across the internet, and continuing to grow.

Architecturally, DMARC behaves like a policy gate at the email execution boundary. If we look at it structurally rather than as an email-specific artifact, the pattern is precisely the shape Aiyo applies to autonomous consequential actions. We think that convergence is worth naming out loud — both because it's a claim we can make in writing with a straight face, and because it grounds Aiyo's architecture in over a decade of production evidence rather than positioning it as a bet the industry has never seen before.

What DMARC actually is, in architectural terms

Set aside the email-specific machinery for a moment. Under the mail headers and the receiver-side quirks, DMARC does five things:

1. Sender-authored policy, published in a canonical location. The domain owner publishes a policy at a well-known DNS record (_dmarc.example.com) declaring how mail servers should treat messages that claim to originate from the domain. The policy is authored by the party being protected — the sender's domain owner — not by the receiver, not by a third-party service, not by the mail-transport protocol itself. The receiver applies the policy but does not author it.
2. Cryptographic authentication evidence evaluated against the message. The receiving server checks two independent authentication signals: SPF (does the sending IP have permission to send for this domain?) and DKIM (is the message body signed with the domain's published key?). DKIM in particular provides cryptographic evidence of message authenticity — the signature travels with the message and can be independently verified against the sender domain's published public key. DMARC then requires that either signal align with the sender's declared domain; both signals failing is what triggers policy enforcement.
3. Ternary requested disposition at the boundary immediately before delivery. The policy requests one of three receiver actions: p=none (deliver anyway; report the failure), p=quarantine (deliver to the spam folder; report), or p=reject (bounce the message; report). The receiver applies the requested disposition locally, in the narrow window between the message arriving and it being handed to the recipient's mailbox. The disposition itself is a receiver-side outcome, not a portable cryptographic artifact.
4. Aggregate reports back to the policy author. The receiver sends daily reports (the rua= address in the DMARC policy) back to the sender domain owner summarizing what messages were seen, which passed authentication, which failed, and what disposition was applied. The policy author gets an audit trail of receiver decisions taken under their published policy, from every reporting receiver that observed traffic claiming to be from them.
5. A mechanism for staged enforcement. RFC 7489 explicitly provides pct as a mechanism for progressive rollout: a domain owner can begin with p=none and use pct to apply a policy to a fraction of failing traffic before moving to full quarantine or reject. The RFC gives operators the mechanism; large-scale deployments have used it to onboard cautiously without disrupting legitimate mail flow.

The typical rollout discipline that emerges from those mechanisms is a staircase: start at p=none (monitoring), watch reports for weeks, fix any legitimate senders that fail authentication, escalate to p=quarantine; pct=25 or similar partial enforcement, then p=quarantine, then p=reject. This isn't a mandated sequence — the RFC provides the mechanism, not the schedule — but it's the shape careful operators tend to converge on when they want production rollout with recovery windows built in.

Now translate DMARC row-by-row into the Runtime Decision Point pattern

Here is the mapping. Every row is a real structural correspondence, not a metaphor:

DMARC (email delivery)	Aiyo's Runtime Decision Point (autonomous consequential actions)
Sender's policy authored at _dmarc.example.com	Merchant's policy authored in the Aiyo dashboard (or via API)
Cryptographic authentication of the incoming artifact: DKIM signature bound to the message body, verifiable against a published domain key	Cryptographic attestation of the outgoing decision: Ed25519-signed execution receipt bound to the specific action, verifiable offline against a published JWKS
Additional alignment signal: SPF (does the sending IP have permission to send for this domain?)	Evidence signal set: identity, policy match, authority chain, budget check, approval state, on-rail settlement proof, arbitrary merchant-declared inputs
Ternary requested disposition: p=none / p=quarantine / p=reject, applied receiver-side	Ternary verdict issued at the composition point: ALLOW / ESCALATE / BLOCK (or in the reference implementation: ALLOW / DENY, with ESCALATE as a first-class product surface)
Boundary: the receiving mail system, immediately before delivery	Boundary: the merchant's execution surface, immediately before the consequential action runs
Decision output: a local receiver-side disposition. Not itself a portable, cryptographically signed artifact that travels beyond the receiver.	Decision output: a portable authorization receipt that downstream systems can independently verify against the published JWKS, with no round-trip required at verification time
Evidence lineage: rua= aggregate reports back to the domain owner summarizing dispositions taken. Lineage terminates at the receiving mail system.	Execution lineage: the receipt binds intent → authorization → (where applicable) settlement → execution → outcome into a single signed record that can carry across downstream systems, plus a merchant dashboard with decision-event log and structured reason codes
Rollout mechanism: RFC-provided pct for progressive enforcement (p=none → partial quarantine → full quarantine → reject)	Rollout mechanism: Shadow Mode → Enforce (the Aiyo Express onboarding pattern, with partial-enforcement modes between the two)
Alignment mode: relaxed vs. strict — how tightly the authentication signal must match the declared domain	Policy strictness: merchant-configured evaluation depth — which evidence signals are required, and to what tolerance
Actor treatment within its domain: a human at a laptop, a marketing platform, a transactional-email service, a script — all subject to the same policy evaluation	Actor-agnostic by architectural design: a human-initiated action, an agent-initiated action, and a machine-to-machine action all run the same primitive
Transport indifference: any receiving mail system — Google, Microsoft, Yahoo, Fastmail, Proton, on-prem — applies the sender's declared policy to the artifact it received	Rail-agnostic and wallet-agnostic by architectural design: the policy gate evaluates the relevant evidence at the boundary rather than making the underlying transport, wallet, or provider the authorization primitive. Open Payments, x402, Machine Payments Protocol on Tempo, Stripe / Shopify Payments — same authorization contract, same receipt shape.

The pattern is not new to the internet. It's new to the specific substrate Aiyo occupies: consequential actions taken by autonomous systems, evaluated at the moment before execution, with the decision itself carried forward as a portable, independently verifiable artifact. The last clause is where Aiyo materially extends what DMARC does — a point worth its own treatment below.

The two invariants DMARC satisfies, and why the pattern generalizes

In an earlier post we wrote up the two invariants any composition point for the Runtime Decision Point must satisfy:

1. One authorization decision per consequential action. Not one per session, not one per workflow, not one aggregated across multiple actions.
2. The decision must occur strictly between intent and execution. Not before the intent is knowable; not after the action has already run.

DMARC satisfies both. One policy evaluation per delivered message. The evaluation occurs after the message arrives at the receiver (intent is fully known: sender-claimed domain, message body, sending IP, DKIM signature) and before the message is handed to the recipient's mailbox (delivery has not yet happened; if the requested disposition is reject, the message never reaches the mailbox at all).

The invariants aren't Aiyo-specific. They're properties of any well-formed authorization gate for consequential actions. DMARC's designers made the same architectural choice against the same invariants — for a different substrate, twelve years earlier. That the same invariants produce the same architectural shape when applied to two different substrates is not a coincidence. It's evidence the shape is right.

Where Aiyo materially extends what DMARC does

This is the part of the argument that carries the most weight, because it's the part that turns "Aiyo is like DMARC" — a claim we do not want to make in the aggressive form — into a claim about a specific architectural extension. DMARC governs a well-defined execution surface (email delivery) with a well-defined artifact format (SMTP messages) and a well-defined moment of arrival at the receiver. The Runtime Decision Point pattern, generalized beyond email, has to handle four things DMARC does not, and those extensions are what make the RDP genuinely new architecture rather than a rebadging of the precedent.

1. A portable authorization receipt, not just a receiver-side disposition. This is the most important extension. DMARC produces a local receiver disposition and reports it back to the sender in aggregate. The disposition itself is not a portable, independently-verifiable artifact that travels with the message. Aiyo's execution receipt does travel: it is an Ed25519-signed, structured attestation of the full runtime decision — intent, policy version, evidence signals evaluated, verdict, actor attribution, timestamp, and (where applicable) settlement resource ID — that any downstream system can independently verify offline against the published JWKS. That's a real architectural distinction. It's why Aiyo is not simply DMARC for agents; the portable receipt makes the authorization decision addressable outside the boundary at which it was made.

2. Cross-system authorization lineage. DMARC's evidence lineage terminates at the receiving mail system's disposition. Autonomous execution isn't like that: one authorized action often kicks off downstream actions in other systems that need to verify the original decision was made under the merchant's policy, at the specified time, with the specified evidence. The portable receipt is what makes cross-system lineage work — a system that receives the receipt can verify it against the published JWKS without any coordination with Aiyo or the merchant.

3. Settlement evidence as a first-class evidence signal. DMARC's authentication signals are cryptographic-alignment checks (SPF, DKIM). Neither answers "did the economic event actually occur on the rail?" because email delivery has no economic event. Aiyo's RDP treats verified on-rail settlement as one of its first-class evidence signals — the strongest one, where money is the consequence. Verified on Open Payments, x402 on Base, MPP on Tempo, and observed on Stripe / Shopify Payments. The evidence signal has no DMARC analog because email needed no equivalent.

4. Multi-signal composability across an open set of evidence signals. DMARC evaluates a fixed two-signal input (SPF, DKIM), with the policy specifying how strictly each must align. Aiyo's RDP composes an open set of merchant-declared signals — identity, policy version, authority chain, budget check, approval state, settlement proof, arbitrary webhook responses from upstream systems. Merchants declare which signals are required for which action types, and the RDP composes them into a single decision per invocation.

Why this precedent matters

Two reasons. Both practical, neither romantic.

First: DMARC provides evidence that this kind of boundary architecture — policy authored by the protected party, evidence evaluated at the point of execution, a requested disposition at a well-defined boundary, feedback back to the policy author, and a mechanism for staged enforcement — can operate at internet scale. That's a genuinely different claim than "DMARC proves Aiyo will work." It's a claim about the durability of the architectural pattern itself, grounded in more than a decade of deployment across the global email ecosystem.

Second: DMARC is the working evidence that the operational discipline we ship with Aiyo Express — Shadow Mode before Enforce, with partial-enforcement modes in between — is a defensible sequence rather than an isolated design choice. RFC 7489 gave email operators the mechanism (pct) for progressive rollout because production authorization rollouts need recovery windows built in. Two independent designs converging on the same operating shape, against the same architectural invariants, is a signal the discipline is correct. Aiyo did not need to invent this. Aiyo needed to recognize the precedent and apply it.

That last point is what makes the DMARC precedent useful beyond marketing. When we design future Aiyo surfaces — additional rail adapters, additional composition points, additional escalation ladders for new merchant categories — we can ask what does the DMARC-shaped analog to this look like? and reason from a well-understood reference. The Runtime Decision Point pattern is not a private Aiyo invention. It's an internet-protocol shape Aiyo is generalizing to a substrate the earlier pattern did not need to address.

The one-sentence version

The Runtime Decision Point is an authorization-boundary pattern for autonomous consequential actions: policy authored by the protected party, evidence evaluated at the point of execution, a decision made before the action runs, and a cryptographically verifiable record of that decision. DMARC demonstrates the same architectural discipline for email delivery; Aiyo generalizes it to autonomous execution, and extends it with a portable receipt that turns the decision itself into a first-class artifact.

Where this shows up in Aiyo's engineering practice

• The @aiyoplane/mcp-authz reference implementation is a concrete instance of the boundary-authorization pattern applied at the MCP tool-call boundary. Merchant-authored policy (the reference policy.example.json). Evidence signals (action type, target, amount thresholds; extensible). Ternary verdict at the composition point. Portable signed execution receipt (Ed25519, v2. format). Fail-closed defaults. The composition point differs from DMARC's — a tool-call boundary rather than an inbound-message boundary — but the architectural discipline is the same.
• The Aiyo Express onboarding sequence starts every merchant in Shadow Mode — the direct analog of p=none. Merchants observe the decisions Aiyo would make against their policy without any action being taken. When they've watched a policy-full cycle of orders and confirmed the verdicts match their intent, they enable Enforce — the direct analog of p=reject. Partial-enforcement modes (analog of p=quarantine; pct=25) sit between them for merchants who want a graduated rollout.
• The published JWKS at api.aiyoplane.com/.well-known/aiyo-jwks.json is the direct analog of a DKIM public-key record. Any receiver of an Aiyo execution receipt can verify it offline against the published key, with no round-trip to Aiyo required at verification time. Key rotation follows the same discipline DKIM key rotation follows — publish new keys, retire old keys after the rotation window, verifiers cache the JWKS and refresh on cache miss.
• The offline verifier is a shipped package: @aiyoplane/verify on npm (also available as brew install aiyoplane/tap/aiyo). Single command to verify a receipt against the published JWKS with no coordination with Aiyo. This is what turns the portable-receipt argument into working software any downstream system can install and use. The full list of shipped Aiyoplane surfaces lives on the Trust page.
• Aiyo's rail-agnostic settlement adapters — Open Payments, x402, MPP on Tempo, Stripe / Shopify Payments observation — are equivalent to DMARC's transport-agnosticism. The evidence signal is normalized regardless of which underlying rail produced it. The verdict shape is the same.

Kick the tires

• DMARC as a reference: RFC 7489 (DMARC), RFC 6376 (DKIM), RFC 7208 (SPF). Reading the RFCs alongside Aiyo's Reference Architecture is a fast way to see the isomorphism directly.
• Aiyo's Reference Architecture: the corresponding invariants and composition rules for the Runtime Decision Point, applied to consequential actions rather than email delivery. Available to design partners and to investors on request.
• Aiyo's Governance Pattern Library catalogs patterns that surface across authorization gates for autonomous execution, including the two invariants any composition point must satisfy and the Shadow Mode → Enforce escalation ladder. Also available to design partners.
• The MCP tool-call boundary as a concrete instance: the MCP-authz reference implementation composes the RDP above one specific tool-invocation protocol. The DMARC pattern applies at that boundary. It applies at every other boundary Aiyo composes above.

If you're building agent infrastructure whose agents perform consequential actions, and the DMARC-shaped precedent lands for you the way it landed for us — clean, well-precedented, generalizing an internet-scale pattern to a new substrate — we'd like to talk.

Verify First. Execute Second.