ai agent email authentication: what spf, dkim, and dmarc actually do

Your AI agent just sent a password reset request to a SaaS tool. The email never arrived. No bounce, no error in the logs, no indication anything went wrong. The receiving server looked at the message, couldn't verify where it came from, and quietly dropped it.

This is what happens when email authentication isn't set up. It's not a theoretical risk. Gmail, Outlook, and Yahoo all enforce strict authentication policies as of 2024, and messages that fail verification increasingly get rejected outright rather than routed to spam. For AI agents that depend on email to complete tasks (signing up for services, receiving verification codes, communicating with humans), a silent rejection means the entire workflow breaks with no obvious cause.

The fix involves three protocols: SPF, DKIM, and DMARC. They're not new, but the way they apply to autonomous agents is different from how a human IT admin thinks about them. Let's walk through what each one does, how they work together, and where agents run into trouble.

What are SPF, DKIM, and DMARC?#

Email authentication is a set of DNS-based protocols that let receiving mail servers verify a message actually came from who it claims to come from. Three protocols handle this:

• SPF lists the IP addresses authorized to send email on behalf of your domain.
• DKIM adds a cryptographic signature to each email so receivers can verify it wasn't altered in transit.
• DMARC ties SPF and DKIM together with a policy that tells receiving servers what to do when either check fails.

Without all three, a receiving server has no reliable way to distinguish your agent's legitimate email from a spoofed message using the same domain name. That's why Gmail started rejecting unauthenticated bulk mail in February 2024, and individual message filtering has gotten stricter since.

How SPF works (and where agents get stuck)#

An SPF record is a DNS TXT record on your domain that lists every IP address or service allowed to send mail on your behalf. When your agent sends an email from agent@yourdomain.com, the recipient's server checks whether the sending IP appears in your domain's SPF record. If it does, SPF passes. If not, the message fails.

The record looks something like this:

v=spf1 include:mail.provider.com -all

That include: directive tells receiving servers to trust the IP ranges published by your mail provider. The -all at the end means "reject everything else."

Here's where agents run into problems. SPF has a hard limit of 10 DNS lookups per record. Every include: directive triggers at least one lookup, and nested includes count too. If your agent sends through one service, your marketing team uses another, and your transactional system runs on a third, you can hit that limit fast. Once you exceed 10 lookups, the entire SPF check fails, which means every email from your domain gets flagged.

For agents, there's a second problem: they typically can't modify DNS records. An autonomous agent that provisions its own inbox on a custom domain would need to add the sending service's IPs to the domain's SPF record. That requires DNS access the agent doesn't have.

How DKIM works#

DKIM takes a different approach. Instead of checking IP addresses, it uses public-key cryptography to verify that the email content hasn't been tampered with after sending.

When your agent sends a message, the mail server signs selected headers and the body with a private key. That signature gets added as a DKIM-Signature header. The receiving server then looks up the corresponding public key in a DNS TXT record on your domain (identified by a "selector," which is just a label like s1 or mail) and uses it to verify the signature.

s1._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

If the signature checks out, DKIM passes. If someone altered the message in transit, or if the signing key doesn't match the published public key, it fails.

DKIM selectors matter more than most people realize. Each selector points to a different key pair, so you can rotate keys without breaking existing mail flows, or use separate selectors for separate sending services. If your agent uses one email provider and your human team uses another, each service gets its own selector on the same domain.

The operational challenge for agents is similar to SPF: someone with DNS access needs to publish the DKIM public key before the agent can send authenticated mail. The agent itself can't do this step.

How DMARC ties it together#

DMARC builds on top of SPF and DKIM. It does two things that neither protocol handles alone.

First, it introduces "alignment." SPF checks the envelope sender (the Return-Path), and DKIM checks whatever domain signed the message. But neither one verifies that those domains match the From address that the recipient actually sees. DMARC requires that at least one of them aligns with the visible From domain. This closes a common spoofing gap where an attacker passes SPF with their own domain but forges the From header.

Second, DMARC publishes a policy telling receiving servers what to do with messages that fail:

• p=none monitors failures but delivers everything. Good for initial setup.
• p=quarantine routes failing messages to spam.
• p=reject blocks failing messages entirely.

A DMARC record looks like this:

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

The rua tag sends aggregate reports to the specified address, which is useful for debugging. But here's the catch: if your DMARC policy is set to reject and your agent's emails fail either SPF or DKIM alignment, those messages get permanently blocked. There's no retry, no second chance. The receiving server follows the policy you published.

This is why the "550 denied by policy" error is so common in agent deployments. The domain has a strict DMARC policy, but the agent's sending infrastructure wasn't properly added to SPF or DKIM. The fix isn't to relax the DMARC policy (that weakens security for everyone on the domain). The fix is to get authentication right at the source.

Why this is harder for agents than for humans#

A human developer setting up email authentication follows a predictable flow: pick a sending service, add SPF and DKIM records to DNS, set a DMARC policy, wait for propagation (usually 15 minutes to 48 hours), send a test email, check the headers.

An autonomous agent can't do most of those steps. It doesn't have DNS credentials. It can't wait 48 hours for propagation. It can't open an email client to inspect headers. And if something fails, it often can't diagnose whether the problem is SPF, DKIM, DMARC alignment, or something else entirely.

This creates a real gap. Agents are great at sending email programmatically, but the infrastructure that makes those emails trustworthy still assumes a human is doing the setup.

There are two ways to solve this.

Option one: pre-configure everything manually. Set up your custom domain with proper SPF, DKIM, and DMARC records before the agent ever sends a message. This works, but it means your agent isn't truly autonomous. Someone has to do DNS work upfront, and if anything changes (new sending service, key rotation, SPF record hitting the lookup limit), a human has to intervene.

Option two: use managed infrastructure where authentication is pre-configured. This is the approach LobsterMail takes. When your agent provisions an inbox on @lobstermail.ai, SPF, DKIM, and DMARC are already configured on that domain. The agent doesn't touch DNS. It doesn't wait for propagation. It creates an inbox and sends authenticated email immediately.

For custom domains on the Builder plan ($9/mo), LobsterMail provides the exact DNS records you need to add once, and then handles signing and authentication automatically after that.

Checking your authentication setup#

If your agent is already sending email and you want to verify that authentication is passing, there are a few approaches.

The simplest: send an email to a Gmail address, open it, click the three dots menu, and select "Show original." You'll see the authentication results right at the top:

SPF: PASS
DKIM: PASS
DMARC: PASS

If any of those show FAIL, you know exactly which protocol needs attention.

For programmatic checking, tools like dig can query your DNS records directly:

dig TXT yourdomain.com +short
dig TXT s1._domainkey.yourdomain.com +short
dig TXT _dmarc.yourdomain.com +short

If any of these return empty, that record isn't published yet.

You can also use free online tools like MXToolbox or dmarcian to get a full authentication audit of your domain. They'll flag missing records, SPF lookup limits, and DKIM key issues.

The practical recommendation#

If your agent sends email from a custom domain, set up all three protocols before the first message goes out. Not after deliverability drops, not after Gmail starts rejecting messages. Before.

If you don't want to manage DNS records and authentication infrastructure yourself, use a domain that already has it configured. LobsterMail's managed @lobstermail.ai domain ships with SPF, DKIM, and DMARC from the moment your agent creates an inbox. No DNS, no propagation wait, no 10-lookup math. Your agent calls createSmartInbox(), gets an address, and sends authenticated email on the first try.