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. Some receivers also send a "failure report" (ruf) about each single message that failed. Mailocity collects both kinds 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 indmarcReports. Update the_dmarcrecord 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.
Failure reports
Failure report collection is on for every domain by default too (dmarcCollectFailures, the Collect DMARC failure reports box in the domain's Mail settings).
- The DMARC record adds
ruf=mailto:dmarc-reports@<your-domain>; fo=1, ahead of any addresses you list indmarcFailureReports.fo=1asks for a report when either SPF or DKIM fails, not only when both do. - Each report (RFC 6591) says what failed (
dmarc,spf,dkim...), where the message came from, who it claimed to be from, its subject, and what the receiver did with it. Mailocity keeps the failed message's headers (up to 32 KiB), never its body, for 90 days, at most 1000 per domain a day. - As with aggregate reports, a failure report is only stored if it is about your domain or a subdomain, and each records whether its own email passed DMARC.
- Most large providers (Google, Microsoft) do not send failure reports, and those that do often leave out personal details, so expect few. A real one is useful: it shows the exact message someone forged, or the service of yours that is not signing.
Each kind can be turned off on its own. With dmarcCollect off and dmarcCollectFailures on, the record asks for failure reports only, and aggregate reports sent to the address are refused.
Domains whose DNS Mailocity publishes
If the domain uses automatic DNS (Route 53 or dnso.city), there is nothing to do: the updated _dmarc record is published at the next hourly sync, or at once with Publish now. Otherwise copy the _dmarc record from the DNS checklist into your DNS.
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.
- Failure reports: each failure report, newest first, with what failed, the source, the From and the subject. Choose one to see every detail the receiver gave and the failed message's headers.
Reading reports
From the API:
| 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. |
| GET /v1/tenants/{id}/domains/{domain}/dmarc-failures | The failure reports, newest first, without headers, paged the same way. | | GET /v1/tenants/{id}/domains/{domain}/dmarc-failures/{reportId} | One failure report with the failed message's headers. |
Shared domains have the same 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
spfExtraand 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
quarantineand thenreject.
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.
- 1000 failure reports per domain per day, kept 90 days, headers only.
Not yet
- An optional email digest of each domain's reports to its admins.