dmarc setup for ai agent sender

Last month I watched someone burn a perfectly good domain in two days. Their agent sent 400 outreach emails from a new address with no DMARC record, no warm-up, and SPF that pointed to the wrong server. Gmail flagged the domain. Yahoo followed. By Thursday the domain's reputation was so low that even a password reset email from their SaaS product landed in spam.

DMARC isn't optional anymore. Google and Yahoo's 2024 bulk sender requirements made that explicit: if you send more than 5,000 messages a day, you need a published DMARC policy. But even if your agent sends 50 emails a day, a missing DMARC record tells receiving servers you don't care whether someone spoofs your domain. That's not a signal you want to send.

This guide walks through DMARC setup for AI agent senders, from the first DNS record to full enforcement. If you've already got SPF and DKIM in place, you're halfway there. If you don't, we'll cover those too.

How SPF, DKIM, and DMARC work together#

Think of email authentication as three checks that happen before a message reaches anyone's inbox.

SPF (Sender Policy Framework) is a DNS record that lists which servers are allowed to send email for your domain. When your agent sends a message through a mail server, the recipient checks whether that server's IP appears in your SPF record. If it doesn't, the message fails SPF.

DKIM (DomainKeys Identified Mail) is a cryptographic signature attached to every outgoing message. Your sending server signs the email with a private key. The recipient looks up the public key in your DNS and verifies the signature matches. If someone tampered with the message in transit, DKIM fails.

DMARC ties them together. It tells receiving servers what to do when both SPF and DKIM fail, and where to send reports about authentication results. Without DMARC, a receiving server might silently accept a forged email from your domain. With DMARC set to p=reject, that forged email gets dropped.

Here's the part most guides skip: DMARC requires alignment, not just a pass. SPF alignment means the domain in the Return-Path header matches the domain in the From header. DKIM alignment means the domain in the DKIM signature (d= tag) matches the From domain. If your agent sends from agent@yourdomain.com but the Return-Path says bounce@some-other-service.com, SPF might pass but DMARC alignment fails. This is the most common reason agent emails pass individual checks but still land in spam.

How to set up DMARC for an AI agent sender (step-by-step)#

