Our DMARC Report Analyzer helps you make sense of the RUA DMARC report you receive from mail service providers. By uploading a GZ (GZIP) or ZIP file, the tool will provide you with stats on your email deliverability along with a downloadable report that details failures so you can take action.

Please note that this tool does not support RUF forensic reports. Due to privacy concerns, some providers do not provide this report, therefore it is not required for DMARC compliance.


Article Contents

This support article contains several sections which can be accessed quickly by clicking the appropriate link below:


Uploading Your GZ (GZIP) or ZIP Files for Analyzing

In order to receive daily reports, your DMARC record must have an email address specified for an RUA value in your TXT record, as in this example:

v=DMARC1; p=quarantine; rua=mailto:you@yourdomain.com;

The RUA report contains the following records which the tool will analyze:

Drag and drop, or browse for your files to upload them to the tool:


You may select multiple files to upload at once, however, the maximum file size is 250mb.

Once files are uploaded, click Next.


By default, Your Store Tools will email you when your files are analyzed. If you choose to receive this notification, verify your email address is correct before clicking Submit. It is recommended you receive your notification via email, as the email contains additional information that is not provided in the downloadable report.

For those not opting to receive an email, you’ll receive a notification in the dashboard when the analysis is complete so you can download your report.


Interpreting the Email Notification

If you opted to receive an email notification when the upload is complete, the body of the email contains aggregate information regarding pass and fail email stats extrapolated from your uploaded files. This email contains:

Additionally, the email will remind you of your current DMARC policy settings (none, quarantine, reject). In order to change these settings, you will need to modify your DMARC TXT record with your domain provider.


Interpreting Our DMARC Report

After analyzing your RUA files, we generate a CSV file that provides more information on all reported failures. This report does not list details of successful validations as you only need to review failures for DMARC compliance. Information in the report includes:


Frequently Asked Questions

DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, is an email authentication protocol designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose of DMARC is to improve and ensure email security by preventing cybercriminals from sending messages with forged “From” addresses in emails, which is a common tactic used in phishing and spam attacks.

Here’s why you should be concerned about DMARC:

  1. Prevents Email Spoofing: DMARC helps to prevent attackers from sending emails that appear to come from your domain. This is crucial for protecting your brand and your recipients from potentially harmful and fraudulent emails.
  2. Increases Email Deliverability: By implementing DMARC, you signal to receiving email servers that your domain’s emails are protected, which can increase the likelihood of your emails being successfully delivered to the recipient’s inbox rather than being marked as spam or rejected.
  3. Provides Visibility and Reporting: DMARC policies allow domain owners to receive reports about emails sent from their domain, including those that pass or fail DMARC evaluation. This visibility is key for understanding your email ecosystem and identifying potential security issues.
  4. Protects Your Reputation: Email fraud can damage your organization’s reputation significantly. By preventing phishing attacks and ensuring that only authorized emails are sent from your domain, DMARC helps protect your brand’s integrity and trustworthiness.
  5. Compliance: For some organizations, especially in certain industries, implementing DMARC may be part of regulatory compliance requirements to ensure secure email practices.

Implementing DMARC involves setting up DNS records to specify the DMARC policy for your domain. This policy tells receiving email servers how to handle emails that don’t pass authentication checks (SPF and DKIM). The policy can specify actions such as none (take no action), quarantine (move to spam), or reject (block the email), depending on the level of protection the domain owner wants to enforce.

Given the ongoing and evolving threat of email-based attacks, DMARC is an essential component of an organization’s email security strategy. It not only helps in preventing the abuse of your domain but also contributes to the broader fight against phishing and spam, enhancing the overall trustworthiness of email as a communication medium.

Setting up DMARC (Domain-based Message Authentication, Reporting, and Conformance) involves a few key steps. It requires that you first have SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) records in place for your domain. These steps are designed to help you implement DMARC in a way that monitors email flow initially, allowing you to gradually enforce stronger policies without impacting legitimate email delivery.

