SPF, DKIM and DMARC for AI Agent Email: A Practical Rollout
What SPF, DKIM and DMARC actually prove, how they apply to mail your AI agents send, and a safe path from p=none to p=reject on a dedicated subdomain.
By Toan Nhu
When an AI agent sends email on your behalf, every recipient's mail server asks the same question: is this message really from the domain it claims? SPF, DKIM and DMARC are how that question gets answered. Get them right and your agent's replies, confirmations and follow-ups have a fair chance of reaching the inbox. Get them wrong and even a perfectly written message can be rejected, or worse, someone else can send mail that looks like it came from your agent.
This guide explains what each record proves, how they fit together for agent mailboxes, and how to tighten your DMARC policy without breaking legitimate mail.
The short version
- SPF lists which servers may send mail for a domain. It checks the envelope sender (the Return-Path), not the From address people see.
- DKIM adds a cryptographic signature to each message. The receiving server fetches a public key from DNS and confirms the signed parts were not altered in transit.
- DMARC ties the two to the visible From domain. A message passes DMARC when SPF or DKIM passes and the passing domain aligns with the From domain. DMARC also tells receivers what to do with failures and where to send reports.
None of these records say anything about whether a message is wanted or honest. They prove the sender is allowed to use the domain. That distinction matters for agents in both directions, as we will see below.
Why agent email raises the stakes
A human usually sends from one address and notices when something looks off. Agents can send from many mailboxes, at any hour, and often in reply to strangers. That creates three practical risks. First, an unauthenticated domain is easy to spoof, so a scammer could pose as your support agent. Second, major mailbox providers now expect authentication from everyone; Google and Yahoo's sender rules, in force since 2024, require SPF or DKIM for all senders and full SPF, DKIM and DMARC for bulk senders. Third, if your agent shares a domain with your company's human email, a misconfigured agent can hurt the reputation your team depends on.
Step 1: Give agents their own subdomain
Put agent mailboxes on a dedicated subdomain such as agents.example.com or mail.example.com instead of your root domain. The subdomain gets its own SPF, DKIM and MX records, so you never have to edit the records that run your company inbox. It also keeps reputation separate: a spike in complaints on the agent subdomain does not automatically land on your founders' mail.
Mermail is built around this pattern. It does not accept a domain that already has MX records, and it suggests a subdomain instead, so connecting agent mail cannot take over your existing mail routing. Custom domains are available on the Developer and Enterprise plans; on the Free plan, agents use a hosted @mermail.app address where Mermail manages SPF, DKIM and DMARC for you.
Step 2: Publish exactly the records you are given
When you add a domain in Mermail, it generates the TXT, MX and CNAME records you need and checks each one. The domain card shows two separate capabilities: Sending ready (the signing and sending records are verified) and Receiving ready (the MX record is verified). Once sending records verify, Mermail signs every outgoing message, which covers SPF and DKIM for that domain.
A few mistakes cause most failed setups:
- Guessing values. Copy each name and value exactly. Never hand-write an SPF include or a DKIM key you were not given.
- Doubled names. Some DNS hosts append your zone automatically, turning a record into name.example.com.example.com. Enter only the relative part if your host does this.
- Proxied CNAMEs. If your DNS provider offers a proxy (such as Cloudflare's orange cloud), set these records to DNS only. A proxied CNAME returns IP addresses and never verifies.
- Two SPF records on one name. A hostname may have only one SPF TXT record. If another service already uses SPF on the same name, merge rather than add, and keep the total under SPF's limit of 10 DNS lookups.
Step 3: Add DMARC yourself, starting in monitor mode
Mermail does not create your DMARC record, because the policy is your decision. Add a TXT record at _dmarc on the sending subdomain. A sensible first record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc@example.comWith p=none, receivers deliver mail as usual but send daily aggregate reports to the rua address. Those reports list every source that sent mail using your domain, how many messages it sent, and whether SPF, DKIM and alignment passed. Use a mailbox or a DMARC reporting service that can parse the XML; the raw files are not meant to be read by hand.
One detail people miss: if your subdomain has no DMARC record, receivers fall back to the organizational domain's record and apply its sp= (subdomain policy) value, or its p= value when sp= is absent. Check what your root domain already publishes before you assume a subdomain is unprotected, or unexpectedly strict.
Step 4: Move from none to quarantine to reject
Tighten the policy only when the reports show that every legitimate source passes. A practical sequence:
- Stay at p=none for at least a couple of weeks of normal agent traffic. Identify every sender in the reports and fix or remove anything unexpected.
- Switch to p=quarantine. You can ramp with pct=25, then 50, then 100 so only part of failing mail is affected at first. Watch for legitimate mail landing in spam.
- Move to p=reject once quarantine has run cleanly. At this point spoofed mail using your agent subdomain is refused outright by receivers that honor DMARC.
Because the agent subdomain carries only agent mail, this rollout is usually much simpler than enforcing DMARC on a root domain that dozens of SaaS tools send through.
The inbound side: authentication is not permission
Your agent also receives mail, and it is tempting to trust a message because its SPF or DKIM passed. Resist that. A pass only means the sending domain is authorized to use that domain; attackers can authenticate their own lookalike domains perfectly well.
Mermail exposes a sender_authentication object on received mail with SPF, DKIM and DMARC verdicts derived from server-side receiving evidence, never from headers the sender could forge. Many messages currently return unknown, and unknown is not a pass. Even a pass does not authorize an action: your agent should still check that the sender is who the task expects and treat the body as untrusted input.
Checklist
- Agent mail lives on a dedicated subdomain.
- All generated records are published exactly, CNAMEs unproxied, and both Sending and Receiving show ready.
- A DMARC record exists with a working rua address.
- Policy moves to quarantine and reject only after reports show clean alignment.
- Inbound authentication results inform decisions but never replace task-level checks.
Read the Mermail custom domain guide
Ready to give your agents a properly authenticated address? Create a Mermail workspace and start on a hosted address today, then connect your own subdomain when you move to production.