1. Publish a TXT record at _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com to start collecting reports without affecting delivery.
2. Send test emails from your agent and monitor aggregate reports for one to two weeks, looking for SPF or DKIM alignment failures.
3. Confirm that every legitimate sending path (your agent's email platform, transactional services, marketing tools) is properly SPF and DKIM aligned with your From domain.
4. Upgrade your policy to p=quarantine and monitor for another two weeks, checking that no legitimate mail is being flagged.
5. Advance to p=reject for full enforcement once you're confident all legitimate senders are aligned.

Each step matters. Jumping straight to p=reject on a domain where your agent sends through multiple services is how you accidentally quarantine your own emails.

The DNS records you actually need#

For a domain called yourdomain.com, you'll need three TXT records.

SPF record (on yourdomain.com):

v=spf1 include:your-email-provider.com -all

Replace your-email-provider.com with whatever service your agent uses to send. The -all at the end means "reject everything not listed." If your agent sends through multiple services, add each one with a separate include:.

DKIM record (on selector._domainkey.yourdomain.com):

v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY_HERE

Your email provider gives you the selector name and the public key. You paste them into DNS. The private key stays on the sending server and signs every outgoing message.

DMARC record (on _dmarc.yourdomain.com):

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; adkim=r; aspf=r

The rua address receives aggregate reports (daily summaries of authentication results). The ruf address receives forensic reports (details about individual failures). Some providers don't send forensic reports, so rua is the one that matters. The adkim=r and aspf=r tags set relaxed alignment, meaning subdomains can align with the parent domain. This is usually what you want for agent deployments.

Why agents create unique DMARC alignment problems#

A human sends email from one account through one provider. An AI agent might send from multiple inboxes, across multiple workflows, at variable volumes that spike unpredictably. Each sending path needs to be aligned independently.

Consider a common pattern: your agent provisions an inbox, sends a few welcome emails, then goes quiet for a week, then sends 200 follow-ups in an afternoon. Receiving servers notice these volume spikes. Without authentication in place, that kind of pattern looks a lot like a compromised account or a spam bot.

Multi-tenant deployments add another layer. If your agent sends on behalf of multiple customers, each customer's domain needs its own DMARC setup. You can't publish one SPF record that covers all of them. This is where subdomain policies (sp= in your DMARC record) become useful. Setting sp=reject on the organizational domain while using p=quarantine on agent-specific subdomains gives you enforcement at the top level with room to monitor new sending patterns on subdomains.

Or you skip all of that complexity. Managed inbox platforms like LobsterMail ship with SPF, DKIM, and DMARC pre-configured on every inbox your agent provisions. Your agent calls createInbox(), gets an address with authentication already passing, and starts sending. No DNS records to edit, no alignment to debug. The trade-off is you're sending from LobsterMail's domain (or a custom domain you've verified), not from agent@yourcustomdomain.com with self-managed DNS. For most agent builders, that trade-off saves a week of setup.

Reading DMARC aggregate reports#

DMARC reports arrive as XML files attached to emails sent to your rua address. They look terrible in raw form, but the data is straightforward.

Each report tells you: which IPs sent email claiming to be from your domain, whether SPF passed or failed, whether DKIM passed or failed, and what disposition was applied (none, quarantine, or reject). If you see an IP you don't recognize sending as your domain, someone is spoofing you. If you see your agent's IP failing DKIM, your signing configuration is wrong.

Free tools like the Postmark DMARC analyzer or MXToolbox's DMARC report parser turn these XML files into readable dashboards. Set one up during your p=none monitoring phase so you're actually looking at the data, not just collecting it.

Moving from p=none to p=reject#

The monitoring phase isn't a formality. I've seen teams discover that their CRM, their transactional email service, and their agent platform were all sending as the same domain with only one of them in the SPF record. If they'd started at p=reject, two thirds of their email would have bounced.

Here's a reasonable timeline:

• Weeks 1-2 (p=none): Collect reports. Identify every service that sends as your domain. Fix any SPF or DKIM alignment failures.
• Weeks 3-4 (p=quarantine): Failed messages go to spam instead of being delivered normally. Watch for complaints from recipients who should be getting your email.
• Week 5+ (p=reject): Full enforcement. Unauthenticated messages are dropped. Your domain is protected from spoofing.

Two weeks per phase is a minimum. If your agent's sending volume is low, you might need longer to collect enough report data. If you're sending thousands of messages a day, two weeks gives you plenty of signal.

One thing worth noting: DMARC records propagate through DNS, which means changes can take up to 48 hours to take effect globally. Don't change your policy at 9 AM and assume it's live everywhere by noon.

Recovering from a damaged sender reputation#

If your agent has been sending without DMARC for a while and your domain reputation is already low, adding DMARC alone won't fix things overnight. Reputation is built on consistent, authenticated, low-complaint sending over time.

Start by fixing authentication (the steps above). Then reduce your agent's sending volume to a fraction of what it was. Gradually increase over two to four weeks while monitoring bounce rates and spam complaints. This is essentially a warm-up process, and it works the same whether you're warming a new domain or rehabilitating a damaged one.

If your domain reputation is truly buried, it might be faster to move your agent to a new subdomain (like mail.yourdomain.com), set up clean authentication from the start, and warm it up properly. The old subdomain's reputation doesn't automatically infect the new one, as long as the new one has its own SPF, DKIM, and DMARC records.

The simpler path#

Everything above is the right way to do it yourself. It works. It's also a week of DNS record management, report monitoring, and policy iteration before your agent sends a single authenticated email.

If you'd rather skip the DNS configuration, set up LobsterMail and let your agent provision its own inbox. Every inbox comes with SPF, DKIM, and DMARC passing out of the box. Your agent spends its time sending email instead of debugging TXT records.