email authentication for ai agents: how dkim, spf, and dmarc actually work

Last month a developer on Reddit posted a screenshot: 347 emails sent from an AI agent, zero delivered to primary inbox. Every single one filtered to spam or silently dropped. The agent's code was fine. The email content was fine. The problem was that the sending domain had no SPF record, no DKIM signature, and no DMARC policy. The receiving servers took one look and decided the agent didn't exist.

Email authentication isn't some bureaucratic checkbox. It's the difference between your agent's messages landing in front of a human and disappearing into nothing. For AI agents that send autonomously, getting this wrong means every downstream action that depends on email (verification flows, notifications, outreach, support) fails silently.

How email authentication works for AI agents#

Email authentication is a set of DNS-based protocols that let receiving mail servers verify whether a message actually came from who it claims to be from. For AI agents, these protocols serve as both a deliverability requirement and an identity layer.

Here's how the three core protocols (plus one optional layer) work together:

1. SPF (Sender Policy Framework) lists the IP addresses an AI agent is authorized to send from. The receiving server checks the domain's DNS for an SPF record and compares it to the server that delivered the message.
2. DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every email the agent sends. The receiving server fetches the public key from DNS and verifies the message hasn't been tampered with in transit.
3. DMARC (Domain-based Message Authentication, Reporting & Conformance) enforces policy and ensures the visible "From" domain aligns with SPF or DKIM results. It also tells receiving servers what to do when authentication fails: nothing, quarantine, or reject outright.
4. BIMI (Brand Indicators for Message Identification) optionally displays a verified brand logo next to authenticated emails. It requires a DMARC policy of p=quarantine or p=reject to function.

When a human sends email from Gmail, all of this happens behind the scenes. Google handles SPF, signs with DKIM, publishes DMARC. The human never thinks about it. But when an AI agent provisions its own inbox and starts sending, someone (or something) needs to set these records up correctly. Otherwise, every major mail provider will treat the agent's messages as unverified at best, fraudulent at worst.

SPF: who's allowed to send#

An SPF record is a TXT record in your domain's DNS that says "these servers can send email on behalf of this domain." When your agent sends a message, the recipient's server does a DNS lookup on the envelope sender domain and checks whether the sending IP matches the SPF record.

Here's what a typical SPF record looks like:

v=spf1 include:mail.lobstermail.ai ~all

The include mechanism delegates authorization to LobsterMail's sending infrastructure. The ~all at the end is a softfail, meaning "if the IP doesn't match, flag it but don't outright reject." A -all (hardfail) is stricter and tells receivers to reject unauthorized senders entirely.

One thing that trips up agent builders: SPF has a 10-lookup limit. Every include, a, mx, and redirect mechanism counts as a DNS lookup. If your domain already has SPF includes for Google Workspace, a marketing tool, a transactional sender, and now an AI agent's infrastructure, you can blow past 10 lookups fast. When that happens, the entire SPF evaluation returns permerror, and many receivers treat that the same as no SPF at all.

For agents that send from subdomains (like agent.yourdomain.com), each subdomain gets its own SPF record. This sidesteps the lookup limit on your root domain and isolates the agent's sending reputation.

DKIM: proving the message is real#

DKIM works differently from SPF. Instead of checking the sending server's IP, it verifies the message itself. When your agent sends an email, the sending server signs the message headers and body with a private key. The corresponding public key lives in a DNS TXT record under a specific "selector."

A DKIM DNS record looks like this:

agent1._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The selector (agent1) is the part that matters for multi-agent setups. Each AI agent can have its own selector, which means its own key pair. If one agent's key is compromised or its emails start getting flagged, you rotate that one selector without touching the others.

This is a real operational concern for persistent AI agents. A human employee might use the same email for years without rotating credentials. An AI agent running autonomously should cycle its DKIM key on a regular schedule (every 90 days is a common recommendation, though quarterly works for most setups). If your agent can detect DKIM signature failures through DMARC aggregate reports, it could even trigger rotation automatically.

The question of "do I need both SPF and DKIM?" comes up a lot. Technically, DMARC only requires one to pass and align. In practice, you want both. SPF can break when emails are forwarded (the forwarding server's IP won't match your SPF record). DKIM survives forwarding because the signature travels with the message. Running both gives you redundancy.

DMARC: the policy enforcer#

DMARC ties SPF and DKIM together with alignment checks and tells the world what to do when authentication fails. It also generates reports so you (or your agent) can see what's happening with your email traffic.

A DMARC record sits at _dmarc.yourdomain.com:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"

The p= tag is the policy. Three options:

• p=none logs failures but takes no action. Good for monitoring.
• p=quarantine sends failing messages to spam.
• p=reject blocks failing messages entirely.

The alignment check is where things get subtle. DMARC requires that the domain in the visible "From" header matches (or is a subdomain of) the domain validated by SPF or DKIM. If your agent sends with a "From" address of agent@yourdomain.com but the SPF-authenticated domain is bounce.mailprovider.com, SPF passes but DMARC alignment fails. DKIM alignment works the same way: the d= domain in the DKIM signature must match the "From" domain.

This is a common source of confusion. "Why is my email failing DMARC even with SPF and DKIM configured?" Almost always, it's an alignment mismatch. The protocols passed individually, but the domains didn't line up with the visible sender address.

Progressive policy escalation#

A pattern that's emerging for AI agent deployments: start with p=none to collect data, then programmatically escalate to p=quarantine and eventually p=reject once you've confirmed legitimate traffic is passing. An agent that reads its own DMARC aggregate reports (the XML files sent to the rua address) could automate this entire progression. No human intervention required.

Why agents need per-identity isolation#

Here's the scenario nobody talks about in generic email authentication guides: you have five AI agents, all sending from the same root domain, sharing one SPF record and one DKIM selector.

Agent three starts sending poorly targeted outreach. Recipients mark it as spam. The domain's reputation drops. Now agents one, two, four, and five all suffer. Their perfectly legitimate transactional emails start hitting spam folders because the domain they share got poisoned by one bad actor.

The fix is subdomain isolation. Each agent sends from its own subdomain (agent1.yourdomain.com, agent2.yourdomain.com). Each subdomain has its own SPF record, its own DKIM selector, and its own DMARC policy. If one agent's subdomain gets flagged, the blast radius is contained. Your other agents and your root domain are unaffected.

This also solves the SPF 10-lookup limit problem. Each subdomain is a fresh slate with its own lookup budget.

Gmail, Yahoo, and Microsoft all tightened their bulk sender requirements in 2024 and 2025. The rules now require valid SPF, DKIM signing, and a published DMARC policy for any sender doing more than 5,000 messages per day. AI agents hit that threshold faster than most people expect. An agent handling customer support for even a mid-size product can clear 5,000 sends in a week.

What LobsterMail handles for you#

When your agent provisions an inbox through LobsterMail, the authentication setup happens automatically. SPF, DKIM signing, and DMARC are configured on the @lobstermail.ai domain out of the box. Your agent doesn't need to touch DNS records or manage key pairs.

If you bring a custom domain, LobsterMail provides the exact DNS records you need to add. The custom domains guide walks through the process, and DKIM selectors are scoped per inbox so you get the isolation benefits described above without managing the cryptography yourself.

The point isn't that this is impossible to do manually. It's absolutely possible. But email authentication is the kind of thing that's easy to get 90% right and then spend weeks debugging the last 10%. For an autonomous agent that needs to send reliably from day one, having authentication pre-configured removes a category of silent failures.

If you want your agent sending authenticated email in about thirty seconds, set up a LobsterMail inbox here and the authentication layer is handled before your agent sends its first message.