DMARC, DKIM, and SPF for AI agents: a no-bullshit field guide
· 11 min read
Most blog posts about email authentication start by explaining DKIM like it's a math puzzle. Skip that. The thing you actually need is a mental model of what each record does, where it breaks for an agent fleet, and which fix you reach for when deliverability starts dropping. Here is the field guide.
The three records, in plain words
SPF — "these IPs are allowed to send for me"
A DNS TXT record on your domain naming the IPs that are authorized to put mail into the SMTP envelope as you. Receivers reject mail from unlisted senders. SPF only checks the envelope-from (the "return path"), not the visible From: header.
DKIM — "here's a signature you can verify"
A cryptographic signature on every outbound message tied to a public key in DNS. Receivers verify the signature has not been tampered with and was signed by an authorized key for the domain in the From: header. DKIM is the only one of the three that actually authenticates the visible sender.
DMARC — "here's what to do when SPF and DKIM disagree"
The policy record. It does two things: ties SPF and DKIM together with alignment rules (the verified domain has to match the visible From:), and tells receivers what to do when alignment fails (none, quarantine, or reject). It also takes a reporting address (rua=mailto:dmarc@yourdomain.com) so you find out when something is broken.
What breaks for an agent fleet
Three failure modes are common when you scale from one or two senders to a fleet of agents:
- SPF flatten exhaustion. SPF has a 10-DNS-lookup limit per evaluation. Add three SaaS senders and a self-hosted relay and you blow it. Receivers either fail soft or fail hard; either way mail starts landing in spam.
- DKIM key rotation drift. If your DKIM selector rotates and a sender is still signing with the old key, receivers see signature failures. With one sender that's a five-minute fix; with thirty agents on three domains, you're reading forensic reports for a week.
- DMARC alignment break. The visible From: domain doesn't match the SPF/DKIM-authenticated domain. Mail silently moves to spam at the receiver — you don't see an error, just a slow drop in opens. This is the one that bites unattended.
The forcing function: configure all three from day one, run DMARC at p=quarantine with reporting on, and never let an agent send from a domain you don't control.
How MailMolt handles all of this
On the default @mailmolt.com sub-addresses, MailMolt owns the DNS — SPF, DKIM, and DMARC are configured for you. You send from your agent address, and the receiver sees aligned records.
For your own sending domain, MailMolt operates two modes:
Managed (Tier 2)
You point the domain's nameservers at a Cloudflare zone MailMolt provisions. SPF, DKIM, DMARC, and MX are auto-managed; rotation is handled. You get the zone published; you don't edit it. This is the default for most teams. Setup looks like:
curl -X POST https://api.mailmolt.com/v1/custom-domains \
-H "Authorization: Bearer mm_live_…" \
-d '{"domain": "bots.acme.com", "mode": "managed"}'
# response includes nameservers — point bots.acme.com at them
# verification is automatic once delegation lands
BYOC (Tier 3)
You keep the DNS zone on your own cloud account. MailMolt provisions a scoped sender on it via API, and your team manages the zone. This is the right mode if compliance demands you control your own DNS or if the domain is shared with non-MailMolt senders.
Warm-up — the part everyone skips
A new sending domain or subdomain has zero reputation. If you fire 1,000 messages out of it on day one, you'll trip every spam filter on the planet. Standard practice:
- Day 1–7: under 100 messages/day. Mostly to addresses that will positively engage (replies, opens).
- Day 8–14: ramp to 500/day, watching DMARC reports for any alignment failures.
- Day 15–30: ramp to your steady-state daily, monitoring complaint rate (under 0.1% is fine).
MailMolt's outbound queue surfaces per-message events (delivered, bounced, complained) so you can detect a warm-up gone wrong before a recipient blocks you.
Reading DMARC reports without crying
DMARC reports come back as XML attachments to rua=mailto: daily. Most teams set up a parser service (Postmark's DMARC Digests, dmarcian, or roll your own from the XSD). What you're looking for:
- Aggregate "source IPs" you don't recognize. Could be a forgotten SaaS sender, could be someone forging your domain.
- Alignment failures concentrated on one source. That's your broken sender; fix or remove it.
- A sustained drop in "passed" volume. That's a mailbox provider making you up to spam — go check your reputation dashboards.
The summary
Email authentication is not optional for autonomous senders. The good news: it's a one-time setup, not an ongoing tax. Configure SPF, DKIM, and DMARC together; run DMARC at p=quarantine with reporting on; warm up new subdomains gradually; and let the platform handle key rotation. MailMolt's managed mode does all of this for you — but even if you're running your own sender, the principles are the same.