spf, dkim, and dmarc setup for ai agent senders

Your agent composed a perfect follow-up email. The recipient never saw it. Gmail quietly routed it to spam because the sending domain had no SPF record, no DKIM signature, and no DMARC policy. The email was technically flawless and cryptographically anonymous.

Email authentication exists to answer one question: is this sender allowed to use this domain? When a human sends email through Gmail or Outlook, the provider handles authentication automatically. When an AI agent sends email through an API or SMTP relay, nobody sets it up unless you do. And most agent builders skip it, either because they don't know it's required or because DNS records feel like a problem for later.

It's not a problem for later. Gmail and Outlook both enforce strict authentication requirements for bulk senders as of 2025. If your agent sends more than a handful of emails per day without proper SPF, DKIM, and DMARC records, those messages will be rejected or filtered before the subject line is ever read.

Here's what each protocol does, how to configure them, and the specific decisions that matter when your sender is an autonomous agent rather than a person.

What SPF, DKIM, and DMARC actually do#

These three protocols work together, but they solve different problems.

SPF (Sender Policy Framework) tells receiving servers which IP addresses are allowed to send email on behalf of your domain. It's a DNS TXT record that lists authorized senders. When your agent sends through a mail service, that service's IPs need to appear in your SPF record, or the message fails the check.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing message. You generate a key pair, publish the public key as a DNS TXT record, and your sending service signs each email with the private key. The recipient's server uses the public key to verify the message wasn't altered in transit and actually originated from your domain.

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 (p=none), quarantine the message (p=quarantine), or reject it outright (p=reject). DMARC also requires alignment, meaning the domain in the From: header must match the domain authenticated by SPF or DKIM.

The short version: SPF says who can send, DKIM proves the message is genuine, and DMARC decides what happens when either check fails.

How to set up SPF, DKIM, and DMARC for an AI agent sender#

Whether your agent sends through LobsterMail, a transactional provider, or your own mail server, the DNS setup follows the same steps:

1. Create a dedicated sending subdomain (e.g., mail.yourdomain.com).
2. Add an SPF TXT record authorizing your sending service's IPs.
3. Generate a DKIM key pair and publish the public key as a DNS TXT record.
4. Configure your agent's sending service to sign outbound messages with the private key.
5. Publish a DMARC TXT record starting with p=none and a rua reporting address.
6. Monitor aggregate reports for 2-4 weeks.
7. Escalate to p=quarantine, then p=reject after clean reports.

Each step is straightforward on its own. The part that trips up agent builders is the order and the waiting. Let's walk through the details.

Why agents should use a dedicated subdomain#

If your agent sends from yourdomain.com directly, every authentication failure and spam complaint hits your root domain's reputation. One bad week of agent emails can tank deliverability for your human team's messages too.

A subdomain like agent.yourdomain.com or mail.yourdomain.com isolates reputation. If the agent's sending patterns trigger a temporary blocklist, your root domain stays clean. This is cheap insurance, and it costs nothing beyond a few extra DNS records.

Set up all three authentication records (SPF, DKIM, DMARC) on the subdomain independently from whatever your root domain already has.

Setting up SPF#

Add a TXT record to the DNS zone of your sending subdomain. The value depends on which service your agent sends through:

mail.yourdomain.com.  IN  TXT  "v=spf1 include:_spf.sendingservice.com ~all"

The include: directive delegates authorization to your sending provider. They'll tell you the exact value. If your agent uses more than one sending service, you can chain multiple includes:

"v=spf1 include:_spf.service1.com include:_spf.service2.com ~all"

Keep the total number of DNS lookups under 10. SPF has a hard limit of 10 lookups per evaluation. Every include: triggers at least one, and nested includes count toward the total. Most agents only need one or two sending services, so this rarely becomes a problem in practice.

The ~all at the end is a softfail. It tells receiving servers that senders not listed in the record are probably unauthorized but shouldn't be outright rejected. Once you've confirmed everything works, switch to -all (hardfail) to tell servers to reject unauthorized senders. The practical difference: softfail is forgiving during setup, hardfail is strict for production.

Setting up DKIM#

