Why am I not Receiving DMARC Aggregate/Failure (Forensic) Reports?

There can be many reasons why you are not receiving DMARC reports. Here are some of the most common reasons: DMARC is not configured for your domain and/or is not published in your DNS. External domain verification (EDV) is not configured. No emails have been sent since your published the DMARC record. Your email service provider does not send DMARC forensic reports (Not all do). Forensic reporting is not enabled for your domain.

When are DMARC forensic reports generated?

DMARC forensic reports are generated by an ISP when the SPF or DKIM does not align with DMARC.

What is RUF or DMARC Forensic Report?

Q: Do forensic reports contain any personally identifiable information?

Forensic reports may contain some PII, such as data about the spoofed email such as the sending email address, receiving email address, subject, and, sometimes, the header of the email. Read more.

Everything you need to know about RUF and DMARC Forensic Reports

What is RUF?

RUF data was created with the intention of providing domain owners with redacted copies of emails that failed to pass the DMARC compliance test.When seeking to establish the true origin of lawful email streams that require repair, domain owners can use the additional facts supplied in the forensic reports. Most DMARC reporters do not conduct RUF reporting due to privacy concerns regarding incomplete or poor redaction. The goal is to avoid data breaches and to follow all applicable rules and regulations regarding sensitive and personal information. RUF is a more comprehensive report because it includes more information about emails, such as the subject, header, attachments, and URLs.

RUF reports may contain the following information:

IP information
Subject line
The time when the message was received
Message-ID
URLs
Delivery result
SPF, DKIM, and DMARC results
ISP information
‘From’ domain information
‘To’ domain information

DMARC Forensic Reports Overview

Unlike aggregate reports, forensic reports are sent out if an email from your domain fails both the SPF and DKIM authentication protocols. These reports contain data about the spoofed email such as the sending email address, receiving email address, subject, and, sometimes, the header of the email. Due to this, they are utilized for in-depth investigation of emails impersonating an organization’s domain.

To decrease noise and only receive forensic reports of spoofed emails, activate these reports after analyzing the aggregate reports and allowing all the valid sources. When the SPF or DKIM does not match DMARC, an ISP generates DMARC forensic reports. Sample data in forensic reports indicates that there is a problem with a specific source or transmitting IP. Message-level data, “To” and “From” email addresses, and the sender’s IP addresses are all included in the forensic reports.

It is also possible to view a message’s body, which may include sensitive information. Therefore, not all ISPs send these forensic reports. However, receiving these forensic findings could aid in the DMARC deployment process. The receiver for the failure reports is specified by the “ruf” tag in your DMARC record.

For example, ruf=mailto:xxxxxxxx@emailauth.io

You can also use the “fo” tag in your DMARC record to identify the types of failures for which you want forensics. When both SPF and DKIM fail, failure reports are sent by default. These reports:

Are real-time reports
Are only sent for DMARC failed emails
May contain the Subject and Body content of the email
Include original message headers

Receiving DMARC Forensic Reports

To receive an aggregate report, firstly create a DMARC record. A DMARC record invites DMARC reporting organizations to send DMARC aggregate reports back to the sender of an email. The record contains a RUF tag like the one in the following example:

tag: ruf=mailto:demo@emailauth.io

This is the email address to which the DMARC reporting organization will send the DMARC forensic report. Similar to requesting for aggregate reports, requests can be made to send failure reports to a temporary email address. For example, to request for failure reports be sent to failure_reports@emailauth.io, you can add a RUF tag with that email to your DMARC record in the following manner:

v=DMARC1; p=none; rua=mailto:aggregate_reports@emailauth.io;

ruf=mailto:failure_reports@emailauth.io;

RUF vs. RUA

RUF	RUA
Provides details of an individual email	Provides aggregate data on a group of emails
To receive failure reports, set up the ‘ruf’ tag	To receive aggregate reports, set up the ‘rua’ tag
Sent almost immediately after the authentication failure	Sent every day by default
Contains personally identifiable information	Does not contain personally identifiable information
Not supported in all mailbox providers	Supported in all DMARC-compliant mailbox providers

How Does DMARC Help?

GLOBAL STATISTICS JUSTIFYING THE NEED FOR EMAIL AUTHENTICATION

Phishing attacks have risen by 350% post the COVID-19 Pandemic!

$600 million every year is scammed by Phishing attacks!

Globally 1 in 3 companies have been victims of CEO Fraud Email Scams!

DMARC has been adopted by the biggest email senders and email receivers globally. This includes Yahoo!, Google, and Microsoft, covering 85% of the consumer inboxes in the world.

The most important reason why DMARC should be used is that it gives an organisation full control on how their domain is being used. The organisation can also instruct the receivers on what actions should be taken if the incoming email is not legitimate and report the incident back to the organisation for further analysis.

It saves consumers from the trouble of identifying whether an email is legitimate or a spam. Sometimes it may happen that regardless of all the knowledge of email spoofing a receiver might fall into the trap. DMARC makes sure that this does not happen.