how to set up spf, dkim, and dmarc for ai agent email

Your AI agent just sent a password reset confirmation to a user. The email never arrived. No bounce notification, no error in your logs. It simply vanished into the recipient's spam folder because Gmail couldn't verify who sent it.

This is the default outcome for most agent-built email in 2026. Gmail, Yahoo, and Outlook now reject or quarantine unauthenticated mail with zero tolerance. If your agent sends email from a domain without SPF, DKIM, and DMARC records, those messages are dead on arrival.

The good news: setting this up correctly takes about 30 minutes, and once it's done, you don't touch it again. Here's exactly how to do it.

How to set up SPF, DKIM, and DMARC for an AI agent (step-by-step)#

1. Choose a dedicated subdomain for your agent's mail (e.g. agent.yourdomain.com) to isolate its sender reputation from your root domain.
2. Add a TXT record for SPF at agent.yourdomain.com listing your sending service's IP or include statement.
3. Generate a DKIM key pair and publish the public key as a TXT record at selector._domainkey.agent.yourdomain.com.
4. Configure your mail library or sending service to sign every outbound message with the DKIM private key.
5. Publish a DMARC TXT record at _dmarc.agent.yourdomain.com starting with p=none.
6. Monitor DMARC aggregate reports for two weeks, then advance to p=quarantine, then p=reject.
7. Validate the full setup with a tool like MXToolbox or mail-tester.com before letting your agent send production email.

That's the overview. Let's break each piece down.

What SPF, DKIM, and DMARC actually do#

These three protocols solve different parts of the same problem: proving that an email really came from who it claims to come from.

SPF (Sender Policy Framework) tells receiving servers which IP addresses are allowed to send mail for your domain. It's a DNS TXT record that lists your authorized senders. When Gmail receives a message claiming to be from agent.yourdomain.com, it checks the SPF record to see if the sending IP is on the list. If not, the message fails SPF.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing email. The receiving server looks up your public key in DNS and verifies the signature. This proves the message wasn't tampered with in transit and that it was signed by someone holding your private key.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy. It tells receiving servers what to do when authentication fails: nothing (none), quarantine the message, or reject it outright. It also sends you reports so you can see exactly what's passing and failing.

You need all three. SPF without DKIM means a forwarded email fails authentication. DKIM without SPF means anyone can spoof your domain's envelope sender. Either one without DMARC means receiving servers make their own decisions about what to do with failures, and those decisions won't be in your favor.

Setting up SPF for your agent's sending domain#

SPF is the simplest record to configure. It's a single TXT record on your sending domain.

agent.yourdomain.com.  IN  TXT  "v=spf1 include:_spf.sendingprovider.com ~all"

Replace _spf.sendingprovider.com with the include statement from your actual email sending service. Every provider documents this. If your agent sends through multiple services, you add multiple include: entries to the same record.

One thing catches people off guard: SPF has a 10-lookup limit. Each include: triggers one or more DNS lookups, and the total across all nested includes can't exceed 10. If your agent stack uses three or four SaaS services that each need an SPF include, you'll hit this limit fast. The fix is called SPF flattening, which resolves the nested includes into static IP addresses. Tools like AutoSPF or SPF Toolbox handle this automatically.

A common mistake with agent setups: your agent provisions an inbox through one service but tries to send through a different SMTP relay. The SPF record needs to list every sending source, not just your primary one.

Configuring DKIM for your AI agent#

DKIM requires two things: a key pair and a DNS record.

Most sending providers generate the key pair for you and give you a CNAME or TXT record to publish. If you're rolling your own with a library like nodemailer, you'll generate the keys yourself:

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem
Then publish the public key in DNS:

selector._domainkey.agent.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY_BASE64"

The selector is a label you choose (like agent1 or mail2026). It lets you rotate keys without breaking existing signatures. This matters when you run multiple agents on the same domain. Each agent can use its own DKIM selector, scoping its signing key independently.

Your agent's mail library needs the private key to sign outgoing messages. Store it securely. If you're using a managed sending service, they handle the signing automatically once you publish the DNS record.

Publishing a DMARC policy#

DMARC goes at _dmarc.agent.yourdomain.com:

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

Start with p=none. This tells receiving servers to deliver everything regardless of authentication results, but send you aggregate reports about what's passing and failing. Those reports arrive as XML files to the rua address, and they're unreadable without a tool. Services like PowerDMARC, EasyDMARC, or the free Postmark DMARC tool parse them into human-friendly dashboards.

After two weeks of clean reports (SPF and DKIM both passing consistently), move to p=quarantine. This sends failing messages to spam instead of the inbox. Run that for another two weeks. If nothing breaks, move to p=reject, which tells receiving servers to drop failing messages entirely.

The reason for this gradual rollout: if your SPF record is missing an include, or DKIM isn't signing correctly, p=reject will silently kill legitimate email from your agent. Starting at none lets you find those problems without losing real messages.

Why your agent should send from a subdomain#

Don't let your agent send from your root domain. If your agent misconfigures something, sends too aggressively, or triggers spam complaints, the reputation damage hits your root domain. That means your human team's email, your transactional email, your marketing email, everything suffers.

A dedicated subdomain like agent.yourdomain.com or mail.yourdomain.com isolates the blast radius. If the subdomain's reputation tanks, your root domain stays clean. You can spin up a new subdomain and start fresh. You can't do that with your primary domain.

This also makes multi-agent setups cleaner. If you run three agents that each handle different types of email, you can scope each to its own subdomain with its own SPF, DKIM selector, and DMARC policy. One agent's reputation issues don't contaminate the others.

When your emails still land in spam after setup#

You've configured all three records, tested them, everything passes. But emails still go to spam. This happens, and it's almost never an authentication problem at that point.

Common causes: your sending IP is on a blocklist (check with MXToolbox), your email content triggers spam filters (too many links, suspicious phrasing, missing unsubscribe headers), or your domain is brand new with no sending history. New domains need warming. Start with 10-20 emails per day and increase gradually over two to four weeks. An agent that provisions a fresh domain and immediately fires off 500 messages will get flagged regardless of perfect SPF, DKIM, and DMARC.

Also check DMARC alignment. SPF and DKIM can both pass individually but still fail DMARC if the domains don't align. SPF alignment means the envelope MAIL FROM domain matches the From header domain. DKIM alignment means the d= domain in the DKIM signature matches the From header domain. Misalignment is one of the most common reasons agent emails fail authentication even when the records look correct.

The zero-configuration alternative#

All of this setup is necessary when your agent sends from your own domain. But if you're prototyping, running a side project, or just don't want to spend an afternoon in your DNS provider's dashboard, there's a simpler path.

LobsterMail's @lobstermail.ai addresses ship with SPF, DKIM, and DMARC pre-configured. Your agent provisions an inbox and starts sending authenticated email immediately, no DNS records to publish, no keys to manage. When you're ready to use your own domain, LobsterMail's custom domains guide walks through the DNS setup and handles DKIM signing for you.

If you want your agent sending authenticated email in under a minute, grab an inbox here and skip straight to the part where your agent actually does useful work.