Email for Agents · September 26, 2026

An Email Address Is an Agent's First Identity

AI agent identity starts with an email address. What a mailbox proves, what DKIM and DMARC never check, and what A2A, OAuth and AP2 still leave to email.

Before an agent can act in its own name anywhere on the open web, a service sends it an email. The signup confirmation, the six-digit code, the password-reset link, the renewal notice and the reply from a person all route to one address, and whoever reads that mailbox controls every account registered to it. In practice, AI agent identity starts with email, long before any agent-specific protocol is involved, and the email address is the weakest credential in the stack.

The standards already concede the point. NIST SP 800-63B-4 forbids email as an authenticator and, in the next sentence, exempts the recovery codes that make a mailbox the reset path for everything else. This piece tests that claim against the identity work under way now, from A2A and OAuth delegation to workload identity, “know your agent” and agent payments. It sets out what an email address proves and what it does not, reports a DMARC measurement of 30 service domains taken for this article, including our own domain’s weaker result, and ends on what a stronger agent identity needs that a mailbox cannot supply. For the mechanics of reading a code out of an agent’s inbox, read signup and verification codes in an agent’s inbox.

A mailbox is the root credential under every account an agent opens

An email address is the identifier almost every service accepts, the channel it uses to recover the account, and the one value that outlasts every API key issued against it. That makes it the first durable identity an agent gets, whether or not anyone designed it that way.

The standards community already treats email as too weak to authenticate with and too useful to stop using for recovery. NIST SP 800-63B-4 says, in its section on out-of-band authenticators, that “Email SHALL NOT be used for out-of-band authentication”, citing access using only a password, interception at intermediate mail servers, and rerouting through DNS spoofing. The next sentence carves out the case that matters here: confirmation codes “sent to validate email addresses or are issued as recovery codes” are “not authentication processes and not affected by the above prohibition.” The same document’s section on issued recovery codes lets an emailed code stay valid for up to 24 hours. The OWASP Forgot Password Cheat Sheet lists four reset methods and notes that URL reset tokens “are typically sent to the user via email”.

Email is not supposed to prove who you are when you log in, and it is exactly what proves who you are when you cannot. For a person, that fallback sits beside a phone number, a passkey and a face at a bank branch. An agent usually has none of those. Its mailbox is not one factor among several. It is the factor, and the reset path for every other credential the agent holds runs through it.

Durability comes from the same place. An API key belongs to one service and dies at rotation; an OAuth grant belongs to one client. The email address appears on every account and every thread a human later replies to. It is the join key across the agent’s whole footprint, which is the working definition of an identity.

The new agent protocols authenticate software, not the person

The protocols built for agents authenticate software, keys and operators. When they reach an account that belongs to someone, they fall back to a contact identifier to find it: an email address or a phone number.

The A2A specification, at version 1.0.0, describes an agent through an Agent Card carrying securitySchemes and securityRequirements, and cards “MAY be digitally signed” with JWS (section 8.4). Server identity is TLS: clients “SHOULD verify the A2A Server’s identity by validating its TLS certificate” (section 7.2). Client credentials are obtained “through an out-of-band process specific to the required authentication scheme” (section 7.3). A2A requires the server to “authenticate every incoming request” (section 7.4) but leaves identity itself to existing schemes: “Identity information is handled at the protocol layer, not within A2A semantics.” Its own sample Agent Card in section 8.5 hands that to Google’s OpenID Connect provider with the openid, profile and email scopes.

The MCP authorization specification, in its 2026-07-28 revision, is built on OAuth 2.1. Authorization servers and clients SHOULD support Client ID Metadata Documents, in which the client identifier is an HTTPS URL pointing at a JSON document, and Dynamic Client Registration “is deprecated and retained for backwards compatibility.” That identifies client software, not an agent instance. The OpenID Foundation’s October 2025 whitepaper says so directly: a dynamically registered client ID “is not a robust stand-alone workload identity”, and Client ID Metadata “is still insufficient as a workload identity or AI agent identifier.”

