Which reports will I get, and from whom?

On every plan

You can get three kinds of report, all at your reporting address. Aggregate reports come from the mailbox providers that receive your mail, and the product's sources and readiness are built on them. Forensic reports are rare, and come only if you ask for them. TLS reports come from servers that send mail to you, once you publish a TLS-RPT record.

Aggregate reports

An aggregate report covers one period, usually a day, of the mail one mailbox provider received from your domain. It holds no message content. Each row is a sending address with a count of messages, the From domain, and the SPF, DKIM and DMARC results. Sources, explanations, readiness and the charts are all built from these rows.

The DMARC record the product builds asks for one report a day, and a domain gets about one a day from each mailbox provider that reports. They arrive as XML, in the format of RFC 7489 or the newer RFC 9990, and the domain's Reports page lists them. You can download the file of each one.

Forensic reports

A forensic report is a copy of one message that failed DMARC, sent by the mailbox provider that received it (RFC 6591). Few mailbox providers send them. Google and Microsoft do not. You get them only when your DMARC record asks for them with ruf=.

They can contain message content and personal data, so an admin chooses how we store them, under Settings, Organization:

with personal data removed, the default. We keep the report with personal data removed, and delete the original message as soon as the report is read. No unredacted copy remains;
in full. We keep the report and the original message, and you can download the message from the report's page;
not at all. We keep neither the report nor the message.

The domain's Forensic page lists them.

TLS reports

A TLS report is about mail coming in to your domain. Servers that delivered mail to your MX hosts report how many connections they could encrypt, and why any failed (RFC 8460). You get them once you publish a TLS-RPT record at _smtp._tls.example.com with your reporting address in it. They arrive as JSON. The domain's TLS-RPT page shows them.

Each failure carries a result type. This is what each one means, and what to check where a fix is known:

What the report says	How to fix it
The receiving server did not offer STARTTLS, so the connection could not be encrypted.	Check that every MX host in the policy offers STARTTLS.
The certificate did not name the MX host the sending MTA connected to.	–
The receiving server's certificate had expired.	Renew the certificate on the MX host.
The certificate was not issued by an authority the sending MTA trusts.	–
The certificate could not be validated for another reason.	–
The receiving server's certificate did not match its published TLSA record.	–
DNSSEC validation failed while looking up the receiving server's TLSA record.	–
DANE was required, but the receiving server published no signed TLSA record.	–
The sending MTA could not fetch your MTA-STS policy over HTTPS.	Check that your MTA-STS policy file is reachable over HTTPS.
Your MTA-STS policy did not parse.	–
The certificate on your MTA-STS policy host was not valid.	–

Files we accept

A report arrives as an attachment to an email. We read:

XML files for aggregate reports and JSON files for TLS reports, as .xml or .json, gzipped as .xml.gz or .json.gz, or inside a .zip;
forensic reports as the report message itself.

A .zip may hold report files only. An archive inside an archive, or a file in a folder inside the zip, makes us refuse the message.

Limits on one message

Report mail comes from outside, so each message is checked against fixed limits before we read it:

25 MiB for the whole message;
5 report files;
32 MiB for each file once unpacked, and 64 MiB for all of them together;
100,000 rows in one aggregate report.

A message or report over a limit is not stored as a report. A real report for one domain is far below every limit.

Published 27 October 2026 · Checked 27 October 2026