Does an amazonses.com DMARC report cover mail I sent through SES?

No, and this is the common mistake. DMARC reports are always written by the receiver. Mail you send through SES appears in reports from Google, Microsoft, Yahoo and whoever else receives it — not in a report from Amazon. Reading an SES report to audit your own campaigns will tell you nothing about them.

Is a low-volume DMARC report from Amazon worth reading?

Yes. Spoofing campaigns do not distribute evenly across receivers, so a sending IP that appears in an SES report and nowhere else is still a server putting your domain in a From address. Inbound SES is also usually wired to an application rather than a human mailbox, so forged mail there is aimed at a system nobody is watching by eye.

How do I make SES mail pass DMARC?

Enable DKIM signing with your own domain using the CNAME records SES issues during domain verification. Until then your messages carry a signature belonging to Amazon, which passes DKIM and fails DMARC alignment. Also watch your SPF lookup budget: adding SES alongside a mailbox provider and a marketing platform is a common way to cross the ten-lookup limit, after which receivers stop evaluating SPF entirely.

Learn · DMARC report emails

DMARC report from amazonses.com: why you're getting it

Q: Why am I getting a DMARC report from amazonses.com?

Because Amazon's mail infrastructure received messages with your domain in the From address, and your DMARC record asks for reports. Amazon SES handles inbound mail as well as outbound — receipt rules that deliver to S3, invoke Lambda or feed an application — and any address behind it that receives mail forged in your name produces rows in a report to you.

A DMARC aggregate report naming amazonses.com as the reporting organisation catches people out, because Amazon SES is famous as a service for sending mail. The report is not about your SES sending. It is Amazon telling you what it saw arriving at addresses it receives for — and the distinction changes entirely what the report is worth to you.

Sending versus receiving

DMARC reports are always written by the receiver. The reporting organisation in a report is whoever accepted (or refused) mail claiming to be from your domain, then wrote down what happened.

So a report from amazonses.com means Amazon's mail infrastructure received messages with your domain in the From address. That happens because SES handles inbound mail as well as outbound — receipt rules that deliver to S3, invoke a Lambda function, or feed an application. Any address behind that infrastructure that receives mail forged in your name produces rows in a report to you.

If you use SES to send, your outbound mail shows up in reports from Google, Microsoft, Yahoo and everyone else who receives it — not in this one. Reading an SES report expecting to audit your own campaigns is the common mistake here, and it leads people to conclude their sending is fine when they simply haven't looked at the reports that would say.

Is it legitimate?

Verify it the same way as any other report, without needing to trust the name:

Check the live record with the free DMARC checker. A rua= address matching this mailbox means the report is expected.
Open the attachment in the free DMARC report analyzer — it parses in your browser, nothing is uploaded, and a genuine report renders as a table of sending IPs.

The filename follows the standard convention: reporting organisation, then your domain, then the reporting window's start and end as Unix timestamps. As always, a real aggregate report contains a compressed XML file and asks nothing of you.

What an SES report is actually good for

Volume from Amazon is usually low compared with the big mailbox providers, which makes it easy to dismiss. Two reasons not to.

It is a different vantage point. Spoofing campaigns don't distribute evenly across receivers. A sending IP appearing in an SES report and nowhere else is still a server putting your domain in a From address, and low volume from an unfamiliar source is not the same as unimportant.

It catches application mail. Inbound SES is typically wired to an application rather than a human mailbox — support pipelines, reply parsing, automated intake. Mail forged as your domain into those addresses is aimed at a system, not a person, and nobody is going to notice it by eye.

The rows read like any other report: source IP, message count, aligned SPF and DKIM results, and the disposition applied. DMARC aggregate reports explained covers the format, and source IPs in DMARC reports covers judging an address you don't recognise.

If you do send through SES

Then the useful question isn't in this report at all — it's whether your SES-sent mail aligns to your domain everywhere else. Two things to confirm:

DKIM signing with your domain. SES can sign with your domain via the CNAME records it issues during domain verification. Until that's in place, your messages carry a signature belonging to Amazon rather than to you, which passes DKIM and fails DMARC alignment — the classic ESP alignment problem. The free DKIM checker shows what's actually published.
Your SPF lookup budget. Adding SES alongside a mailbox provider and a marketing platform is how domains cross the ten-lookup limit, at which point receivers stop evaluating SPF entirely. The free SPF record checker counts them.

Get both right and SES mail has two independent paths to a DMARC pass, which is what you want before moving to an enforcing policy.

Making the reports work for you

Reports from a dozen receivers, each in its own compressed XML file, is not a thing anyone reads for long. Don't fix it by deleting the DMARC record — that ends the reports and your visibility together. Repoint rua= at a monitor that parses every report, names the service behind each IP, and tells you when something changes. Canny Pigeons does that free for one domain, hosted DMARC included.

Free checks: Report analyzer DMARC checker SPF checker DKIM checker

Reports from other submitters too? Why am I getting DMARC report emails? covers the whole set.