DKIM requires a key pair. Most sending services generate this for you and give you a CNAME or TXT record to add to your DNS. The record looks something like:

selector._domainkey.mail.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb..."

The selector is a label your sending service chooses (often something like s1 or default). The p= value is the public key. When your agent sends an email, the service signs the message headers with the private key. The recipient's server fetches the public key from DNS and verifies the signature.

If you're running your own mail infrastructure (Postfix, for example), you'll generate the key pair yourself using OpenSSL and configure your MTA to sign messages. For most agent builders using a managed sending service, you just copy-paste the DNS record they provide.

Rotating DKIM keys#

Keys should be rotated periodically. The safest approach: publish a new key under a new selector, update your sending config to use the new selector, wait 48 hours for DNS propagation and cached signatures to expire, then remove the old record. Never delete the old record before the new one is active, or in-flight messages signed with the old key will fail verification.

Setting up DMARC#

DMARC is the policy layer. Add a TXT record at _dmarc.mail.yourdomain.com:

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

Start with p=none. This tells receiving servers to send you reports about authentication results without taking any action on failing messages. You'll receive XML aggregate reports at the rua address. These reports show which IPs are sending email as your domain, whether they pass SPF and DKIM, and how many messages are involved.

After 2-4 weeks of clean reports (meaning all your agent's legitimate emails pass both SPF and DKIM), escalate to p=quarantine. This sends failing messages to the spam folder instead of ignoring them. After another few weeks of clean data, move to p=reject, which blocks unauthenticated messages entirely.

This gradual rollout matters for agents. Unlike a human employee who sends 20 emails a day, an agent might send hundreds or thousands from its first week. Starting at p=reject with no monitoring period means any misconfiguration silently drops real messages.

DMARC alignment#

DMARC checks alignment between the From: header domain and the domain authenticated by SPF or DKIM. If your agent sends from agent@mail.yourdomain.com but SPF authenticates against sendingservice.com, that's a mismatch. DKIM alignment usually solves this because the DKIM signature is tied to your domain, not the service's. Make sure at least one of SPF or DKIM aligns with the From: domain.

Technically, DMARC passes if either SPF or DKIM aligns. In practice, configure both. If one breaks temporarily (DNS issue, key rotation, provider change), the other keeps your messages authenticated.

Gmail and Outlook 2025 bulk sender requirements#

Google and Microsoft both tightened their requirements for senders delivering more than 5,000 messages per day. The rules are simple: you need valid SPF, DKIM, and DMARC records. You need a one-click unsubscribe header for marketing messages. And your spam complaint rate must stay below 0.3%.

These requirements apply to AI-generated emails too. Gmail doesn't distinguish between a human composing a message and an agent composing one. The domain and its authentication records are what matter. If your agent sends transactional emails (receipts, confirmations, notifications), the unsubscribe requirement doesn't apply, but SPF, DKIM, and DMARC are non-negotiable regardless of message type.

Verifying your records#

After adding all three records, verify them before your agent sends a single message:

# Check SPF
dig TXT mail.yourdomain.com +short

# Check DKIM (replace 'selector' with your actual selector)
dig TXT selector._domainkey.mail.yourdomain.com +short

# Check DMARC
dig TXT _dmarc.mail.yourdomain.com +short

DNS propagation typically takes 15 minutes to 48 hours, depending on your registrar and TTL settings. Tools like MXToolbox and Google's Check MX can validate that your records are syntactically correct and reachable.

Send a test email to a Gmail account and inspect the message headers. Look for spf=pass, dkim=pass, and dmarc=pass in the Authentication-Results header. If any of the three shows fail or none, trace back to the DNS record for that protocol.

Where LobsterMail fits#

If you're using LobsterMail, SPF and DKIM are configured automatically for your agent's inbox. The default lobstermail.ai domain comes with authentication already in place, so your agent can start sending without touching DNS at all. If you connect a custom domain on the Builder plan, LobsterMail provides the exact SPF include: and DKIM CNAME records to add. The custom domains guide walks through the setup.

For everyone else, the records described above are what you need. The protocols are the same whether your agent sends 10 emails a day or 10,000.