DMARC reports
DMARC is the DNS record that tells mail servers how to treat the messages that use your domain as sender without being authorized. Every day the large mail receivers (Google, Microsoft, Yahoo and the others) send to the address written in the DMARC record an aggregate report: from which servers the mail in the name of your domain came, how much of it passed SPF and DKIM, what they did with it.
These reports are XML files that are hard to read. DRP (DMARC Report) collects them and shows them in a readable way, so you can see:
- whether all your legitimate mail passes DMARC, before making the policy stricter (from
p=nonetop=quarantineorp=reject); - who sends mail in your name: a forgotten newsletter service, a business application, or someone pretending to be you.
DRP reads the aggregate reports (rua). The reports of single failed messages (ruf) are not included.
The domains
The DMARC tile of the subscription opens DMARC domains: the domains whose reports the subscription follows, with the number of Reports and the Last report. The plan sets how many domains you can follow.
Add domain asks for the Domain, as in the DMARC record, for example example.com, and an optional Note.
- The subdomains without a DMARC record of their own are in the reports of the domain. A subdomain with a record of its own receives reports of its own: add it as a domain to follow it separately.
- A domain can be followed by only one subscription of the panel.
- Remove stops following a domain: its summaries go with it, its reports stay until they expire.
How the reports arrive
The How the reports arrive box says how the panel receives the reports of the subscription. There are two ways.
A mailbox
The panel reads a mailbox where the reports arrive: the address written in the rua of your DMARC record, for example rua=mailto:dmarc@example.com. Every 15 minutes it takes the messages that look like reports and reads them.
In DMARC mailboxes, Add mailbox asks for:
| Field | What to write |
|---|---|
| Address | The address of the mailbox, as in the rua. Optional |
| Protocol | IMAP or POP3 |
| Server, Port, Security | The mail server; always TLS or STARTTLS |
| User and Password | The access to the mailbox. The password is kept encrypted and never shown again |
| Folder read | For IMAP, the folder where the reports arrive |
| Folder of the processed | For IMAP, where the panel moves the reports taken |
Good to know:
- Only the reports: the panel looks at the subject of the messages ("Report Domain: …") and downloads only those; the others are neither read nor marked as read. A mailbox used only for the reports is better.
- With IMAP the reports taken move to the folder of the processed: what stays in the folder read is mail that is not a report. On servers that keep all the folders under INBOX the panel finds them and creates them by itself.
- With POP3 the reports taken are deleted from the mailbox 7 days later.
- Microsoft 365 does not accept IMAP and POP3 with the password: for now its mailboxes cannot be used.
- One mailbox serves every domain whose record names it: the panel reads the domain in each report.
Test the mailbox signs in and says how many messages there are, without taking anything. Read now reads at once. Turn off and Turn on stop and resume the reading. The State says Read, Not read yet, or Not read since … when something is wrong: the reason is written next to it.
Uploading reports by hand
On the page of a domain, Upload reports accepts XML files, compressed .gz or .zip, or messages saved as .eml. It is for bringing into the panel the history of a domain whose reports went to another mailbox or service: download them from there, then upload them here.
For each file the page says how it went: Report written, Already received (a report is never written twice), Not read.
Reading the reports
The page of a domain shows the Last 30 days, with the messages the receivers counted and how many passed DMARC, and the list of Reports received: Period, Receiver, Messages, DMARC pass, Policy and how it Arrived.
A report shows:
- the Policy seen by the receiver: your DMARC record as the receiver read it;
- the Rows: for each source address (Source), the Messages, whether DKIM and SPF passed aligned with the domain of the sender, and what the receiver Applied (delivered, quarantine, rejected). DMARC passes when at least one of DKIM and SPF passes aligned;
- Signatures and SPF seen: the DKIM signatures and the SPF check as they were, even when not aligned.
Download XML saves the original report.
What to look at
- A Source you do not recognize, with many messages that do not pass DMARC, is often someone pretending to be you: with a
p=rejectpolicy those messages are rejected. - A source of yours (your mail server, the newsletter service, the business application that sends the invoices) that does not pass DMARC must be fixed, by adding it to the SPF record or setting up DKIM, before making the policy stricter: otherwise your own mail would be rejected.