An AI agent that can only send email is half an agent. Real autonomy means the agent has an address humans can reply to, an identity that survives across threads, and the infrastructure to receive, parse, and act on responses — without a human manually routing messages.
This post walks through exactly how to provision that identity: the DNS records, mailbox configuration, inbound routing, and threading primitives you need to make an agent a first-class email participant.
Why a dedicated address matters
Using a shared domain or a generic noreply@ address breaks several things at once. Thread context collapses when multiple agents share an address — you can't correlate a reply to the agent instance that sent the original. Deliverability degrades when automated and human mail shares sending infrastructure, because volume spikes from agent activity affect the reputation of human-sent mail. Reply routing becomes ambiguous; you need a subaddress or some other signal to route inbound mail to the right handler.
A dedicated address — aria@agents.yourcompany.com, for example — solves all three. Each agent gets a stable identity, replies route unambiguously, and you can isolate agent sending reputation from transactional or human mail.
Choosing your addressing strategy
Three practical patterns exist for assigning addresses to agents, each with different tradeoffs.
Pattern 1: Static named address
One agent, one address. agent@yourdomain.com or support-bot@yourdomain.com. Simple, memorable, easy to configure. Works well for a single-purpose agent with low send volume. The problem: you can't run multiple instances without collision, and you lose per-conversation routing.
Pattern 2: Subaddress routing (plus addressing)
Most mail servers support the + extension defined in RFC 5321: agent+threadid@yourdomain.com routes to the same mailbox as agent@yourdomain.com, but the full address is preserved in the To: header. Your inbound parser extracts the local-part extension and maps it to the correct agent context.
Low-infrastructure — no extra mailboxes — but it exposes internal IDs in the address, and some senders strip plus extensions before replying.
Pattern 3: Dynamic provisioned addresses
Provision a unique address per conversation via API: conv-a3f7b2@agents.yourdomain.com. The mail server (or a catch-all route) delivers everything matching *@agents.yourdomain.com to your inbound webhook. Your webhook extracts the local-part, looks up the conversation record, and dispatches accordingly.
This is the most reliable pattern for multi-agent or multi-conversation systems. It requires a catch-all MX configuration and a lookup table, but eliminates ambiguity entirely.
import secrets
import string
def provision_agent_address(conversation_id: str, domain: str = "agents.yourdomain.com") -> str:
# Store mapping: local_part -> conversation_id in your DB
local_part = f"conv-{conversation_id[:8]}"
address = f"{local_part}@{domain}"
db.store_address_mapping(local_part, conversation_id)
return address
DNS and authentication setup
Before the agent sends a single message, the sending domain needs correct authentication records. Without them, your mail hits spam or gets rejected outright.
SPF
Add a TXT record on the sending domain authorizing your mail provider's sending IPs:
agents.yourdomain.com. TXT "v=spf1 include:_spf.yourprovider.com ~all"
Use ~all (softfail) during initial setup, then tighten to -all once you've confirmed all legitimate sending paths are covered.
DKIM
Generate a 2048-bit RSA keypair. Publish the public key as a DNS TXT record:
mail._domainkey.agents.yourdomain.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."
Your sending provider signs outbound messages with the private key. The selector (mail above) can be rotated — useful for rolling keys without downtime.
DMARC
DMARC tells receiving servers what to do when SPF or DKIM fails, and where to send aggregate reports:
_dmarc.agents.yourdomain.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100"
Start with p=none (monitor only), review aggregate reports for two weeks, then move to p=quarantine or p=reject. Agent mail sent from a subdomain inherits none of the parent domain's DMARC policy unless you explicitly configure subdomain policy (sp=).
MX records for inbound
For the agent to receive mail, configure MX records pointing to your inbound mail handler:
agents.yourdomain.com. MX 10 inbound.yourprovider.com.
If you're using a catch-all route, a single MX record is sufficient. Verify the MX is resolving before going live — replies will bounce silently if it's missing.
Wiring inbound mail to your agent
The MX record gets mail to your provider. What happens next is the integration work. Most infrastructure-level email APIs expose inbound mail as a webhook POST containing a parsed representation of the message: headers, body (plain and HTML), attachments as base64, and envelope data.
A minimal inbound handler looks like this:
from fastapi import FastAPI, Request
import hashlib, hmac
app = FastAPI()
SECRET = b"your-webhook-secret"
@app.post("/inbound")
async def handle_inbound(request: Request):
# Verify the webhook signature
sig = request.headers.get("X-Webhook-Signature", "")
body = await request.body()
expected = hmac.new(SECRET, body, hashlib.sha256).hexdigest()
if not hmac.compare_digest(sig, expected):
return {"error": "invalid signature"}, 403
payload = await request.json()
to_address = payload["envelope"]["to"] # e.g. conv-a3f7b2@agents.yourdomain.com
local_part = to_address.split("@")[0] # conv-a3f7b2
conversation = db.lookup_by_address(local_part)
if not conversation:
return {"status": "unknown_address"}
# Extract threading headers
in_reply_to = payload["headers"].get("In-Reply-To", "")
references = payload["headers"].get("References", "")
# Dispatch to agent
agent_queue.enqueue({
"conversation_id": conversation["id"],
"from": payload["envelope"]["from"],
"subject": payload["headers"]["Subject"],
"text": payload["body"]["text"],
"in_reply_to": in_reply_to,
"references": references,
})
return {"status": "queued"}
The signature verification step is non-negotiable. Without it, anyone can POST fake inbound events to your endpoint.
For a deeper treatment of the inbound pipeline, see our guide on inbound email parsing for AI agents.
Threading: keeping conversations coherent
Email threading is handled by three headers: Message-ID, In-Reply-To, and References. If the agent doesn't set these correctly when replying, clients like Gmail and Outlook won't thread the conversation, and the exchange looks like a sequence of unrelated messages.
When the agent sends the initial message:
import uuid
def generate_message_id(domain: str) -> str:
uid = uuid.uuid4().hex
return f"<{uid}@{domain}>"
initial_message_id = generate_message_id("agents.yourdomain.com")
When replying to a human's response:
def build_reply_headers(original_message_id: str, existing_references: str) -> dict:
new_message_id = generate_message_id("agents.yourdomain.com")
# References is a space-separated chain of all prior Message-IDs
references = f"{existing_references} {original_message_id}".strip()
return {
"Message-ID": new_message_id,
"In-Reply-To": original_message_id,
"References": references,
}
Store every Message-ID the agent sends. When an inbound message arrives with an In-Reply-To header, look up that ID to reconstruct conversation state before generating a response.
Sending: SMTP vs API
Two paths exist for the agent to send mail: direct SMTP submission or an HTTP API.
| SMTP | HTTP API | |
|---|---|---|
| Authentication | STARTTLS + credentials | Bearer token |
| Header control | Full | Usually full |
| Retry logic | Built into SMTP client | You implement or use SDK |
| Async sending | Blocking by default | Naturally async |
| Programmatic control | Harder | Easier |
For agent workloads, the HTTP API wins on almost every dimension. You get structured error responses, easy async dispatch, and no need to manage connection pools or TLS negotiation in agent code. SMTP makes sense only if your infrastructure mandates it or you're integrating with an existing mail relay.
The Mails.ai API is designed specifically for agent senders — per-call pricing at $0.001/send means you're not paying flat subscription fees for bursty agent workloads during closed beta.
Display name and From header hygiene
The From: header has two components: the display name and the address. "Aria (AI Assistant)" <aria@agents.yourdomain.com> tells the recipient immediately they're talking to an automated system, which is both honest and increasingly expected.
A few rules:
- Keep the display name consistent across all messages in a thread. Changing it mid-conversation confuses threading heuristics in some clients.
- Don't impersonate humans in the display name. Beyond ethics, it creates deliverability and legal risk.
- Match the DKIM signing domain to the
From:domain. Mismatches (From: aria@agents.yourdomain.comsigned byyourprovider.com) reduce trust signals and can affect spam scoring.
Reputation isolation
Agent mail has a different sending pattern than transactional or marketing mail: irregular cadence, variable volume, and often replies rather than new sends. Mixing this traffic with your primary domain's sending history pollutes the reputation signals ISPs use to score your mail.
Send agent mail from a subdomain (agents.yourdomain.com) with its own dedicated IP if volume warrants it. A dedicated IP lets you build a clean sending history for agent traffic and isolate any deliverability issues. See dedicated IP for automated sending for the tradeoffs between shared and dedicated pools at different volume levels.
Flow: from provisioning to reply
sequenceDiagram
participant App as Application
participant API as Email API
participant DNS as DNS Resolver
participant Human as Human Recipient
participant Webhook as Inbound Webhook
participant Agent as AI Agent
App->>API: Provision address conv-a3f7b2
App->>DNS: MX records already configured
App->>API: Send from conv-a3f7b2 with Message-ID
API->>Human: Delivers signed message
Human->>DNS: Resolve MX for agents.yourdomain.com
Human->>API: Reply arrives at inbound handler
API->>Webhook: POST parsed inbound event
Webhook->>Agent: Dispatch with conversation context
Agent->>API: Send reply with correct threading headers
API->>Human: Threaded reply delivered
Frequently Asked Questions
Can I use Gmail or Outlook to give my agent an email address?
Technically yes — you can create a mailbox on either platform and poll it via IMAP or use their webhook equivalents (Gmail Push Notifications, Outlook webhooks via Microsoft Graph). In practice, both platforms rate-limit API access, restrict programmatic sending at scale, and weren't built for agent workloads. You'll hit friction fast: OAuth token refresh cycles, send limits, and terms of service restrictions on automated sending. Infrastructure-level email APIs are the right tool.
How do I prevent the agent's address from getting flagged as spam?
Four things matter most: correct SPF/DKIM/DMARC alignment, a warm sending history (start low volume and ramp), a reply-to address that actually works (spam filters check this), and content that doesn't trigger phrase-level filters. Monitor your sender reputation via Google Postmaster Tools and Microsoft SNDS — both are free and show domain-level reputation signals.
What happens if someone replies to the wrong thread or an old address?
Your inbound handler needs to handle the address-not-found case gracefully. Return a 200 to the webhook (to prevent retries), log the event, and optionally send a bounce-style reply explaining the conversation has ended. Never silently drop inbound events — they're data.
Do I need a separate subdomain for each agent?
Not necessarily. A single subdomain with dynamic local-parts (*@agents.yourdomain.com) scales to hundreds of agents without additional DNS configuration. Use separate subdomains only if you need distinct DMARC policies, separate sending reputations, or organizational separation between agent types.
How does email classification fit into this architecture?
Once inbound mail arrives at your webhook, you often need to categorize it before dispatching: is this a reply, an opt-out, a complaint, or an out-of-office auto-response? Routing auto-responses to your agent generates unnecessary completions. Email classification at the inbound layer lets you filter, route, or discard messages before they consume agent resources.
What's the minimum viable setup for a proof of concept?
A subdomain with SPF and DKIM, a catch-all MX pointing to an inbound-capable provider, and a webhook endpoint that logs parsed events. Skip DMARC enforcement initially — add it after you've confirmed all sending paths are authenticated. You can test the full loop in an afternoon with tooling that supports inbound webhooks out of the box.