Hey HN, I built KeyID because I kept hitting the same wall: every AI agent that needs to sign up for a website needs a real email address, and there's no good free way to get one programmatically.
The problem: Agents need email for signups, verification codes, 2FA, and communication. You can use Gmail (manual setup, doesn't scale), disposable email APIs (get blocked), or paid services like AgentMail ($per mailbox).
What KeyID does: One API call → real email address. The agent generates an Ed25519 keypair, calls provision(), and gets an address on a shared domain pool. No API keys, no human in the loop.
From there agents can:
Send/receive email
Auto-extract verification codes from incoming messages
Follow verification links server-side
Track multi-step signup flows with browser state persistence
Get phone numbers for SMS verification
Generate TOTP 2FA codes
How it stays free: Shared rotating domain pool. We manage DKIM/SPF/DMARC, warm-up, and reputation. When a domain degrades, it rotates out. No per-mailbox cost.
MCP server (47 tools) — works with Claude, Cursor, Windsurf out of the box:
{"mcpServers":{"keyid":{"url":"https://keyid.ai/mcp"}}}
Also has JS (@keyid/sdk) and Python (keyid) SDKs for direct integration.
You don't explain how SMS works, via which provider (is it also a shared pool of numbers? Many virtual providers are flagged for MFA via such numbers)
Your privacy policy says you harvest/store 100% of all data that travels over your services including PII.. perhaps you could call this out more specifically. (IP addresses are PII in many jurisdictions, most people run agents on their home network)
You seem to assume the cost of running mail and routing infrastructure is $0 (only talk about $10/yr domain cost).
I’m willing to give you the benefit of the doubt on this. Because this sounds like a legitimately difficult problem to solve.
But what is the use case here? How often do agents need to get an email address? What’s the argument for letting agents create accounts? I can see letting an agent use my account, but why do they need their own?
And all of this has great legitimate uses, why would a domain degrade?
We're still figuring out the exact tiers above 1,000. The shared pool model keeps our marginal cost per account very low (domains cost ~$10/year and serve hundreds of agents), so we can afford to be generous. The likely path is a paid tier for higher volumes with dedicated domains and priority deliverability. But honestly, 1,000 accounts covers most use cases we've seen — even teams running agent fleets rarely need more than a few hundred active at once. If you're hitting the limit, reach out and we'll work something out.
Good question. A few layers: (1) Agents authenticate via Ed25519 challenge-response, so every account is tied to a keypair — no anonymous throwaway accounts. (2) We track per-agent reputation based on send patterns, bounce rates, and complaint signals. Agents that degrade domain reputation get throttled or suspended automatically. (3) The shared domain pool is the key incentive — if an agent spams, it hurts their own deliverability because the domain rotates out. The pool is a shared resource, so agents that abuse it lose access. It's a similar model to how shared IP pools work in transactional email services.
Hey HN, I built KeyID because I kept hitting the same wall: every AI agent that needs to sign up for a website needs a real email address, and there's no good free way to get one programmatically.
The problem: Agents need email for signups, verification codes, 2FA, and communication. You can use Gmail (manual setup, doesn't scale), disposable email APIs (get blocked), or paid services like AgentMail ($per mailbox).
What KeyID does: One API call → real email address. The agent generates an Ed25519 keypair, calls provision(), and gets an address on a shared domain pool. No API keys, no human in the loop.
From there agents can:
Send/receive email Auto-extract verification codes from incoming messages Follow verification links server-side Track multi-step signup flows with browser state persistence Get phone numbers for SMS verification Generate TOTP 2FA codes How it stays free: Shared rotating domain pool. We manage DKIM/SPF/DMARC, warm-up, and reputation. When a domain degrades, it rotates out. No per-mailbox cost.
MCP server (47 tools) — works with Claude, Cursor, Windsurf out of the box:
{"mcpServers":{"keyid":{"url":"https://keyid.ai/mcp"}}} Also has JS (@keyid/sdk) and Python (keyid) SDKs for direct integration.
Free for 1,000 accounts. Open source: https://github.com/KeyID-AI/KeyID
Happy to answer questions about the architecture, the domain rotation model, or anything else.
Your github is 404 (maybe it's private?)
You don't explain how SMS works, via which provider (is it also a shared pool of numbers? Many virtual providers are flagged for MFA via such numbers)
Your privacy policy says you harvest/store 100% of all data that travels over your services including PII.. perhaps you could call this out more specifically. (IP addresses are PII in many jurisdictions, most people run agents on their home network)
You seem to assume the cost of running mail and routing infrastructure is $0 (only talk about $10/yr domain cost).
I’m willing to give you the benefit of the doubt on this. Because this sounds like a legitimately difficult problem to solve.
But what is the use case here? How often do agents need to get an email address? What’s the argument for letting agents create accounts? I can see letting an agent use my account, but why do they need their own?
And all of this has great legitimate uses, why would a domain degrade?
What happens when you hit the 1,000 account limit? What's the pricing model after that?
We're still figuring out the exact tiers above 1,000. The shared pool model keeps our marginal cost per account very low (domains cost ~$10/year and serve hundreds of agents), so we can afford to be generous. The likely path is a paid tier for higher volumes with dedicated domains and priority deliverability. But honestly, 1,000 accounts covers most use cases we've seen — even teams running agent fleets rarely need more than a few hundred active at once. If you're hitting the limit, reach out and we'll work something out.
How do you prevent abuse? What stops someone from spinning up 1,000 accounts to send spam?
Good question. A few layers: (1) Agents authenticate via Ed25519 challenge-response, so every account is tied to a keypair — no anonymous throwaway accounts. (2) We track per-agent reputation based on send patterns, bounce rates, and complaint signals. Agents that degrade domain reputation get throttled or suspended automatically. (3) The shared domain pool is the key incentive — if an agent spams, it hurts their own deliverability because the domain rotates out. The pool is a shared resource, so agents that abuse it lose access. It's a similar model to how shared IP pools work in transactional email services.
"no anonymous accounts" is a stretch when one could just provision n+1 ef25519 keys