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

DNS records for an agent subdomain, verified
Published once, verified once. Everything after this is behaviour, not DNS.

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>

TXT

agents.yourcompany.com

10 inbound-smtp.eu-west-1.amazonaws.com

MX

agents.yourcompany.com

v=spf1 include:amazonses.com ~all

TXT

_dmarc.agents.yourcompany.com

v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; fo=1; adkim=s; aspf=s

TXT

<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

RecordThe claimWho checks it
SPFThese servers may send mail with this envelope domainThe receiving server, at connection time
DKIMThis message was signed by this domain and has not been modifiedThe receiving server, using the public key in DNS
DMARCIf SPF or DKIM does not align with the From domain, do thisThe 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.

How SPF and DKIM alignment is evaluated against the From domain
Passing is not aligning. DKIM signed by your own domain is what makes DMARC pass.

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.

  1. Two weeks at `p=none`, reading the aggregate reports that arrive at your rua address.
  2. Move to `p=quarantine` once every source in the reports is one you recognise and that passes alignment.
  3. Move to `p=reject` after a clean fortnight at quarantine. This is the destination, not an optional extra.
  4. 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=none with an rua reporting 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