Email authentication protocol DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an essential tool for email security. It allows senders to protect their domains from unauthorized use, while providing receivers with information about the authenticity of messages they receive. You can find more information about how DMARC works here: Demystifying DMARC. In this blog post, we will take a closer look at the optional parameters in DMARC record – rua and ruf – and explain how to set up DMARC reporting.

Two optional parameters for reporting in the DMARC specification

rua (Reporting URI of Aggregate Reports) provides an email address where aggregate reporting data about messages that fail DMARC authentication can be forwarded. Aggregate reports contain summary information about messages that fail DMARC authentication, including the sending domain, the number of messages received, and the number of messages that failed DMARC authentication.

ruf (Reporting URI of Forensic Reports) provides an email address where forensic reporting data about messages that fail DMARC authentication can be forwarded. Forensic reports contain detailed information about messages that fail DMARC authentication, including the full message headers, message body, and any attachments.

While it is possible to add the ruf tag to a DMARC record, it is generally not recommended for several reasons:

1. 1. High volume of reports: In the event of a DMARC failure, receiving mail servers will generate detailed reports for each failed message and send them to the address specified in the ruf. This can result in a very high volume of reports, making it difficult to manage and analyse the information.

1. 1. Privacy concerns: The reports generated for failed messages contain detailed information about the messages and recipients, which can raise privacy concerns if this information is not properly secured. For more information, check Report on the compliance of DMARC with EU GDPR by eco competence group e-mail.

1. 1. Lack of standardization: There is no standard format for failure reports, making it difficult for domain owners to process and analyse the information in a consistent and meaningful way.

For these reasons, it is generally recommended to use aggregate reports generated by the rua tag instead of failure reports generated by the ruf tag. Aggregate reports provide valuable information about the use of a domain for email while avoiding the privacy concerns and high volume of reports associated with failure reports.

The format of DMARC aggregate reports (rua) is standardized and follows the XML format. The information the reports contain can be difficult to understand without proper interpretation. Fortunately, there are several options available to help you make sense of your DMARC reports and take advantage of the insights they provide: using free online tools, having your IT team write a parser, or working with a third-party company specializing in DMARC support. These options can help you understand the data in the reports and make the most of the insights they provide to maintain the integrity and reputation of your email domain.

Setting up DMARC reporting

First, the sending domain must publish a DMARC record in its DNS. For example, the DMARC record for the sending domain “email.example.com” might look like this:

v=DMARC1; p=reject; adkim=s; aspf=r; rf=afrf; pct=100; rua=mailto:dmarc@example.com

The part of the DMARC record “rua=mailto:dmarc@example.com“ indicates that DMARC aggregate reports should be sent to the mailbox dmarc@example.com.

DMARC reports can also be sent to an address within a third-party or another domain, which can be useful when delegating monitoring reports to a trusted organization, or if you manage multiple domains and prefer to receive all reports at a centralized address.

In some cases, the owner of the reporting domain must add a special DNS record to their domain. Here are example situations where it is needed or not needed:

Case 1. The domain with the DMARC policy is the same as the reporting domain, no additional steps are necessary.

Domain:

email.example.com

DMARC record:

v=DMARC1; p=reject; adkim=s; aspf=r; rf=afrf; pct=100; rua=mailto:dmarc@email.example.com

Case 2. The domain with the DMARC policy is a subdomain of the reporting domain, no further action is required.

Domain:

email.example.com

DMARC record:

v=DMARC1; p=reject; adkim=s; aspf=r; rf=afrf; pct=100; rua=mailto:dmarc@example.com

Case 3. An address in a third-party domain is used for reporting, and an authorization from the owner of the other domain is required. To do this, they will need to add a special DNS record to authorize the sending domain to use their domain for DMARC reports.

Domain:

email.example.com

DMARC record:

v=DMARC1; p=reject; adkim=s; aspf=r; rf=afrf; pct=100; rua=mailto:dmarc@otherdomain.com

The owner of “otherdomain.com” from this example will need to add the following record:

email.example.com._report._dmarc.otherdomain.com. TXT "v=DMARC1"

This TXT record will ensure that DMARC report generators can send reports to the indicated mailbox. Without it, reports will not be sent to the mailbox specified in your DMARC record. For more information about DMARC reporting outside your domain, visit the DMARC website.

Be mindful

When setting up DMARC for your domain, it is essential to be mindful of the impact that the parameters you add can have on the infrastructure of DMARC report generators. For this reason, it is crucial to add the reporting parameters only if you have a plan in place to process and analyze the resulting reports.

It is also important to ensure that the email addresses you define in the rua and ruf tags are accurate and exist. This is especially critical if you are using a third-party reporting domain, as that domain must authorize the reports for your domain. Failure to do so will result in an unnecessary burden on the infrastructure of the DMARC report generators.

In conclusion, DMARC is a crucial tool for safeguarding the authenticity and reputation of your email communication. However, it is essential to approach DMARC implementation with caution and attention to detail.

By being mindful of your DMARC setup and taking the time to set everything up correctly, you can maximize the benefits of DMARC and ensure that your email communication is secure, trustworthy, and effective.

Happy reporting!

What’s next?

Please leave feedback below and/or hit the “like” button to show this type of content is useful.

You can ask questions and provide suggestions for helpful email deliverability topics in the Q&A area Q&A – SAP Emarsys Email Deliverability.

And if you’d like to find out more SAP Emarsys, you can visit the community page: SAP Emarsys CX.