SPF, DKIM, and DMARC for an agent subdomain, with a generator
Authentication is the part of email deliverability with a correct answer. A handful of records, one alignment rule, and a policy you tighten over time. This page generates the records for your own domain and then checks a real message to prove they are working, because published records and passing messages are not the same claim.
6 min read
Generate the records
Fill in your domain. The subdomain is the one your agents send from, which should not be the domain your people send from: reputation is tracked per sending domain, and separating them means an agent's bad week cannot take your invoices down with it.
_mcpmailer.agents.yourcompany.com
mcpmailer-verify=<token from the dashboard>
agents.yourcompany.com
10 inbound-smtp.eu-west-1.amazonaws.com
agents.yourcompany.com
v=spf1 include:amazonses.com ~all
_dmarc.agents.yourcompany.com
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; fo=1; adkim=s; aspf=s
<token>._domainkey.agents.yourcompany.com
<token>.dkim.amazonses.com
Three DKIM CNAMEs, issued when you add the domain. They cannot be derived from the name, and a domain is not activated until they resolve and a signature is confirmed.
Monitoring only. Nothing is rejected, and the reports tell you who else sends as this domain. Start here for two weeks.
The exact values for a domain you have added are shown in the dashboard and in the domains chapter. If you have not added a domain at all, you do not need one yet: a workspace gets a working mcpmailer.email subdomain, so the whole flow can be built and tested before any DNS change.
What each record is claiming
| Record | The claim | Who checks it |
|---|---|---|
| SPF | These servers may send mail with this envelope domain | The receiving server, at connection time |
| DKIM | This message was signed by this domain and has not been modified | The receiving server, using the public key in DNS |
| DMARC | If SPF or DKIM does not align with the From domain, do this | The receiving server, after the other two |
Three details are worth knowing before you publish.
`-all` versus `~all`. Hard fail says "if it did not come from these servers, it is not us". Soft fail says "probably not us". Publish -all once you are certain the include list is complete, which for a dedicated agent subdomain is immediately, because nothing else sends from it.
Ten lookups. SPF evaluation stops after ten DNS lookups and the record then fails. Chaining several include: statements is how people quietly break SPF, and it is another argument for a subdomain that has exactly one sender.
`adkim=s` and `aspf=s`. Strict alignment requires an exact domain match rather than an organisational one. On a dedicated agent subdomain you can afford strict, and it closes the case where a neighbouring subdomain's signature would satisfy your policy.
Alignment is what actually fails
SPF and DKIM can both pass while DMARC fails, and this is the single most common confusion in agent email setups.
DMARC does not ask whether the mechanisms passed. It asks whether the domain that passed is the domain in the visible From address. A provider that bounces through its own domain will show smtp.mailfrom=bounce@mail.provider.com while your From says agents.yourcompany.com. SPF passes, for the provider's domain, and contributes nothing to your DMARC result. DKIM is what carries alignment, which is why the DKIM record must be published on your own domain rather than the provider's.
Check a message you actually received
Publishing records proves nothing on its own. Send a message from your agent to an account you can read, open the raw source, and paste the Authentication-Results header below. It is parsed in the page and nothing is uploaded.
Paste the Authentication-Results header from a message you
received.
In Gmail, open the message and choose Show original. In Apple Mail, View then Message then Raw Source. In Outlook, open the message and choose Properties, then read internet headers.
The policy ramp
Publish p=none first. Not because monitoring is virtuous, but because DMARC reports are the only way to discover what else sends as your domain: a ticketing tool, a payments provider, a marketing platform someone signed up for in 2023. Going straight to reject before you know that list is how legitimate mail disappears on a Friday afternoon.
- Two weeks at `p=none`, reading the aggregate reports that arrive at your
ruaaddress. - Move to `p=quarantine` once every source in the reports is one you recognise and that passes alignment.
- Move to `p=reject` after a clean fortnight at quarantine. This is the destination, not an optional extra.
- Leave it there. A subdomain used only by agents should never acquire new senders.
Aggregate reports are XML and unpleasant to read by hand. Any DMARC reporting service will parse them, and for a subdomain with one sender the volume is small enough to read manually if you would rather not add a vendor.
When authentication is right and mail still lands in spam
Then the problem is reputation or content, not DNS, and the diagnostic order is in deliverability for agent senders. The usual causes, roughly in order: a domain with no sending history, volume that arrived too fast, near-identical bodies across recipients, or addresses that were not obtained from real conversations.
The first two are the ones a new agent hits, and they have a shape rather than a fix. There is a warmup plan and a schedule for that.
A note on forwarding
Forwarding breaks DKIM whenever the forwarder modifies the message, and a broken signature can take alignment down with it. This is one of the practical reasons an agent should have its own mailbox rather than an alias that forwards somewhere else, as compared in agent inbox or shared mailbox.
Questions
- What DNS records does an AI agent sending domain need?
- An ownership TXT, an MX for inbound mail, SPF, DMARC, and three DKIM CNAMEs. The generator above produces the first four for your domain; the DKIM tokens are issued when you add the domain and cannot be derived from its name.
- Should agents send from a subdomain or the main domain?
- A subdomain. Reputation is tracked per sending domain, so a subdomain isolates agent sending from the mail your people send while keeping your brand in the address.
- Why does DMARC fail when SPF and DKIM pass?
- Because DMARC checks alignment with the visible From domain, not just whether the mechanisms passed. A provider bounce domain passes SPF for itself and contributes nothing to your alignment, which leaves DKIM on your own domain carrying the result.
- What is the right DMARC policy to start with?
p=nonewith anruareporting address for about two weeks, then quarantine, then reject. The monitoring phase exists to reveal other senders on your domain before you start refusing mail.- Do I need a separate DKIM key per agent?
- No. DKIM is per sending domain, not per agent. Separation between agents is handled by identity and key scope, described in identities.
- Can I check this without sending a real message?
- Not meaningfully. DNS checkers confirm records exist and parse; only a real message shows what a receiving server concluded, which is why the header checker above matters more than a lookup tool.
Give your agent an address it can answer from.
Create an inbox