Understanding DMARC Reports
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a policy that protects organizations from Business Email Compromise attacks and allows to receive DMARC reports from mail service providers. DMARC is an email authentication protocol, that is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. It is a policy that lets the domain owner publicize to its email receivers what they need to do with the unauthenticated emails coming from his/her domain. You can dive deeper for DMARC in RFC7489.
So, let’s find out why you need DMARC reports with specific examples and explanations.
Why do you need a DMARC policy?
DMARC policy appeared in 2012 as a tool against phishing. It was supported by mail providers AOL, Comcast, Gmail, Hotmail, Netease, Yahoo! Mail and mail senders American Greetings, Bank of America, Facebook, Fidelity, JPMorgan Chase & Co., LinkedIn, PayPal.
Thus, the DMARC policy protects domain owners from the negative consequences of fraud. So, you need a DMARC policy to protect your business from money, data, and customer loss.
How does DMARC work?
DMARC works on top of 2 email authentication protocols, DKIM and SPF. A domain owner can authorize the sources which he/she uses with the help of DKIM and SPF, and start sending only authenticated emails.
With the use of DMARC, the domain owner can publish a policy that will dictate receivers how to process emails from that domain. For example, you can publish a policy to reject all non-authenticated emails from your domain. After that, no one can send a fraudulent email from your domain after publishing the “reject” policy.
One of the key values of DMARC is “Domain Alignment” – It checks if the domain of the email address in the “From:” line matches the identifiers of the SPF verification and DKIM signature. If the match is complete, the letter is delivered to the recipient’s mailbox, if not, it is processed according to the selected DMARC policy:
- “None” – No action against the unqualified email, the letter goes to the recipient’s mailbox. The domain owner receives a report with information about sending a message, by analyzing it the owner will see who sends letters on his behalf and whether they are allowed to do so.
- “Quarantine” – the recipient’s email server delivers the unqualified email to the Spam folder of the recipient, domain owners can continue analyzing the data received in reports.
- “Reject” – letters that don’t pass the DMARC check are rejected and do not fall into any folder of the recipient’s mailbox.
When setting this type of policy, make sure that third parties who are allowed to send messages on your behalf are properly authenticated, otherwise, their letters will also be rejected. This also applies to CRM systems and email newsletter services.
Why do you need DMARC reports?
SPF and DKIM mechanisms don’t guarantee 100% protection against scams. Even if everything is spelled out correctly, it is possible that the original redirected emails will be well processed or the sender’s identification will go without a hitch. Also, frequently, the report of delivery failures to the sender does not arrive. In general, the technology is not perfect.
In order to enhance the defensive capabilities of SPF and DKIM, DMARC was implemented. It sets the standard for checking incoming mail by ensuring that it passed “face control” by SPF or DKIM.
DMARC reports on the current status of your email authentication program by sending DMARC reports to the specified mailboxes.
It allows you to detect and prevent sending fraudulent emails that claim to be from your domain when they aren’t. DMARC reports are valuable sources of information that you can now easily collect using EasyDMARC.
When you publish a DMARC record, a lot of ISP’s (i.e. Google, Comcast, Yahoo, etc.) will send you DMARC reports. These reports will contain compressed flat XML text and contain a lot of valuable data. EasyDMARC parses those reports and renders the data into human-readable and easy-to-understand charts.
When you publish a DMARC record in the DNS, not only can you specify the policy which instructs email servers how to dispose of unauthenticated emails, but also you can request mailbox providers to send you DMARC reports directly.
These reports contain information about your outgoing email infrastructure. You should constantly monitor such information to properly authenticate all your legitimate email sources.
DMARC report examples and explanations
DMARC maintains 2 types of reports: aggregate reports and failure (forensic) reports. These 2 reports serve different purposes.
Aggregate reports contain info about groups of email messages, including:
- Sending source IP
- Sent date
- The domain or organization that sent the report
- SPF domain
- SPF domain alignment check: pass or fail
- SPF authentication result: none, neutral, pass, fail, softfail, temperror, or permerror
- DKIM domain
- DKIM domain alignment check: pass or fail
- DKIM authentication result: none, neutral, pass, fail, policy, temperror, permerror
- The disposition of those emails (Applied policy by the receiver): None, Quarantine or Reject
E.g of DMARC Aggregate Report parsed data:
Failure (forensic) reports contain all the information about individual email messages, including:
- Sending source IP
- From: email address
- To: or recipient email address
- Email subject line
- Authentication results: SPF and DKIM
- Received time
- Email headers; including: sending host, email message ID, DKIM Signature, and other custom header information
E.g of DMARC Failure Report parsed data:
Failure reports contain Personally Identifiable Information (PII). Due to privacy concerns, many mailbox providers including Gmail have dropped support for DMARC failure reports. Only a few mailbox providers still send failure reports, including LinkedIn.
Request to send aggregate reports
In order to receive DMARC aggregate reports to your specified email address, you should specify an email address in the rua tag of your DMARC record.
For example, if you want to request aggregate reports sent to your EasyDMARC dashboard, you should publish a DMARC Record like this:
v=DMARC1; p=none; rua=mailto:[email protected];
Request to send failure reports
In order to receive DMARC failure reports, you can request to send failure reports to an arbitrary email address accessible to you.
For example, if you want to request failure reports sent to your EasyDMARC dashboard, you can publish a DMARC Record including “ruf” tag, like this
DMARC is a great tool to monitor your outgoing email infrastructure and understand how providers receive and process your emails. Based on this, you can improve delivery and regain 5% or more of your base, which may not receive letters for technical reasons.