what is a DMARC policy and why it matters for agent email

Every email your agent sends gets judged before a human ever sees it. The receiving mail server checks authentication records, compares them against the message headers, and decides whether to deliver, quarantine, or reject. DMARC is the policy that drives that decision. If your agent sends email without understanding DMARC, it's rolling dice on whether anyone actually reads the message.

This isn't a new protocol. DMARC has been around since 2012. But 2026 is different. Google, Microsoft, and Yahoo now enforce DMARC checks on all inbound mail, and domains without a published policy face increasing deliverability penalties. For AI agents that send email programmatically, getting DMARC wrong means silent failure at scale.

What is a DMARC policy?#

A DMARC policy is a rule published in your domain's DNS that tells receiving mail servers how to handle messages failing SPF or DKIM authentication. It has three enforcement levels: none (monitor only), quarantine (send to spam), and reject (block entirely). DMARC prevents domain spoofing and phishing by letting domain owners control what happens to unauthenticated email sent from their domain.

That definition covers the mechanics, but the real-world impact is simpler: DMARC is how you tell Gmail, Outlook, and every other mail provider "if someone fakes my domain, here's what to do about it."

Without a DMARC record, receiving servers make their own judgment call. Sometimes they deliver. Sometimes they don't. You have no visibility and no control.

How DMARC, SPF, and DKIM work together#

DMARC doesn't authenticate email by itself. It sits on top of two older protocols and combines their results.

SPF (Sender Policy Framework) lists which IP addresses are authorized to send email for your domain. It's a DNS TXT record that says "these servers can send as yourdomain.com." When a message arrives, the receiving server checks whether the sending IP matches the SPF record.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing message. The receiving server verifies that signature against a public key published in your DNS. If the signature checks out, the message hasn't been tampered with in transit.

DMARC checks whether at least one of these protocols passes and aligns with the domain in the From: header. That alignment piece is what makes DMARC different from running SPF and DKIM alone. A message could pass SPF but fail alignment if the envelope sender domain doesn't match the From: domain. DMARC catches that gap.

Think of it as a chain: SPF and DKIM do the authentication work. DMARC decides what happens when they fail.

The three DMARC policy levels#

p=none (monitor mode)#

The none policy tells receiving servers to deliver the email regardless of authentication results, but send reports back to you. This is the starting point. You're watching traffic without blocking anything.

It's useful for discovery. You'll see which services, agents, and third parties are sending email as your domain. Some of them you authorized. Some you forgot about. Some you've never heard of.

The catch: p=none offers zero protection against spoofing. Anyone can still forge your domain.

p=quarantine (spam folder)#

With quarantine, messages that fail DMARC authentication get routed to the recipient's spam or junk folder. They're not blocked outright, but they're effectively buried. Most recipients never check spam.

This is the middle step. You've reviewed your reports, confirmed that your legitimate senders pass authentication, and you're ready to start penalizing failures.

p=reject (full block)#

The reject policy tells receiving servers to drop unauthenticated messages entirely. They never reach the inbox, never hit spam. They're gone.

This is the goal. In 2026, email deliverability depends on strong authentication, and p=reject is what major providers want to see. PowerDMARC's 2026 predictions recommend moving all sending domains to p=reject or at minimum p=quarantine.

What a DMARC record looks like#

A DMARC record is a DNS TXT entry published at _dmarc.yourdomain.com. Here's a typical one:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100; adkim=r; aspf=r
Breaking that down:

- `v=DMARC1` identifies the record version
- `p=quarantine` sets the policy for failing messages
- `rua=mailto:dmarc-reports@yourdomain.com` tells servers where to send aggregate reports
- `pct=100` applies the policy to 100% of messages (you can lower this during rollout)
- `adkim=r` and `aspf=r` set relaxed alignment (subdomains count as matching)

One common mistake: setting up the rua address and never checking it. Those reports are XML files, and they contain the data you need to find authentication gaps. If you're not reading them, your DMARC record is a decorative DNS entry.

