---
title: The compliance floor for email an AI agent sends
metaTitle: GDPR, CAN-SPAM, and CASL for AI agent email
description: An agent sending on your behalf is you sending. What CAN-SPAM, GDPR, PECR, and CASL require, how unsubscribe and suppression have to work, and what to do about disclosure and retention.
date: 2026-07-28
author: MCPmailer
tags: Operations
---

Automation does not create an exemption. An agent sending on your behalf is you sending, and every obligation that applied to your marketing team applies to a model with an inbox. The good news is that the obligations are stable, well documented, and mostly satisfied by infrastructure rather than by anyone remembering.

![Sending obligations attaching to an agent's messages](/blog/ai-email-compliance-gdpr-canspam/hero.webp "The obligations attach to the sender, and the sender is you.")

This is not legal advice. It is the shape of the thing, so you know what to ask your lawyer and what to build before you do.

## The four regimes worth knowing

| Regime | Where | The short version |
| --- | --- | --- |
| CAN-SPAM | United States | Accurate headers and subject, a physical postal address, a working opt-out honoured promptly, no misleading content |
| GDPR | EU and EEA | A lawful basis for processing personal data, transparency about who is processing it, and rights over it |
| PECR | UK | Consent for marketing to individuals, with a narrow soft opt-in for existing customers |
| CASL | Canada | Consent in most cases, plus identification and a working unsubscribe |

Two things follow that people find counterintuitive. Email addresses are personal data under GDPR, so a contact record with recorded facts about a person is a processing activity with obligations attached. And a reply to someone who wrote to you is a very different legal object from a message to someone who did not, which is why the [distinction between replies and cold sends](/blog/stopping-agent-email-spam) is a compliance boundary and not just a deliverability one.

## Unsubscribe has to be enforced below the agent

The rule that matters most in practice: an opt-out must be honoured by your infrastructure, not by a model remembering. A prompt instruction to respect unsubscribes is a preference and will eventually lose to a goal.

Three requirements, and all three are ordinary engineering.

**Every cold send carries a working opt-out.** MCPmailer attaches an unsubscribe link to sends classified as cold, which is the category the law is aimed at.

**Opting out suppresses the address permanently and immediately.** Not at the next sync, not after the current sequence finishes. A suppressed recipient produces `recipient_suppressed` on any further attempt, which is the correct behaviour: refusal at the infrastructure layer rather than a well-behaved agent.

**A reply saying "stop" counts.** Legally it counts; practically, an agent that only honours a link click will generate complaints. Detect the obvious phrases, suppress on them, and escalate anything ambiguous to a person rather than guessing.

> [!note]
> Test your own opt-out path quarterly by using it. The number of companies whose unsubscribe silently fails is remarkable, and finding out from a regulator is the expensive way.

## Identification, and the disclosure question

Every jurisdiction requires the recipient to know who is writing. Practically that means a real sending domain, a real reply-to that a human can reach, and a physical postal address on anything cold.

Whether an agent must disclose that it is an agent is unsettled and tightening: the EU AI Act's transparency obligations point that way for systems interacting with people, and several jurisdictions are moving similarly. The practical answer is easy, because the incentives already point at disclosure. An assistant that says it is an assistant performs about as well, and it avoids the worst outcome, which is a recipient discovering it mid-thread and telling everyone. Say it once, plainly, and give a fast path to a person.

## Records, retention, and deletion requests

An agent inbox accumulates personal data quickly: message bodies, contact records, recorded facts, attachments containing CVs and invoices. GDPR requires that you keep it only as long as you need it, keep it accurate, and be able to delete it on request.

Three habits cover most of it.

- **Archive what you have dealt with,** and decide a retention period per category rather than keeping everything forever by default.
- **Keep recorded facts relevant and factual.** Write facts you would be comfortable showing the person they describe, per [giving an email agent memory](/blog/agent-memory-contacts-email).
- **Know how to answer a deletion request** across the mailbox, the contact record, and any copy your own systems hold. If you cannot answer it in an afternoon, that is the gap.

Our side of this, including what we process and for how long, is in the [privacy policy](/legal/privacy), and the contract for processing on your behalf is the [data processing addendum](/legal/dpa), with the sub-processors listed at [subprocessors](/legal/subprocessors).

![Retention decided per category rather than kept by default](/blog/ai-email-compliance-gdpr-canspam/retention.webp "Deciding retention is a five minute conversation. Not deciding it is a permanent liability.")

## Where an agent adds genuinely new risk

Beyond the familiar obligations, three things are specific to a model with a mailbox.

**It can be talked into it.** A message can persuade an agent to send data somewhere, which under GDPR is a personal data breach with a 72 hour notification clock. The architectural defences are in [prompt injection by email](/blog/prompt-injection-email-agents), and the point here is that this failure has a legal shape as well as a technical one.

**Volume arrives faster than review.** A person sending unlawful mail does it slowly. An agent does not, so the gap between a mistake and a large number of affected people is minutes. Metering and tripwires are what buy you that time.

**Attribution has to survive.** When someone asks who sent a message, "one of our agents" is not an answer. One identity and one key per agent is what makes the audit trail answer the question, as argued in [agent inbox or shared mailbox](/blog/agent-inbox-vs-shared-mailbox).

## A checklist before an agent contacts anyone new

1. A lawful basis you can state in a sentence for the mail you intend to send.
2. Working unsubscribe on every cold send, enforced by suppression rather than by the agent.
3. Suppression on any reply that reads as a refusal, with ambiguity escalated to a person.
4. Sender identification, including a physical postal address where required.
5. A one-line disclosure that the sender is an assistant, and a fast path to a person.
6. A retention period per category, and a tested deletion path.
7. One identity and key per agent, so the audit trail can attribute anything.
8. A rate at which a mistake is discoverable before it is large.

None of that is onerous, and all of it is cheaper than the alternative. The acceptable use rules for this service, including what agents may not send, are in the [acceptable use policy](/legal/acceptable-use).

## Questions

### Do email laws apply to messages sent by an AI agent?

Yes. An agent sending on your behalf is you sending, so CAN-SPAM, GDPR, PECR, and CASL apply exactly as they otherwise would. Automation is not an exemption.

### Does every agent email need an unsubscribe link?

Cold sends do, and MCPmailer attaches one to sends classified as cold. Replies inside a thread the recipient started are a different category, though honouring any request to stop is both required and sensible.

### Does an unsubscribe have to be honoured by the agent?

It has to be honoured by your infrastructure. Suppression at the platform layer means further attempts are refused with `recipient_suppressed` rather than depending on a model remembering.

### Must an AI agent disclose that it is an AI?

Rules vary and are tightening, with the EU AI Act pointing toward disclosure for systems interacting with people. The practical answer is to disclose: it performs about as well and avoids a recipient discovering it mid-thread.

### Is an email address personal data?

Under GDPR, yes, and so are recorded facts about the person. That brings retention limits, accuracy obligations, and the right to deletion.

### What happens if an agent is tricked into sending data to the wrong person?

Treat it as a personal data breach, which under GDPR carries a 72 hour notification clock. The defences are architectural rather than prompt-level.

## Related

- [Keeping an autonomous agent from becoming a spam problem](/blog/stopping-agent-email-spam)
- [Prompt injection by email](/blog/prompt-injection-email-agents)
- [Privacy policy](/legal/privacy)
- [Data processing addendum](/legal/dpa)