Payments make the pattern concrete. Visa’s Trusted Agent Protocol identifies the agent with a signature “based on the HTTP Message Signatures defined by RCF 9421 [and aligned with web-bot-auth]” (sic). It identifies the consumer with a Visa ID Token that may carry an obfuscated phone number, an obfuscated email address, or both: the phone_number and email claims are each optional (cardinality 0..1), and email is the “Obfuscated end user’s preferred e-mail address”, alongside a private email_mask claim. Because nothing arrives in the clear, the merchant “must also maintain a mapping table that can be used to match an obfuscated phone number or obfuscated email address to an actual phone number or email address of their account holder.” The Agentic Commerce Protocol checkout reference lets the agent pass optional buyer information when it opens a session, described as “Buyer information including first name, last name, email, and optional phone number.” Within that object, the phone number is the field marked optional. The protocol is maintained by OpenAI and Stripe and currently in beta.

The agent gets a key. The human is still located by a contact identifier, and email is one of the two these protocols offer. The cryptography sits on top of a mailbox or a phone number rather than replacing them.

What workload identity, delegation and KYA each add, and where each stops

Each serious effort solves one slice of the problem for one class of relying party. None gives an agent an address a stranger can reach, or a recovery channel for the accounts it already holds, which is why email persists underneath all of them.

Workload identity answers “what software is this”. The WIMSE charter defines a workload as “a running instance of software executing for a specific purpose”, and SPIFFE defines its ID as a string that “uniquely and specifically identifies a workload”, proven by an SVID “signed by an authority within the SPIFFE ID’s trust domain.” The OpenID Foundation paper names the limit: SPIFFE “fundamentally relies on knowledge and control of that infrastructure”, while an agent’s identity “must be portable and verifiable to a third party that has no visibility into its host environment.” A signup form on someone else’s website is exactly that third party.

Delegation answers “who is this acting for”. The draft OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents adds a requested_actor parameter to identify the agent and an actor_token to authenticate it. The OpenID Foundation paper describes the target as a token “containing two distinct identities: the user who delegated authority (e.g., in the sub claim) and the agent authorized to act (e.g., in the act or azp claim).” The draft is an individual submission, its latest revision dated 2025-08-25, and the datatracker lists it as expired. The direction is right, and the standard does not exist yet.

Web Bot Auth answers “who operates this traffic”. Cloudflare’s Web Bot Auth documentation verifies signed requests against a key directory at /.well-known/http-message-signatures-directory, and draws the distinction this whole piece turns on: “An agent that reaches your site is often not operated by the company that built it. A platform can run automations on behalf of many different end users, so the operator and the end user are not the same party.” The IETF webbotauth working group has one adopted document, draft-ietf-webbotauth-httpsig-protocol-00, last updated 2026-09-01. The other drafts it lists are individual submissions.

Payments answer “what was this agent allowed to buy”. Google announced AP2 in September 2025 and framed the gap as authorization, authenticity and accountability, because payment systems “generally assume a human is directly clicking ‘buy’ on a trusted surface.” The AP2 v0.2 specification requires that open mandates for human-not-present purchases “MUST include the agent’s public key as a cnf claim”, a real binding of authority to a key the agent holds. The same document says agent-to-agent delegation “is outside the scope of the current specification.” Its agent authorization framework opens with the reason for all of this: “Due to their non-deterministic processes, even well-behaving Agents need to have their behavior tightly constrained above what a normal authorization model would require of human users.”

KYA answers “who is accountable”. Sumsub defines Know Your Agent as “defining their identity, binding them to responsible entities (human or organizational)”, describes the chain it builds as “agent → verified user → face”, and gives the reason: “It is easy to create new agents or users, but hard to fake a face.” That is the strongest accountability claim in the set, and it is a service a relying party buys, not a property an arbitrary signup form can check.

Every row needs the relying party to adopt something first: a trust domain, an issuer, a key directory, a payment network, a vendor. Email needs only SMTP. That asymmetry is why the first identity an agent gets is still a mailbox.

What an email address proves about AI agent identity

An email address proves that someone could read mail sent to it at a particular moment. It does not prove who that someone is, that they are the same party tomorrow, or that the address never belonged to someone else.

OpenID Connect Core states the first half precisely. email_verified true means the provider “took affirmative steps to ensure that this e-mail address was controlled by the End-User at the time the verification was performed.” The same section says the relying party “MUST NOT rely upon this value being unique”, and section 5.7 goes further: iss and sub together “are the only Claims that an RP can rely upon as a stable identifier”, and “an Issuer MAY re-use an email Claim Value across different End-Users at different points in time.” The identity specification the web runs on declines to treat an email address as an identifier, and the web treats it as one anyway.