Why agents trip over DMARC more than humans do#

A human sending email from Gmail doesn't think about DMARC. Google handles SPF, DKIM, and alignment automatically. The human just types and clicks send.

Agents don't get that luxury when they send from custom domains. An agent provisioning its own email, spinning up inboxes programmatically, and sending from a domain it just started using will fail DMARC checks if the authentication records aren't configured first.

The failure modes are specific to automated systems:

SPF lookup limits. SPF allows a maximum of 10 DNS lookups per record. When multiple services and agents all add their include: directives to a single SPF record, you hit the limit fast. Exceeding it causes a permerror, which DMARC treats as a failure. If you're running several agents or SaaS tools that send on your behalf, this is the first thing that breaks.

Alignment mismatches. An agent might send email with a From: header of agent@yourdomain.com but the actual SMTP envelope uses a different subdomain for bounce handling. If DMARC alignment is set to strict (adkim=s), that's a failure even though DKIM passed.

No warm-up awareness. Agents can send hundreds of messages immediately. A brand-new domain jumping straight to p=reject with high volume looks suspicious to receiving servers, regardless of authentication. The common setup mistakes that kill deliverability are amplified when there's no human in the loop to pace things.

The rollout sequence that actually works#

Moving from no DMARC to full enforcement should be gradual. Here's the sequence I'd recommend, especially if agents are sending on your domain:

Week 1-2: Publish p=none with a valid rua address. Collect data. Identify every service and agent that sends as your domain.

Week 3-4: Fix any SPF and DKIM issues you found in the reports. Make sure every legitimate sender passes alignment. This is where you discover the forgotten marketing tool still using your domain or the agent sending from a misconfigured subdomain.

Week 5-6: Move to p=quarantine; pct=25. Apply the policy to 25% of failing messages. Monitor for legitimate mail getting caught.

Week 7-8: Increase to pct=100 on quarantine. If nothing breaks, move to p=reject.

The whole process takes about two months. Rushing it risks blocking your own email.

DMARC on shared email infrastructure#

If you're using a custom domain for agent email, DMARC configuration is your responsibility. You publish the DNS records, you manage SPF includes, and you monitor the reports.

If your agent uses a shared domain (like @lobstermail.ai), the infrastructure provider handles DMARC for that domain. LobsterMail publishes SPF, DKIM, and DMARC records for lobstermail.ai so agents sending from that domain pass authentication automatically. There's nothing to configure.

That's one of the practical advantages of using managed email infrastructure for agents. DMARC alignment, DKIM signing, and SPF are handled at the platform level. Your agent focuses on what it's actually trying to do instead of debugging DNS records.

DMARC reporting: what to actually look at#

Aggregate reports (rua) arrive as XML files, usually daily. They tell you:

• Which IPs sent email as your domain
• Whether each message passed or failed SPF, DKIM, and DMARC
• The policy applied (none, quarantine, reject)
• The volume of messages from each source

Forensic reports (ruf) contain details about individual failures. Most large providers don't send these anymore due to privacy concerns, so don't rely on them.

The single most useful thing in aggregate reports is the list of sending IPs. If you see IPs you don't recognize passing authentication, someone may have compromised a service that sends on your behalf. If you see your own IPs failing, you have a configuration problem.

Tools like MXToolbox, PowerDMARC, and Google Postmaster Tools can parse these reports into readable dashboards. Raw XML is technically sufficient but practically miserable.

What to do right now#

If your domain has no DMARC record, publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com today. It takes five minutes and starts collecting data immediately. You lose nothing by monitoring.

If you're already at p=none and have been for months, review your reports and start moving toward p=quarantine. The longer you sit at none, the longer your domain is unprotected against spoofing.

If your agent sends from a managed domain like @lobstermail.ai, DMARC is handled for you. If it sends from your own domain, treat DMARC configuration as a prerequisite, not an afterthought.