1. Check SPF and DKIM Configuration

  • SPF: Ensure you have an SPF record in your DNS that lists all IP addresses that are authorized to send email on behalf of your domain.
  • DKIM: Ensure DKIM is set up, which involves creating a DKIM record in your DNS. This record holds a public key that corresponds to a private key used by your sending servers to sign outgoing emails.

 

2. Create a DMARC Record

A DMARC policy is published in your DNS as a TXT record. The record starts with v=DMARC1; followed by a series of tags that define the policy. Here’s an example of a basic DMARC record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

This record specifies that:

  • v=DMARC1 indicates the DMARC version.
  • p=none sets the policy to “none,” meaning no specific action is taken on emails that fail DMARC checks, but it allows data collection.
  • rua=mailto:dmarc-reports@example.com specifies where aggregate reports should be sent.

 

3. Publish the DMARC Record in DNS

Add the DMARC TXT record to your domain’s DNS settings. The record should be named _dmarc.yourdomain.com, replacing yourdomain.com with your actual domain name.

 

4. Monitor Reports and Adjust the Policy

Initially, set the policy to p=none to monitor the reports without affecting email delivery. Analyze the reports to understand which emails are failing DMARC and why. This phase is crucial for identifying legitimate email sources that may need SPF or DKIM adjustments.

 

5. Gradually Enforce the Policy

Once you’re confident in your SPF and DKIM setup and understand your email flow, adjust the DMARC policy to a more strict setting:

  • p=quarantine to move failing emails to the spam folder.
  • p=reject to completely reject emails failing DMARC checks.

 

It’s advisable to make these policy changes gradually and monitor the impact on email delivery to ensure legitimate emails aren’t mistakenly blocked or marked as spam.

 

6. Regularly Review Reports and Adjust As Needed

DMARC reports provide ongoing insights into your email ecosystem. Regular review helps you adjust your SPF, DKIM, and DMARC settings as needed, ensuring optimal email delivery and security.

By following these steps, you can effectively set up DMARC for your domain, enhancing your email security posture and protecting your domain from abuse.

Changing your DMARC (Domain-based Message Authentication, Reporting, and Conformance) policy from none to quarantine or reject is an important decision that impacts how your emails are handled by receiving servers. This transition should be carefully managed to ensure legitimate emails are delivered while preventing unauthorized use of your domain. Here’s a guideline on when to consider changing your DMARC policy:

From none to quarantine:

  • After thorough monitoring: You’ve been in the monitoring phase (p=none) long enough to collect and analyze DMARC reports, understanding the sources of your legitimate emails and identifying unauthorized sending attempts.
  • SPF and DKIM are correctly configured: Ensure that all legitimate email sources are properly aligned with SPF and DKIM records. This means that emails sent on behalf of your domain pass these authentication checks.
  • Low rate of false positives: You have a high confidence level that legitimate emails won’t be wrongly classified as spam due to SPF, DKIM, or DMARC failures.
  • Preparedness for potential delivery issues: You’re ready to handle and quickly resolve any delivery problems that might arise for legitimate emails as you tighten the policy.

 

Transitioning to quarantine allows you to start applying some level of enforcement on emails failing DMARC checks by having them placed in the spam/junk folder, which reduces the risk of direct impact on your email deliverability compared to moving straight to reject.

 

From quarantine to reject:

  • Successful quarantine phase: The quarantine policy has been in place without significant issues, and you’ve resolved any false positives or alignment problems.
  • Ongoing review of DMARC reports: Continue to review DMARC reports regularly to ensure no legitimate emails are being misclassified and that unauthorized email sources are correctly being blocked or quarantined.
  • Understanding the impact on email deliverability: Be aware that moving to reject is the strictest policy, meaning emails failing DMARC checks will be outright rejected by receiving mail servers. This is the final step in fully enforcing DMARC, preventing phishing and spoofing attempts using your domain.
  • Stakeholder communication: Ensure that all stakeholders, including email administrators and IT security teams, are informed about the potential impacts of moving to a reject policy and are on board with the change.

 

