What does DMARC loop detection mean and how to resolve it?
Michael Ko
Co-founder & CEO, Suped
Published 6 May 2025
Updated 19 Aug 2025
9 min read
Encountering a "DMARC loop detected" error can be quite perplexing, especially when your email authentication appears to be correctly configured. While these loops are not common, they can certainly disrupt your email flow and hinder deliverability. This type of error usually indicates a misconfiguration in how your DNS records or mail servers are directing DMARC reports, causing them to bounce back and forth in an endless cycle. It is a specific type of mail loop, which can severely impact your ability to receive crucial DMARC aggregate and forensic reports, preventing you from gaining insights into your email ecosystem and potential spoofing attempts.
Understanding this error and knowing how to diagnose and resolve it is vital for maintaining a healthy email sending reputation and ensuring your DMARC implementation works as intended. This guide will clarify what a DMARC loop means, why it happens, and how you can effectively fix it to restore proper DMARC reporting and email security.
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is an email authentication protocol that builds on SPF and DKIM. Its primary purpose is to protect your domain from unauthorized use, such as phishing and spoofing. When a DMARC policy is published in your DNS, it tells receiving mail servers what to do if an incoming email claiming to be from your domain fails SPF or DKIM authentication. This could be to do nothing (p=none), quarantine the email (p=quarantine), or reject it entirely (p=reject).
Beyond its enforcement capabilities, DMARC also provides valuable feedback to domain owners through aggregate (RUA) and forensic (RUF) reports. These XML-formatted reports detail how emails purporting to be from your domain are performing against your DMARC policy, including those that fail authentication. They are essential for gaining visibility into your sending ecosystem and identifying illegitimate senders. This information helps you incrementally adjust your DMARC policy, moving from a monitoring policy to one that actively quarantines or rejects unauthorized emails. If you're encountering issues, understanding how to troubleshoot DMARC failures is critical.
The error "Loop detected! We were referred back to '70.32.65.137'" often surfaces when using DMARC record checking tools. While it might seem like a DMARC-specific issue, it generally points to a problem with how DNS queries are being handled, particularly with MX records or other DNS configurations. This isn't a DMARC policy (p=none, p=quarantine, p=reject) problem directly, but rather an infrastructure issue that prevents the DMARC record from being resolved or the reports from being delivered correctly.
In simpler terms, it means that when the system tries to find information about your domain's DMARC record, it gets sent in a circle. For example, if your DMARC record's RUA tag points to an email address, and the MX record for that reporting domain points back to itself in a way that creates a circular reference, a loop can occur. This prevents the tool from successfully validating your DMARC setup or receiving the vital DMARC reports from Google and Yahoo.
Common causes of DMARC loop errors
DMARC loop errors are almost always a symptom of underlying DNS or mail routing issues, rather than a problem with the DMARC protocol itself. Here are some of the most common culprits:
Misconfigured RUA or RUF addresses: The `rua` (aggregate reports) or `ruf` (forensic reports) tags in your DMARC record specify where DMARC reports should be sent. If the domain for these email addresses is misconfigured, particularly its MX records, it can lead to a loop. For instance, if `rua=mailto:dmarc@yourdomain.com` is set, but the MX records for `yourdomain.com` are improperly configured, the report delivery could loop.
DNS MX record loops: This is a classic mail loop scenario. If your domain's MX records (Mail eXchanger records) create a circular reference, email delivery will fail. A DMARC reporting agent attempting to send a report might get caught in this loop. For more information on mail loops, you can refer to Microsoft's documentation on email non-delivery reports.
Self-referencing DNS entries: Sometimes, a CNAME record or an A record might inadvertently point back to itself or create a chain that circles back, leading to infinite redirects during a DNS lookup.
Mail server routing errors: While less common for DMARC reports specifically, internal mail routing rules or server-side configurations could inadvertently cause reports to be endlessly relayed between two systems.
When a DMARC report (often from a receiver like Google or Yahoo) attempts to reach the specified `rua` address, it performs a DNS lookup for the domain of that address. If that lookup gets stuck in a recursive loop, the report cannot be delivered, resulting in the loop detected error.
How to resolve DMARC loop detection
Resolving a DMARC loop detected error requires a systematic approach, primarily focusing on your DNS configuration and DMARC record syntax. Here's how to tackle it:
Check your DMARC record syntax: Ensure your DMARC record is correctly formatted. A common mistake is using a mailto address for `rua` that belongs to the same domain you're trying to validate, and then having an MX record issue for that domain. Verify the list of DMARC tags and their meanings.
Verify MX records for your DMARC reporting domain: If your `rua` address is `reports@yourdomain.com`, check the MX records for `yourdomain.com`. Ensure they point to a legitimate mail server and don't create a circular reference. You can use a tool like MXToolBox's SuperTool to check your MX records. The DNS MX records error typically indicates this kind of loop.
Avoid self-referencing DNS entries: Double-check any CNAME or A records for your domain and subdomains that might inadvertently point back to an address that loops. This can be particularly tricky to spot.
Consider a dedicated DMARC reporting service: Sending raw DMARC reports to your support inbox is not recommended. These reports can quickly overwhelm an inbox, as they are often voluminous XML files. Instead, use a dedicated DMARC monitoring solution. These services provide a unique email address for your `rua` tag, ensuring reports are sent to a robust infrastructure designed to handle and parse them, reducing the risk of loops and providing readable dashboards. Such services are crucial for diagnosing DMARC failures using DMARC reports.
Here’s an example of a DMARC record that could contribute to a loop if its `rua` address's MX records are misconfigured:
The key is to ensure that the `dmarc-reports@yourdomain.com` email address (or whatever you use) can reliably receive mail without getting into a loop with its own DNS or mail routing. Often, it's safer to use an email address hosted by a different mail provider or a dedicated DMARC reporting service to completely decouple the report delivery from your primary mail infrastructure. This can help you fix issues like DKIM from domain mismatch.
Preventing DMARC loops and ensuring email authentication
To prevent DMARC loops and ensure robust email authentication, consider these best practices and pitfalls:
Best practices
Use an external DMARC monitoring service to receive and parse reports, providing a dedicated and reliable reporting endpoint that isolates your primary email infrastructure.
Regularly review all your DNS records, including MX, A, CNAME, and NS records, to ensure no circular dependencies or misconfigurations exist.
Test your DNS and DMARC configurations using reputable online tools to proactively identify potential issues before they cause service interruptions.
Implement DMARC gradually, starting with a relaxed policy like p=none, and monitor reports closely before moving to stricter enforcement.
Common pitfalls
Directing DMARC reports to a generic or unmonitored email inbox which will quickly become overwhelmed and is likely to experience deliverability issues itself.
Having incorrect or self-referencing MX records for the domain specified in your DMARC rua/ruf tag, leading to recursive lookups and failures.
Assuming DMARC reports are unnecessary once a policy is set to quarantine or reject, missing ongoing insights into legitimate and illegitimate email sources.
Neglecting to check third-party email sending services' DNS requirements, which can often lead to authentication and deliverability issues.
Troubleshooting and prevention
Here’s a table summarizing common DMARC-related issues, including loop detection, and how they manifest:
Issue
Description
Typical cause
Impact
DMARC loop detected
A DMARC checker or reporting agent encounters a circular reference when resolving DNS records related to DMARC reports.
Misconfigured MX records for the rua/ruf domain or self-referencing DNS entries.
DMARC reports are not received, hindering visibility into email authentication performance.
DMARC authentication failure
An email purporting to be from your domain fails SPF or DKIM alignment.
Incorrect SPF or DKIM setup, or emails sent from unauthorized sources.
Emails may go to spam, be quarantined, or be rejected, impacting legitimate email delivery.
DMARC record not found
The receiving mail server cannot find a DMARC TXT record for the sending domain.
DMARC record not published, or incorrect record name (e.g., _dmarc.yourdomain.com).
Domain is not protected by DMARC, making it vulnerable to spoofing and phishing attacks.
Fixing these issues is vital. For instance, if you're experiencing DMARC authentication failures despite SPF and DKIM passing, you might need to investigate why DMARC authentication fails even with passing SPF and DKIM. This often comes down to alignment. Similarly, if your emails are being blocked, a DMARC loop could be part of a broader blocklist problem affecting your IP reputation, and using a blocklist checker can help you identify if your IP has been added to a blacklist.
The importance of DMARC monitoring
Having a DMARC record without actively monitoring its reports is like having a security system without a monitoring station. Raw XML reports are cumbersome to read and analyze manually. Utilizing a specialized service to process these reports will provide clear, actionable insights, helping you detect issues like DMARC loops, identify unauthorized sending sources, and move your DMARC policy towards enforcement (quarantine or reject) confidently. This proactive approach helps to improve email deliverability issues and maintain a strong sender reputation, keeping your emails out of the spam folder.
Views from the trenches
Hearing directly from those in the field can provide invaluable insights. Here are some real-world perspectives and practical advice related to DMARC and email deliverability:
Best practices
Actively monitor DMARC reports to maintain visibility into your email sending infrastructure.
Use a dedicated DMARC monitoring service to parse and analyze complex XML reports effectively.
Regularly review your DNS MX records for your DMARC reporting address to prevent mail loops.
Ensure SPF and DKIM are properly configured and aligned to pass DMARC authentication checks.
Common pitfalls
Sending DMARC reports to a generic support inbox, which can quickly become overwhelmed.
Assuming DMARC is set up correctly without regularly checking DNS configurations and report delivery.
Ignoring DMARC failure reports, leading to undetected spoofing or deliverability issues.
Not understanding the difference between a temporary DNS issue and a persistent loop problem.
Expert tips
Always use an external service for DMARC reporting to avoid self-inflicted loops and improve data readability.
DNS propagation delays can sometimes mimic loop errors; re-check after a few hours if initial fixes don't work.
Ensure your DMARC record's RUA address is hosted on a separate, robust email infrastructure to prevent delivery issues.
Prioritize fixing DNS misconfigurations, as they are a root cause for many DMARC and general email delivery problems.
Marketer view
Marketer from Email Geeks says they checked a client's DMARC records on MXToolBox and encountered a "Loop detected! We were referred back to '70.32.65.137'" message, unsure what it meant.
2022-06-27 - Email Geeks
Marketer view
Marketer from Email Geeks says that the issue might be a temporary problem as DMARC records often look fine upon recheck.
2022-06-27 - Email Geeks
Key takeaways for DMARC health
While a "DMARC loop detected" error can seem intimidating, it's typically a diagnostic message pointing to underlying DNS or mail routing issues rather than a fundamental DMARC flaw. By systematically checking your DMARC record, verifying your DNS configurations, and potentially leveraging a dedicated DMARC monitoring service, you can effectively resolve these loops. This ensures that you receive the critical DMARC reports needed to protect your domain from abuse and maintain optimal email deliverability. Proactive monitoring and correct setup are the keys to a secure and efficient email ecosystem.
Remember, DMARC is a powerful tool for email security, and understanding its nuances, including potential errors like these loops, will empower you to manage your domain's email reputation more effectively. Regular checks and responsive troubleshooting are essential to keep your email sending smooth and secure.
Google or 
Yahoo) attempts to reach the specified `rua` address, it performs a DNS lookup for the domain of that address. If that lookup gets stuck in a recursive loop, the report cannot be delivered, resulting in the loop detected error.
MXToolBox's SuperTool to check your MX records. The DNS MX records error typically indicates this kind of loop.
