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.
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
- Interpreting the Email Notification
- Interpreting the DMARC Report
- Frequently Asked Questions
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:email@example.com;
The RUA report contains the following records which the tool will analyze:
- Date range
- The domain providing the report
- IP address of the mail sender
- SPF and DKIM pass or fail status
- DMARC policy setting (none, quarantine, reject)
- The domain associated with SPF and DKIM
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:
- Report Domain – the domain name for the report submitted
- Report Source – currently only Google and Yahoo! are requiring DMARC
- Date Range – the date range of the report submitted
- Emails Processed – the number of emails sent to email addresses associated with the report source (Google and Yahoo!)
- Emails Passed SPF or DKIM – the number of emails that have passed SPF or DKIM validation
- Emails Failed SPF or DKIM – the number of emails that have not passed SPF or DKIM validation
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:
- IP – the IP address of the email sender
- HostName – the hostname of the email sender based on the IP address if one is associated, otherwise this field will remain blank
- Messages – number of emails sent from the email senders IP address
- Status – pass or fail
- Policy Evaluated – the results based on the DMARC policy:
- Disposition = none, quarantine, reject
- DKIM = pass or fail. Failures result from:
- Invalid or missing DKIM DNS record
- “From” header was modified during email forwarding
- Email header was changed by various email services/gateways
- SPF = pass or fail. Failures result from:
- Invalid or missing SPF DNS record
- Domain specified in the SPF DNS record does not match the domain being reported on
- Auth Results – details of the failure
- Possible Reasons Why Failure Occurred – if the tool can automatically determine why the failure occurred, information will be provided
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:
- 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.
- 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.
- 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.
- 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.
- 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:firstname.lastname@example.org;
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:email@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
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=quarantineto move failing emails to the spam folder.
p=rejectto 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.
Yes, please contact us at firstname.lastname@example.org.
Changing your DMARC (Domain-based Message Authentication, Reporting, and Conformance) policy from
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:
- 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.
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
- Successful quarantine phase: The
quarantinepolicy 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
rejectis 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
rejectpolicy and are on board with the change.
- Gradual Implementation: Move from
quarantineand finally to
rejectin stages, allowing enough time between each stage to monitor the effects and make necessary adjustments.
- Regular Monitoring and Adjustment: Even after reaching the
rejectpolicy, 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.
Without specific failure reasons listed in the report, these suggestions are based on common issues related to DKIM failures and general DMARC compliance.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 email@example.com.
Did you find an error or need additional support? Contact us at firstname.lastname@example.org to let us know!