General Recommendations:

  • Gradual Implementation: Move from none to quarantine and finally to reject in stages, allowing enough time between each stage to monitor the effects and make necessary adjustments.
  • Regular Monitoring and Adjustment: Even after reaching the reject policy, continue to monitor your DMARC reports and adjust your email authentication practices as needed to maintain a secure and effective email ecosystem.

 

The transition between DMARC policies should be considered a process of continuous improvement, aiming to balance email deliverability with the security and integrity of your domain’s email practices.

If the hostname in your DMARC (Domain-based Message Authentication, Reporting, and Conformance) report is empty, this might be due to several reasons related to how the reporting mail servers handle the reporting data or issues within the DMARC report generation process itself. Understanding why this occurs requires examining different aspects of DMARC reporting and email infrastructure:

Reporting Mail Server Configuration: Some mail servers may not include the hostname in the DMARC reports they generate. This could be due to the server’s configuration or privacy policies. Mail servers are configured by their operators, and there might be differences in how much detail they include in reports.

Privacy Concerns: In some cases, report senders might omit hostnames to anonymize the data and protect privacy. This is more common in scenarios where revealing a hostname might expose sensitive information about the email infrastructure.

Technical Limitations: The process of generating and sending DMARC reports can sometimes encounter technical limitations or errors that result in incomplete data. This might include issues with the software used by the reporting entity or network problems that prevent complete data collection.

Policy Aggregation: DMARC aggregate reports (identified by the XML tag rua in the DMARC TXT record) are designed to provide a summary of authentication results rather than detailed forensic information. As such, some details like specific hostnames might not be included, especially if the reporting entity aims to provide a high-level overview rather than exhaustive details.

In many cases, the absence of a hostname in a DMARC report is not a critical issue for understanding and improving your email authentication posture. Focus on the aggregate data and trends in DMARC failures and successes to identify and address authentication issues.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) provides two types of reports that help domain owners monitor and protect their domains against fraudulent email activities: Aggregate reports (RUA) and Forensic reports (RUF). Understanding the differences between these reports is crucial for effective DMARC implementation and email security management.

Aggregate Reports (RUA)

  • Purpose: Aggregate reports provide a high-level overview of all email traffic purporting to come from your domain. They are designed for statistical analysis and long-term monitoring.
  • Content: These reports contain aggregated data about messages, including counts of messages that passed or failed DMARC evaluation, broken down by result and aligned with SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) authentication results.
  • Format: RUA reports are provided in an XML format, making them suitable for automated processing and analysis by specialized tools or software.
  • Frequency: Typically sent daily, although the frequency can vary based on the reporting organization’s policies and the volume of email traffic.
  • Privacy: Aggregate reports are designed to minimize privacy concerns, as they do not include specific details about individual email messages.

 

Forensic Reports (RUF)

  • Purpose: Forensic reports provide detailed information about specific email messages that fail DMARC authentication. They are intended for in-depth analysis of authentication failures to identify configuration issues or potential abuse.
  • Content: These reports include detailed information about the individual email that failed DMARC checks, such as headers and sometimes parts of the body of the email, depending on the reporting entity’s policy regarding redaction for privacy.
  • Format: RUF reports can be sent in different formats, including ARF (Abuse Reporting Format), which is a standard format for reporting email abuse.
  • Frequency: Sent in near real-time, forensic reports are generated and sent shortly after an email fails DMARC checks, providing timely information for analysis.
  • Privacy: Due to the detailed information included, forensic reports have higher privacy considerations. Some organizations may choose not to send or receive forensic reports to protect sensitive information.

 