Sender authentication does not close the gap, because it authenticates a different thing. RFC 6376 says DKIM “permits a person, role, or organization that owns the signing domain to claim some responsibility for a message”, and “separates the question of the identity of the Signer of the message from the purported author of the message.” The signing identity “is not required to match an address in any particular header field.” DKIM even has a field named for this problem. The i= tag is the Agent or User Identifier, and the RFC says “the domain name portion of the AUID has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM.” A valid signature tells you a domain vouched for the message. The local part, the bit that names the agent, is the signer’s unchecked say-so.

DMARC ties the visible From domain to those checks and stops there. RFC 9989, published in May 2026 on the Standards Track and obsoleting RFC 7489, lists as out of scope “Authentication of entities other than domains, since DMARC is built upon SPF and DKIM, which authenticate domains” (section 2.4). Section 11.4 says display name attacks “are out of scope for DMARC.” A message from "Stripe Support" <billing@anything.example> can pass every check for anything.example. A human in a mail client sees the display name first, and so does a model reading a parsed message unless it is told otherwise.

Three weaknesses follow, and the thesis only survives if they are stated plainly:

1. Addresses are cheap. Anyone can create thousands, so an address is a poor basis for one-per-person limits, reputation or accountability.
2. The display name is free text. Nothing in the authentication stack constrains it, and it is the part both humans and models read.
3. Control is not identity. Mailbox control transfers with the password, the session cookie, a forwarding rule, or the credentials of whoever hosts the mailbox. NIST’s list of reasons to distrust email begins with “Access using only a password.”

Measured: whose verification mail an agent can authenticate

Of 30 service domains an agent is plausibly asked to sign up with, 29 publish a DMARC policy asking receivers to quarantine or reject mail that fails authentication. One publishes a policy that asks for nothing.

Method: on 2026-09-25 at 21:33 Eastern, we ran dig +short TXT _dmarc.<domain> against resolver 1.1.1.1 and again against 8.8.8.8 for the 30 organisational domains below. They were chosen before querying, as services a general-purpose agent is plausibly asked to open an account with or receive codes from. The two resolvers returned identical records. This is not a random sample, and it reads the organisational domain’s record, not the specific subdomain each service sends codes from, which can publish its own.

Three details in the raw records say more than the tally.

npmjs.com publishes p=quarantine; pct=5. Under RFC 7489, pct is the “Percentage of messages from the Domain Owner’s mail stream to which the DMARC policy is to be applied”, so a record asks a receiver on the old specification to quarantine about one failing message in twenty. RFC 9989 removed pct (Appendix A.6 and C.5.2), leaves it out of the valid tags in section 4.7 and keeps it in the registry only as “historic”, so a receiver that implements only the new specification has no sampling instruction to follow and reads the record as a request to quarantine every failure. The record carries no t= tag, the new specification’s replacement for test mode. The RFC’s own reason for the removal is that pct “was usually not accurately applied, unless the value specified was either 0 or 100”, and pct=5 is neither. The same DNS record therefore asks for different things depending on which RFC the receiver implements, and under either RFC the receiver may still choose its own handling: RFC 9989 says it “can choose to honor the Domain Owner’s requested message handling for validation failures, but it is not required to do so.”

heroku.com and slack.com publish no TXT record at their own _dmarc name. For both it is a CNAME to _dmarc.reject100.salesforce.com, so their policy is whatever that shared record says.

huggingface.co publishes p=none; sp=none. RFC 9989 defines none as “The Domain Owner offers no expression of preference.” A forged verification email claiming that domain carries no request from the owner to stop it, so whether it reaches an agent depends entirely on the receiving system’s own filtering.

The same query run against this site’s own product is less flattering. Live agent mail on Email for Agents is sent from agents.emailforagents.ai, which publishes p=none, and emailforagents.ai itself publishes no DMARC record, measured by the same method at the same time. By this measure an agent address on our shared domain is less protected against forgery than 29 of the 30 services it might sign up with. A counterparty deciding whether a message really came from one of our agents gets no enforcement from the domain to rely on today. The ownership, SPF and DKIM records a sending subdomain needs are covered in setting up an agent email subdomain; the DMARC record is not covered there.

