DMARC monitoring when you send through Amazon SES.

The raw material

What an aggregate report is, and why the XML is not the answer

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a record you publish in DNS. It tells receiving mail providers what to do with mail claiming to come from your domain that fails authentication, and it names an address where those providers should send reports about what they saw. That address lives in the rua tag, and the reports it collects are called aggregate reports.

An aggregate report is a gzipped XML file, usually one per reporting organisation per day. Inside it, each record describes a sending IP address, how many messages that address sent, the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) results, whether either of those results aligned with the domain in the visible From address, and the disposition the receiver applied. That last field is what actually happened to the mail.

Notice what is not in there. There are no recipient addresses, no subject lines, and no message content. Aggregate reports are counting data, which is exactly why they are safe to collect at scale.

The problem with reading them yourself is not the format. It is that the format answers the wrong question. A file of IP addresses tells you that 3,412 messages from 34 addresses failed DKIM yesterday. It does not tell you that 31 of those addresses are one European marketing platform your events team signed up for, that two are a university mail relay forwarding your newsletter, and that the last one is your own SES traffic from a region where somebody forgot to publish the DKIM records.

Turning the first sentence into the second is the entire job. It means grouping addresses by provider fingerprint and network so rotating IPs stay one row, joining SPF and DKIM results into an alignment story, separating forwarding from unauthorised sending, and doing it again every day as the sources change.

Scope

SES tells you about SES. DMARC tells you about your domain.

Amazon SES gives you excellent data about the mail you sent through Amazon SES. Sends, deliveries, bounces, complaints, opens, clicks — all of it accurate, all of it scoped to your own sending path. That scope is the limitation. SES has no opinion about a message it never handled.

Your domain is almost certainly used by more than SES. A typical company discovers, on reading its first month of reports, that its From domain is in use by Google Workspace or Microsoft 365 for everyday staff mail, by a help-desk product, by a billing or invoicing system, by a scheduling or webinar tool somebody in marketing bought, by mailing lists and personal forwarding rules, and sometimes by a service a departed employee configured years ago.

Every one of those senders affects your DMARC result, because DMARC evaluates the domain in the visible From address rather than the platform behind it. You cannot publish an enforcement policy safely while any of them is unaccounted for, and no SES-side metric will ever show them to you.

Evidence

An SES IP address proves nothing. A DKIM selector proves everything.

The instinct when reviewing reports on SES is to check whether the sending IP belongs to Amazon SES, and to treat a match as proof the mail was yours. It is not proof. SES shared IP ranges are shared across the whole service, so a match tells you the message came from SES — not from your SES account.

That distinction matters more than it sounds. Anyone can open an AWS account, verify a domain they control, and send mail from the same address ranges you use. If they put your domain in the From address, their message appears in your reports, from an IP that looks exactly as legitimate as your own. Network ownership cannot separate the two.

Cryptography can. When SES signs a message with Easy DKIM, it uses a key pair whose public half is published under selectors in your DNS. A signature that validates against one of your selectors could only have been produced by a key your domain controls. That is a positive identity claim about the message rather than a guess about the network it travelled over.

There is a second reason selector evidence matters. Without it, your own SES mail that is failing alignment gets filed alongside genuinely unknown senders, and a configuration mistake starts to look like an attack. With it, that traffic is correctly labelled as yours and broken — which is a fix, not an investigation.

Keep the same discipline in the other direction. An unknown source is a source that still needs a decision. Most of them turn out to be a forgotten SaaS product, a shared sending pool, or ordinary forwarding, and treating the first month's unknowns as adversaries wastes the month.

Diagnosis

The seven failures SES senders actually hit

“DMARC failed” is not a diagnosis. These are the specific causes behind most failing traffic on an SES domain, and what each one asks you to do about it. Note that the last two have no DNS fix at all, which is an honest answer rather than a gap.

Two habits make this list much faster to work through. Check live DNS rather than trusting the report, because a report describes yesterday and a record may have been fixed since. And fix DKIM before SPF: an aligned DKIM signature satisfies DMARC on its own and survives forwarding, so it removes whole categories of failure that no SPF change can. The SES setup guide walks through publishing both, and the SES deliverability guide covers how authentication sits alongside reputation.

Enforcement

From p=none to p=reject, one justified step at a time

The policy ladder has three rungs. p=none asks for reports and changes nothing about delivery. p=quarantine asks receiving providers to treat failing mail as suspicious, usually by filing it as spam. p=reject asks them to refuse failing mail outright during the SMTP conversation.

Nothing in your own infrastructure enforces any of this. The receiving provider acts, because you asked it to in DNS. That also means the blast radius of a premature move lands on your legitimate mail, not on the attacker, which is why every rung should be earned.

Here is the evidence worth having before you tighten:

Two details that are easy to miss. Subdomains inherit your policy unless you set the sp tag, so decide deliberately whether the subdomain that sends your invoices is ready for the same treatment as the parent. And if your published record is ever weaker than the policy receivers were recently reporting, something changed it — a DNS migration, a registrar template, a well-meaning colleague — and that regression is worth catching quickly.

Whatever tool you use, you publish the record. A DMARC product can generate the exact value, show a field-level difference against what is live, and measure what the change would cost. Making the change in your DNS provider stays with you.

A separate signal

TLS reporting answers a different question

SMTP TLS Reporting (TLS-RPT) is a second reporting standard, and it is easy to conflate with DMARC because both arrive as scheduled reports from receiving providers. They measure different things. DMARC reports whether a message was authenticated as coming from your domain. TLS-RPT reports whether sending systems could establish a secure connection to the mail servers your domain publishes.

Keep the two apart in your head and in your alerting. A domain can pass DMARC on every message and still have a certificate or policy problem that TLS reports would have shown. A TLS failure does not mean a message failed DMARC, and it should not be counted against your authentication trend.

For SES senders, TLS-RPT is mostly about the inbound side of your domain, so it is worth watching even though it says nothing about your outbound campaigns.

The Shortcut

Or: run this workflow inside your SES control plane

Everything above can be done by hand, and plenty of teams do it. The reason we built DMARC monitoring into SendOps is that the SES half of the work is the half a general-purpose DMARC tool cannot see. SendOps already knows your verified identities and DKIM selectors, so it can prove which traffic is yours.

Three boundaries are deliberate and will not change. SendOps never publishes DNS, never advances your policy, and never blocks a sender — rejecting a source records a decision, and it is a stricter DMARC policy that asks receiving providers to act. SendOps accepts aggregate reports only and refuses forensic reports, because those can carry recipient addresses, subject lines, and sometimes message content to an address published in public DNS, and the major mailbox providers generally do not send them anyway.

If you are still choosing a tool, the category roundup profiles the alternatives, including the cases where one of them fits better than we do.