SPF, DKIM, and DMARC: What AI Agent Developers Get Wrong
Your agent wrote a strong reply. The customer never saw it. It's sitting in a spam folder because nobody configured the DNS records.
Most developers building AI agents that send email focus on the hard part first: the LLM, the prompt engineering, the tool integration, the workflow orchestration. All the interesting work. Then, right before launch, someone asks: "Wait, will these emails actually get delivered?"
That's when things get uncomfortable.
The three records that decide everything
Email authentication runs on three DNS records. They work together, and each one answers a different question.
SPF (Sender Policy Framework) answers: "Is this server allowed to send email for this domain?" When your agent sends an email from support@yourdomain.com, the receiving mail server checks the SPF record for yourdomain.com. If the sending IP isn't listed, the email fails SPF.
DKIM (DomainKeys Identified Mail) answers: "Was this email tampered with in transit?" Your sending server signs every outbound message with a private key. The receiving server looks up the public key in your DNS and verifies the signature. If the signature doesn't match, the email fails DKIM.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) answers: "What should I do with emails that fail SPF or DKIM?" DMARC is the policy layer. It tells receiving servers whether to accept, quarantine, or reject messages that don't pass authentication.
These records aren't optional. Gmail, Yahoo, and Microsoft all require DMARC alignment as of 2024 for bulk senders. Even for non-bulk email, missing or misconfigured authentication is the single fastest way to land in spam.
Why automated systems get this wrong more often
Here's what nobody talks about in the "build an AI agent" tutorials.
When a human sends email through Gmail or Outlook, authentication is invisible. Google handles SPF. Google handles DKIM. Google handles DMARC. The user never thinks about it.
When an AI agent sends email through an API, authentication becomes the developer's problem. And the failure modes are different from what most developers expect.
The shared IP problem
Budget email services send your messages from shared IP pools. Your agent's carefully crafted support reply goes out from the same IP that another customer used to send a promotional blast that triggered spam complaints. Your email inherits their reputation.
SPF records can't save you here. The SPF record says "this IP is authorized to send for this domain." It doesn't say "this IP only sends high quality email." A shared IP that's listed in your SPF record is technically authorized, but practically toxic.
The subdomain trap
Many developers set up a subdomain for their agent. agent.yourdomain.com or mail.yourdomain.com. They configure SPF and DKIM for the subdomain. Then they forget DMARC.
Without DMARC, SPF and DKIM alignment is evaluated loosely. Some receiving servers will check the organizational domain (yourdomain.com) and find no DMARC record. Some will check the subdomain and find nothing. The behavior is inconsistent across providers, which means the same email might be delivered to Gmail, quarantined by Yahoo, and rejected by Microsoft.
DMARC should be configured at both the organizational domain and the subdomain level. The subdomain record should be explicit about the policy, not rely on inheritance.
The "it worked in testing" failure
This is the most common one. The developer tests the agent. Sends a few emails. They arrive fine. The developer ships to production.
A week later, the agent is sending 500 emails a day. Deliverability drops to 60%. What happened?
During testing, the low volume flew under the radar. Most receiving servers are lenient with small senders. At scale, every missing or misconfigured authentication record becomes a signal. And signals accumulate. A sender with no DMARC record sending 500 emails a day looks exactly like a phishing operation to a spam filter.
What a correctly configured setup looks like
Let me be specific. If your AI agent sends email from support@agent.yourdomain.com, here's what your DNS should contain.
SPF record for agent.yourdomain.com:
v=spf1 include:_spf.yourmailprovider.com -all
The -all at the end is important. It means "reject anything not explicitly authorized." Many guides recommend ~all (soft fail), but for automated systems, you want the strictest policy. Soft fail gives receiving servers discretion. Hard fail gives them clarity.
DKIM: Your email provider should generate a DKIM key pair and give you a CNAME or TXT record to add. It usually looks like:
selector._domainkey.agent.yourdomain.com CNAME selector.yourmailprovider.com
The selector is provider-specific. The key pair is rotated periodically. The critical thing is that every outbound message gets signed, and the public key is resolvable via DNS.
DMARC record for agent.yourdomain.com:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s
Breaking this down:
p=rejecttells receiving servers to reject messages that fail alignment. Not quarantine. Reject.ruaspecifies where aggregate reports go. These reports tell you who is sending email as your domain (including unauthorized senders).adkim=sandaspf=senforce strict alignment. The domain in the DKIM signature and SPF check must exactly match the From domain. No relaxed matching. No organizational domain fallback.
Strict alignment matters for automated systems because you want to know immediately if something is misconfigured. Relaxed alignment hides problems until they become crises.
The monitoring gap
Here's the part that most "set up email authentication" guides skip entirely.
Configuring DNS records is the first step. Monitoring whether they're working correctly is the ongoing work. And for automated systems, this monitoring is essential.
DMARC aggregate reports are XML files that receiving servers send to the address in your rua tag. They contain data about every message sent from your domain: which ones passed, which ones failed, and why.
Most developers set up the rua address and never read the reports. This is like setting up error logging and never checking the logs.
What you should watch for:
Unauthorized senders. If someone is spoofing your domain, DMARC reports will show it. You'll see sends from IPs you don't recognize. For an AI agent handling customer communication, domain spoofing isn't just a security problem. It's a trust problem.
Alignment failures from your own system. Sometimes your own infrastructure causes DKIM alignment failures. A proxy that modifies message headers. A forwarding rule that breaks the signature. A misconfigured relay. DMARC reports surface these issues before they affect deliverability at scale.
Gradual reputation decay. Deliverability doesn't drop overnight. It degrades slowly as small signals accumulate. A few SPF soft fails here, a few DKIM mismatches there. By the time you notice, your sender reputation has already taken damage. Regular DMARC report analysis catches the early warning signs.
What this means for email infrastructure choices
If you're evaluating email infrastructure for an AI agent, email authentication should be one of the first questions you ask. Not the last.
Specifically:
Does the provider give you dedicated sending infrastructure? Shared IPs mean shared reputation. For automated systems sending at any meaningful volume, dedicated IPs with clean reputation are a baseline requirement.
Does the provider handle DKIM signing automatically? You shouldn't be managing key rotation manually. The infrastructure should sign every outbound message and expose the public key records for your DNS.
Does the provider support strict DMARC alignment? Some providers only work with relaxed alignment because their sending infrastructure doesn't match the exact From domain. If you can't use strict alignment, that's a red flag.
Does the provider surface deliverability data at the message level? You need to know, for each individual message your agent sends, whether it was delivered, bounced, or flagged. Aggregate dashboards are marketing tools. Message-level event timelines are engineering tools.
How mailbot handles this
mailbot was built on a proprietary MTA with years of production operation behind it. That history is relevant because sender reputation is built over time, not configured overnight.
When you create an inbox in mailbot, DKIM signing is automatic. Every outbound message is signed with keys managed by the infrastructure. SPF records are preconfigured for the sending domains. DMARC alignment is strict by default.
mailbot's MTA maintains industry-leading deliverability scores. That represents years of reputation management, deliverability optimization, and abuse prevention. It's not something you can replicate by signing up for a new email API and configuring DNS records over a weekend.
For developers building AI agents, this means you can focus on the agent logic. The email authentication layer is handled. The deliverability foundation is already proven. Your agent's emails land in the inbox because the infrastructure underneath has spent a decade earning that trust.
curl -X POST https://api.mailbot.id/v1/inboxes \
-H "Authorization: Bearer mb_live_xxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"username": "support",
"display_name": "Support Agent"
}'
That inbox comes with authentication built in. No DNS configuration on your end. No key management. No reputation cold start.
The bottom line
SPF, DKIM, and DMARC are not bonus features. They are the foundation that determines whether your AI agent's emails reach the inbox or disappear into spam.
Most developers building automated email systems discover this too late. They build the agent, build the workflow, build the integration, and then find out that email deliverability is its own discipline with its own failure modes.
You can learn that discipline from scratch and manage it yourself. Or you can build on infrastructure where it's already solved.
That's the choice.
mailbot is programmable email infrastructure. Read the docs · Get API key