Key Differences

  • Level of Detail: RUA reports provide aggregated data for monitoring and trend analysis, while RUF reports give detailed forensic information about specific email failures.
  • Use Case: RUA reports are used for ongoing monitoring and identifying trends over time, whereas RUF reports are intended for diagnosing specific issues with email authentication.
  • Privacy Implications: RUF reports have greater privacy implications due to the detailed information they contain, requiring careful handling and sometimes leading organizations to opt-out of sending or receiving them.

 

In summary, RUA and RUF reports serve complementary purposes in DMARC reporting by offering both a high-level view of email authentication performance and detailed forensic data for troubleshooting specific issues. Domain owners should leverage both types of reports, where available, to enhance their email security posture while being mindful of the privacy implications associated with forensic reports.

Without specific failure reasons listed in the report, these suggestions are based on common issues related to DKIM failures and general DMARC compliance.

 

  1. Review DKIM Setup: For emails failing due to DKIM, ensure that your DKIM records are correctly published in your DNS and that the emails are being signed properly with the DKIM signature. This involves checking that the selector and domain name in the DKIM signature match the published records.
  2. SPF Alignment: While SPF seems to pass in the cases shown, ensure that your SPF records include all IPs that are authorized to send mail on behalf of your domain. SPF alignment under DMARC requires that the Return-Path or envelope domain matches the domain in the From header.
  3. Check for Alignment Issues: DMARC requires alignment between the domain in the From header and the domains validated by SPF and DKIM. Even if SPF and DKIM individually pass, DMARC can still fail if the domains do not align. Ensure that the domains used in your SPF and DKIM setups match the domain used in the From email address.
  4. Review DMARC Policy: Your DMARC policy (p=none, quarantine, reject) determines how receivers handle your emails based on the DMARC evaluation. If you’re in monitoring mode (p=none), consider tightening your policy as you fix these issues, moving towards quarantine or reject to improve security.
  5. Monitor Reports Regularly: Continue monitoring DMARC reports for ongoing issues and adjustments. This can help identify new sources of email that may not be properly authenticated or aligned with your DMARC policy.
  6. Engage with Sending Services: If third-party services are used to send emails, ensure they are authorized in your SPF record and their DKIM signatures are correctly set up. It may involve coordinating with these services to ensure proper email authentication practices are in place.

f your emails are failing DMARC checks, you should:

  • Verify that your SPF and DKIM records are correctly configured and that the emails you send are aligned with these records.
  • Check the alignment issue; DMARC requires that the domain in the From address matches the domains authenticated by SPF and/or DKIM.
  • Review the DMARC policy to ensure it is set correctly. If you are in monitoring mode (p=none), consider moving to a stricter policy only after ensuring that legitimate emails are passing DMARC checks.
  • Investigate the source of the failed emails. If they are legitimate but failing due to configuration issues, correct these issues. If the emails are unauthorized, take steps to stop these sources from sending emails on behalf of your domain.

Correcting a DMARC setup failure involves:

  • Reviewing the SPF, DKIM, and DMARC records for accuracy and proper configuration.
  • Ensuring that the email sources are authorized and properly authenticated using SPF and/or DKIM.
  • Adjusting your DMARC policy as needed based on the analysis of DMARC reports.
  • Regularly monitoring DMARC reports for ongoing issues and addressing them promptly to maintain the integrity of your email communications.

t’s advisable to review your DMARC reports regularly, at least monthly, to monitor the performance of your email authentication practices and identify any unauthorized use of your domain. Adjust your DMARC policy as needed based on these reviews, especially when you change email service providers, add new email sources, or notice changes in email delivery performance.

Implementing and managing DMARC can be complex, but it’s a crucial component of your e-commerce store’s email security and deliverability strategy. Regular monitoring and adjustment of your DMARC setup will help protect your brand and your customers from email fraud.

While we are not experts in email deliverability, we can help you analyze your reports and give some advice on how to correct the issues you’re seeing.  Please email us at support@yourstorewizards.com.


Did you find an error or need additional support? Contact us at support@yourstorewizards.com to let us know!