How do I use my own domain for an AI agent's email?

By Naol Ketema, founder · 2026-10-21 · Markdown

When a custom domain is worth it

An address on a shared service domain is fine for prototypes, internal agents and agent-to-agent work. Use your own domain when the agent talks to customers or prospects, when the address should carry your brand, or when you want the sending reputation tied to a domain you control.

Consider a subdomain rather than your main domain, for example agents.yourcompany.com. Its reputation is tracked separately, its DNS records do not collide with your company mail, and you can point its MX records at the agent mail provider without moving anyone's inbox.

Two separate jobs: verification and deliverability

• Verification proves to the mail service that you control the domain. It is a one-time TXT record.
• Deliverability records (SPF, DKIM, DMARC) convince receiving servers to trust mail from the domain. Missing these is the usual reason mail ends up in spam.
• Receiving needs MX records pointing at the provider that accepts mail for the domain. Verification and deliverability only cover sending.

Step 1: Add the domain and verify ownership

Adding a domain needs an org key. The response includes the TXT record to publish.

curl -sS -X POST https://api.agent-identity.dev/v1/domains \
  -H "authorization: Bearer $AID_KEY" \
  -H 'content-type: application/json' \
  -d '{"domain":"agents.yourcompany.com"}'

# Response (trimmed):
# "status": "pending",
# "verification": { "record_type": "TXT", "record_name": "agents.yourcompany.com", "record_value": "aid-verify=9f2c…" }

Publish that TXT record at your DNS host, wait for propagation, then call verify. Verification does a live DNS lookup every time it is called, so if it fails, wait and retry rather than adding the domain again.

curl -sS -X POST "https://api.agent-identity.dev/v1/domains/$DOMAIN_ID/verify" \
  -H "authorization: Bearer $AID_KEY"

Step 2: Publish the sending records

GET /v1/domains/:id/deliverability returns the SPF, DKIM and DMARC records for the configured provider, each with a record type, name, value and a note. Publish them as given.

• SPF: a TXT record on the domain. If one already exists, merge the include into it; a domain may have only one SPF record.
• DKIM: a TXT record at the selector name returned. A null record_value means the provider generates the key per domain, and the docs say to take the value from the provider's dashboard.
• DMARC: a TXT record at _dmarc. Start with p=none so nothing is rejected while you confirm SPF and DKIM pass, then tighten to quarantine or reject.

Step 3: Point MX records for inbound mail

If agents on the domain should receive replies, point the domain's MX records at the mail provider, as the Domains and Receiving Mail docs describe. Be careful on a root domain: changing its MX records moves all inbound mail for that domain, including your team's. This is the strongest reason to use a subdomain for agents.

MX changes can take a while to propagate, and mail sent to the address before then goes wherever the old records point. Test with a message from an outside account before telling customers to write to the new address. Inbound mail that reaches the service but matches no agent's mailbox is counted as unroutable, so a typo in a handle shows up there rather than as a bounce you can see.

Step 4: Create agents on the domain

Once the domain is verified, pass it when you create an agent. The mailbox is provisioned on that domain in the same call.

import { AgentClient } from "@agentidentity/sdk";

const admin = new AgentClient({ baseUrl: "https://api.agent-identity.dev", apiKey: process.env.AID_KEY! });

const agent = await admin.identities.create({
  handle: "jobs",
  displayName: "Jobs",
  domain: "agents.yourcompany.com",
});

console.log(agent.mailboxAddress); // jobs@agents.yourcompany.com

Existing agents keep their addresses. The handle and mailbox address do not change when you rename an agent, so moving an agent to a new domain means creating a new agent there.

Managing domains, and common mistakes

GET /v1/domains lists your domains with their status and verified_at. DELETE /v1/domains/:id removes one; the DNS records are yours to clean up. The SDK exposes the same operations on client.domains as add, list, verify, delete and deliverability. After the records are live, send a few messages to mailboxes you control at different providers and check the authentication results in the message headers before you let an agent loose on real recipients.

• Publishing a second SPF record instead of merging into the existing one.
• Jumping to DMARC p=reject before confirming every legitimate sender passes.
• Changing MX on the main company domain and breaking everyone's inbox.
• Re-adding the domain when verification fails, instead of waiting for DNS propagation and calling verify again.
• Sending at full volume from a brand new domain. Ramp up gradually.