DMARC reports

Big mail providers such as Google, Microsoft and Yahoo send a daily "aggregate report" to every domain with a DMARC record that asks for one. A report lists which servers sent mail using your domain, how many messages, and whether they passed SPF and DKIM. Mailocity collects these reports for you, so you can see who sends as your domain before you tighten your DMARC policy, and spot anyone forging it.

How it works

Report collection is on for every domain by default (dmarcCollect).

The DMARC record in your DNS checklist asks for reports at dmarc-reports@<your-domain>, ahead of any addresses you list in dmarcReports. Update the _dmarc record in your DNS if you added the domain before this feature existed.
Reports sent to that address are read when they arrive, whether gzip, zip or plain XML, and stored against your domain for 180 days. They are not delivered to a mailbox.
A report is only stored if it is about your domain or one of its subdomains. A report about any other domain is refused, so nobody can push reports into another customer's domain.
Each report records whether its own email passed DMARC (senderVerified). Reports from big providers always do; treat an unverified report with suspicion, since anyone can send one.

If you would rather read the raw report emails yourself, create a mailbox or alias called dmarc-reports on the domain: it then gets the mail like any other address, and nothing is stored. To stop collecting, set dmarcCollect to false and update your DNS record.

Reading them in the panels

Open the domain's page (in the domain admin panel, or the Mailocity admin panel under Teams or Shared domains) and scroll to DMARC reports:

Who sends as the domain: every server that sent mail claiming the domain in the period you choose (7, 30 or 90 days), how many messages, how many passed DMARC, and how many receivers quarantined or rejected. A source marked failing is either a service you use that is missing from SPF and DKIM (add it), or someone forging the domain (the DMARC policy is what stops them).
Reports: each report, newest first, with who sent it and the policy it found. Verified means the report email itself passed DMARC; an unverified one may be forged. Choose a report to see its rows: each source, its DKIM and SPF results and what the receiver did.

Reading reports

From the API (screens in the admin panels arrive in M2):

Request	What you get
`GET /v1/tenants/{id}/domains/{domain}/dmarc-summary?days=30`	Every sending address seen in the period, busiest first, with how many messages passed, were quarantined or were rejected, and which providers reported it.
`GET /v1/tenants/{id}/domains/{domain}/dmarc-reports`	The reports, newest first, 50 per page (`limit` up to 200; pass `next` as `before` for the next page).
`GET /v1/tenants/{id}/domains/{domain}/dmarc-reports/{reportId}`	One report with every row: source address, message count, what the receiver did, and the raw DKIM and SPF results.

Shared domains have the same three endpoints under /v1/shared-domains/{domain}.

What to look for

Your mail server: the Mailocity mail host's addresses should show nearly all messages passing.
A service you use (newsletters, CRM, invoicing) failing: add it to spfExtra and set up DKIM with it, as described in SPF, DKIM and DMARC.
Addresses you do not recognise failing: probably forgery. Once every real sender passes, move your DMARC policy to quarantine and then reject.

Limits

1000 reports per domain per day; more are refused with a temporary error.
Reports up to 16 MiB once decompressed, with at most 10000 rows each.
The same report (same provider and report id) is stored once.

Not yet

Failure reports (ruf) are not collected; they are rare and can contain personal data. Addresses you list in dmarcFailureReports still get them.
An optional email digest of each domain's reports to its admins.