Decoding the DMARC RUA Report: A Practitioner's Guide to Identifying Authentication Issues

28 October 2026 · DMARC Engine · 11 min read

Understanding the DMARC RUA Report

The DMARC RUA report is a crucial tool for identifying authentication issues, and understanding its contents is essential for effective DMARC management, as evidenced by the search for "dmarc rua report" that often precedes a deep dive into the report's specifics. When analysing a DMARC RUA report, it is clear that the report provides valuable insights into the authentication results of emails sent from a particular domain, and a typical DMARC RUA report will contain information about the source IP addresses, authentication methods, and results, which can be used to identify potential issues with SPF or DKIM authentication.

A common pattern is that receivers typically send DMARC RUA reports to the email address specified in the DMARC record, which may be hosted on a managed setup, such as a third-party DMARC service provider. For example, a DMARC record may look like this:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"

This record specifies that the DMARC RUA reports should be sent to the email address dmarc@example.com, which can be hosted on a managed setup, allowing for easier management and analysis of the reports.

The aggregate reports will show the total number of messages that passed or failed authentication, as well as the source IP addresses and authentication methods used. By analysing these reports, it is possible to identify potential issues with SPF or DKIM authentication, such as misconfigured records or unauthorised senders. For instance, if the report shows a high number of authentication failures from a particular IP address, it may indicate that the IP address is not included in the SPF record, or that the DKIM signature is not correctly configured.

import xml.etree.ElementTree as ET

# Parse the DMARC RUA report XML
root = ET.parse('dmarc_report.xml').getroot()

# Extract the authentication results
auth_results = root.findall('.//auth_result')

# Print the authentication results
for result in auth_results:
 print(result.attrib)

This code snippet demonstrates how to parse a DMARC RUA report XML file and extract the authentication results, which can be useful for automated analysis and reporting.

Tip: When analysing DMARC RUA reports, it is essential to consider the potential impact of changes to the DMARC policy, such as switching from p=none to p=quarantine or p=reject, as this can affect the delivery of legitimate emails.

Common Authentication Issues in RUA Reports

A common pattern is for receivers to report authentication issues in DMARC RUA reports, which can be challenging to decipher. The aggregate reports will show authentication failures, such as SPF and DKIM errors, that can be caused by various factors, including misconfigured DNS records or mismatched sender domains. For instance, a domain may have a DMARC record published with a policy of p=none, but the SPF record may be missing or incorrectly configured, leading to authentication failures.

The RUA reports will typically include details about the authentication results, such as the SPF and DKIM alignment, and the IP addresses of the sending mail servers. A hosted or managed setup may handle these issues differently, depending on the specific configuration and providers involved. For example, some providers may automatically generate SPF records for their customers, while others may require manual configuration.

When examining RUA reports, it is essential to look for specific error messages or codes that indicate the type of authentication issue. For example, an SPF error may be reported as spf=fail, while a DKIM error may be reported as dkim=fail. The reports may also include additional information, such as the sender's IP address and the recipient's domain.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com; fo=1"

This DMARC record snippet shows a typical configuration, with the p=none policy and email addresses for RUA and RUF reports. However, the SPF record for the same domain may be missing or incorrect, leading to authentication failures.

example.com. IN TXT "v=spf1 ip4:192.0.2.1 include:_spf.example.net -all"

In this example, the SPF record includes an IP address and a reference to another domain's SPF record. If the included domain's SPF record is incorrect or missing, it can cause authentication failures.

• Authentication issues related to SPF and DKIM alignment
• Mismatched sender domains or missing DNS records
• Incorrectly configured DMARC policies or reporting addresses
• Issues with mail server IP addresses or network configurations

import dns.resolver

answers = dns.resolver.resolve('_dmarc.example.com', 'TXT')
for rdata in answers:
 for txt_string in rdata.strings:
 print(txt_string)

This Python code snippet uses the dns library to resolve the DMARC record for a given domain and print the resulting TXT strings.

Warning: When troubleshooting authentication issues, it is crucial to verify the DNS records and mail server configurations to ensure they are correctly set up and aligned with the DMARC policy. Failure to do so can lead to ongoing authentication failures and potential delivery issues.

Decoding RUA Report Data: A Step-by-Step Guide

To effectively decode RUA report data, it is essential to understand the structure and content of these reports. The aggregate reports will show the authentication results for a specific domain, including the number of messages that passed or failed SPF and DKIM authentication. A common pattern is for receivers to send RUA reports in XML format, which can be parsed and analysed to identify authentication issues.

<feedback>
 <version>1</version>
 <record>
 <row>
 <source_ip>192.0.2.1</source_ip>
 <count>10</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <dkim>fail</dkim>
 <spf>fail</spf>
 </policy_evaluated>
 </row>
 </record>
</feedback>

When decoding RUA report data, the first step is to identify the domain and the receiver that sent the report. This information is typically included in the report header. The next step is to examine the authentication results for each message, which are usually presented in a table or list format. The aggregate reports will typically include the following information: the source IP address of the sending server, the number of messages that passed or failed authentication, and the authentication results for SPF and DKIM.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

A hosted or managed setup may handle the collection and analysis of RUA reports differently, so it is crucial to consult the documentation for the specific service being used. In general, however, the process of decoding RUA report data involves the same steps: identifying the domain and receiver, examining the authentication results, and using this information to identify and fix authentication issues.

import xml.etree.ElementTree as ET

# Parse the RUA report XML
root = ET.fromstring(rua_report_xml)

# Extract the authentication results
for row in root.findall('.//row'):
 source_ip = row.find('source_ip').text
 count = int(row.find('count').text)
 dkim_result = row.find('.//dkim').text
 spf_result = row.find('.//spf').text
 
 # Print the authentication results
 print(f'Source IP: {source_ip}, Count: {count}, DKIM: {dkim_result}, SPF: {spf_result}')