Even the best case has a ceiling. A pass at a p=reject domain tells an agent that stripe.com vouched for the code. Mail from the agent tells a human, at most, that the agent’s host vouched for it. Neither says which agent sent it, or for whom.

Why this puts email infrastructure inside the identity problem

If the mailbox is the root credential, then the decisions that shape an agent’s inbox are identity decisions: who may read it, whether an address can be reissued, and what a recipient can verify about mail from it.

Read access is account-takeover capability. Anything that can read the inbox, or steer the agent that reads it, can complete a password reset for every account registered to the address. That is why a hostile message in the inbox is more than a content problem, as prompt injection by email sets out, and why a mailbox grant deserves the care given to a signing key. Seen from here, the MCP tool surface as a permission boundary is an identity control as much as a messaging one.

Address reuse is identity reuse. OpenID Connect warns that an issuer may give the same email value to different users at different times. For agents that are created and destroyed casually, that warning becomes an operating rule: an address that once belonged to an agent must never be issued to another, because the next holder receives the previous holder’s resets. Retiring an agent address should be permanent.

The handoff to a human is where identity is judged. When a person replies to an agent, they decide who they are dealing with from a display name and a domain. DMARC and DKIM say nothing about the first, and on a shared domain the second names the host rather than the agent or its operator. An honest agent address says it is an agent, and its operator is discoverable from it. That is a convention today, not a protocol.

Recovery has to be planned for the agent’s absence. Agents are paused, redeployed and abandoned. Accounts registered to an agent’s address keep sending resets, renewals and security notices after nobody is reading them. Whoever operates the agent owns that mailbox’s lifecycle the way they own a service account’s.

What a stronger agent identity needs that email cannot provide

A stronger agent identity needs five properties a mailbox lacks. The work read for this piece supplies parts of each, and none of it replaces what email does.

1. An identifier that is never reassigned. OpenID Connect’s iss plus sub is the model. An email address is reassignable by design.
2. Proof bound to a key, per request. AP2’s cnf claim, TAP’s signed requests and Web Bot Auth’s key directory all prove possession at the moment of use. Mailbox control proves possession at the moment a code was read.
3. A verifiable, accountable operator. Cloudflare’s operator-versus-end-user distinction and KYA’s binding to a verified human both address it. A mail domain names whoever hosts the mailbox, which is often neither.
4. Delegation that narrows as it passes. The OpenID Foundation paper warns that agents “spawning sub-agents or communicating tasks to other agents create complex authorization chains without clear scope attenuation mechanisms”, and AP2 leaves agent-to-agent delegation out of scope. Email has no notion of delegation at all. A forwarding rule hands over everything.
5. Revocation a relying party learns about. A mandate carries an expiry and a key can be pulled from a directory. A service holding an agent’s email address has no way to learn that the agent behind it was shut down.

What email keeps is reachability and recovery. Any stranger can write to an agent, and any service can get a code to it. None of the specifications cited here does that, and none binds an email address to an agent key in a way a relying party can check. That binding is the missing piece. Until it exists, treat an agent’s inbox as its root credential: one address per agent, never reissued, read access granted as narrowly as a signing key, and a DMARC policy at enforcement on the domain it sends from.

Sources

All read on 2026-09-25. DNS records were queried the same day, by the method above.

• A2A Protocol Specification, version 1.0.0 - Model Context Protocol, Authorization, revision 2026-07-28
• OpenID Foundation, Identity Management for Agentic AI (October 2025)
• OpenID Connect Core 1.0 - NIST SP 800-63B-4 - OWASP Forgot Password Cheat Sheet
• RFC 6376, DKIM Signatures - RFC 9989, DMARC - RFC 7489, DMARC (obsoleted) - RFC 7489 status page - Visa Trusted Agent Protocol specifications
• Agentic Commerce Protocol, Checkout reference - Agentic Commerce Protocol repository README - Google Cloud, announcing AP2
• AP2 specification, v0.2 - AP2 agent authorization framework - IETF WIMSE charter - SPIFFE concepts - draft-oauth-ai-agents-on-behalf-of-user
• Cloudflare, Web Bot Auth - IETF webbotauth working group documents - draft-ietf-webbotauth-httpsig-protocol
• Sumsub, Know Your Agent

research security permissions foundations

Keep reading

All guides · Documentation · Email for Agents