When analysing RUA report data, it is essential to consider the potential trade-offs between different authentication policies. For example, a strict policy may block more spam messages, but it may also block legitimate messages that fail authentication. A common approach is to start with a monitoring policy (p=none) and then gradually increase the strictness of the policy (p=quarantine, p=reject) as the authentication issues are identified and fixed.

Warning:
Do not attempt to publish DNS records on a hosting or email provider's own hostname, as this can cause authentication issues and may not be allowed by the provider. Instead, publish the DNS records on the domain that you control, using the correct syntax and format for the specific record type.

Identifying and Fixing SPF-Related Issues

When examining DMARC RUA reports, a common pattern is for senders to encounter SPF-related issues due to misconfigured or overly restrictive SPF records. Receivers typically check the SPF record for the domain in the From header of an email, so it is crucial to ensure the SPF record includes all IP addresses and hostnames that are authorised to send email on behalf of the domain.

A well-structured SPF record should include all necessary IP addresses and hostnames, as shown in the following example:

example.com. IN TXT "v=spf1 ip4:192.0.2.1 include:_spf.example.net -all"

This record specifies that the IP address 192.0.2.1 and any hosts included in the _spf.example.net record are authorised to send email on behalf of example.com.

To fix SPF-related issues, it is essential to review the SPF record and ensure it includes all necessary IP addresses and hostnames. A hosted or managed setup may handle this differently, so it is crucial to consult the provider's documentation for specific guidance.

> Tip: When updating SPF records, it is recommended to use a temporary record with a low TTL to quickly propagate changes and minimise downtime.

Some common issues with SPF records include:

* Overly restrictive records that do not include all authorised senders
* Records that include unnecessary or redundant IP addresses and hostnames
* Records that are not properly formatted or do not include the required v=spf1 version identifier

By carefully reviewing and updating the SPF record, senders can resolve SPF-related issues and improve their overall email deliverability.

Troubleshooting DKIM Authentication Failures

DKIM authentication failures can be particularly tricky to diagnose, as they often involve issues with the DKIM signature itself, or the alignment of the DKIM domain with the sender's domain. A common pattern is for the DKIM signature to be generated correctly, but the public key referenced in the signature is not correctly configured in DNS.

k1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt3WRxWJtUsy5fT8Je13Vbmr0m_8KsKE6BIYsR9d5Kk6Viw7JjxHmsDnXZ3L3ueO4WYx83xY8xVW84k4hU4a7Y1f_mJCE9xQiJ80RJDUUyM28WY4Rc"

When troubleshooting DKIM authentication failures, it is essential to verify that the DKIM public key is correctly published in DNS, and that the selector and domain in the DKIM signature match the public key record.

import dns.resolver

answers = dns.resolver.resolve('k1._domainkey.example.com', 'TXT')
for rdata in answers:
 for txt_string in rdata.strings:
 print(txt_string)

A hosted or managed setup may handle DKIM key management differently, often providing a web interface to manage DKIM keys and selectors.

Tip:
> When generating a new DKIM key, ensure the public key is correctly published in DNS before updating the DKIM signature configuration, to avoid authentication failures due to mismatched keys.

The aggregate reports will show the DKIM authentication results, including the domain and selector used for the signature, allowing for quick identification of any misconfigured DKIM settings.

example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:rua@example.com"

Using RUA Reports to Inform DMARC Policy Decisions

When analysing DMARC RUA reports, the primary goal is to identify authentication issues and inform policy decisions. A common pattern is for receivers to provide detailed information on authentication results, including SPF and DKIM alignment. The aggregate reports will show the number of messages that passed or failed authentication, allowing senders to adjust their DMARC policy accordingly.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:rua@example.com"

This record snippet shows a basic DMARC record with the p tag set to none, indicating that the domain owner is monitoring authentication results but not enforcing any policy. By analysing the RUA reports, the domain owner can determine the best course of action to take, such as updating the p tag to quarantine or reject to protect their domain from phishing attacks.

A list of potential policy decisions based on RUA report analysis includes:

• Updating the p tag to quarantine to divert unauthenticated messages to the spam folder
• Adding or removing IP addresses from the SPF record to improve authentication rates
• Rotating DKIM keys to prevent key compromise

import csv

with open('rua_report.csv', 'r') as file:
 reader = csv.DictReader(file)
 for row in reader:
 if row['spf_result'] == 'fail':
 print(f"SPF failure: {row['source_ip']}")

This code snippet shows an example of how to parse a RUA report CSV file and identify SPF failures. By automating the analysis of RUA reports, senders can quickly identify authentication issues and make data-driven decisions about their DMARC policy.

> Tip: When implementing changes to DMARC policy, it is essential to monitor the RUA reports closely to ensure that the changes do not inadvertently block legitimate traffic. A hosted or managed setup may provide additional tools and features to simplify this process.

Implementing Changes and Monitoring Progress

When implementing changes based on DMARC RUA reports, it is crucial to update DNS records on domains you control. For instance, if the RUA report indicates SPF alignment issues, you may need to update your SPF record. A common pattern is to start with a relaxed policy, such as v=spf1 a mx ip4:192.0.2.1 -all, then adjust as needed.

v=spf1 a mx ip4:192.0.2.1 include:_spf.example.com -all

To monitor progress, regularly review DMARC RUA reports to ensure the changes are effective. The aggregate reports will show whether authentication issues persist or have been resolved.

Tip:
> Regularly review DMARC RUA reports to ensure the changes are effective and adjust your DMARC policy accordingly, such as changing from p=none to p=quarantine or p=reject as authentication issues are resolved.

Check your own domain

• Free deliverability score
• Hosted DMARC

Related reading