DMARC and Email Routing Loops

1 September 2026 · DMARC Engine · 40 min read

Introduction to DMARC Routing Loops

DMARC routing loops are a complex issue that can cause email deliverability problems, even for organisations with a well-configured DMARC setup. At the centre of this problem is the way email routing and DMARC validation interact. When an email is routed through multiple servers, each server may add its own domain or IP address to the email's header, which can lead to DMARC validation failures. This is because DMARC checks the domain of the email sender against the domain of the email's SPF and DKIM records, and if these domains do not match, the email may be flagged as spam or rejected.

For example, consider a company called Example Ltd, which has a DMARC record set up to reject emails that fail validation. The DMARC record for Example Ltd might look like this:

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

In this example, the p tag is set to reject, which means that any email that fails DMARC validation will be rejected by the receiving server. The rua tag specifies the email address where aggregate reports will be sent, and the ruf tag specifies the email address where forensic reports will be sent.

Now, let's say that Example Ltd uses a third-party email service provider to send emails on its behalf. This provider may use its own domain or IP address to send emails, which can cause DMARC validation failures. For instance, if the email service provider uses the domain email-service-provider.com to send emails, the email's header might look like this:

Received: from mailserver.email-service-provider.com (mailserver.email-service-provider.com [192.0.2.1])
 by mail.example.com (Postfix) with ESMTPS id 1234567890
 for <recipient@example.com>; Thu, 01 Sep 2022 12:00:00 +0000

In this example, the email was sent from mailserver.email-service-provider.com, which is not a domain that is authorised to send emails on behalf of Example Ltd. As a result, the email may fail DMARC validation, even if the email service provider has a valid SPF record that includes the IP address 192.0.2.1.

To avoid this problem, organisations can use a technique called "SPF flattening", which involves creating a single SPF record that includes all the IP addresses and domains that are used to send emails on behalf of the organisation. For example, Example Ltd might create an SPF record like this:

example.com. IN TXT "v=spf1 include:email-service-provider.com include:another-email-service-provider.com -all"

This record includes the domains email-service-provider.com and another-email-service-provider.com, which are used to send emails on behalf of Example Ltd. The -all tag at the end of the record specifies that any IP address or domain that is not included in the record should be rejected.

However, SPF flattening can be complex to manage, especially for large organisations that use multiple email service providers. A hosted or managed DMARC setup can help to simplify this process by providing a centralised platform for managing SPF and DMARC records. For instance, our team at DMARC Engine provides a hosted DMARC solution that allows organisations to easily manage their SPF and DMARC records, and receive detailed reports on email deliverability and DMARC validation.

In addition to SPF flattening, organisations can also use DKIM to help prevent DMARC routing loops. DKIM involves adding a digital signature to emails, which can be verified by the receiving server to ensure that the email has not been tampered with. To use DKIM, organisations need to generate a pair of keys, one of which is used to sign emails, and the other of which is used to verify the signature. The public key is published in a DNS record, like this:

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB"

The private key is used to sign emails, and the public key is used to verify the signature. By using DKIM, organisations can help to prevent DMARC routing loops, and ensure that their emails are delivered to the recipient's inbox.

Overall, DMARC routing loops are a complex issue that requires careful management of SPF and DKIM records. By using techniques like SPF flattening and DKIM, organisations can help to prevent DMARC routing loops, and ensure that their emails are delivered to the recipient's inbox. A hosted or managed DMARC setup can also help to simplify the process of managing SPF and DMARC records, and provide detailed reports on email deliverability and DMARC validation.

Identifying DMARC Failures due to Routing Loops

Identifying DMARC failures due to routing loops can be a complex task, as it requires a deep understanding of email routing, DMARC policies, and the interactions between different email systems. In our experience, one of the most common challenges is distinguishing between legitimate email traffic and emails that are caught in a routing loop. To make matters worse, the symptoms of a routing loop can be similar to those of other email deliverability issues, such as spam filtering or IP blocking.

When analysing DMARC failures, it is essential to look for patterns that indicate a routing loop. For example, if we see a large number of emails failing DMARC authentication with a specific error code, such as spf=none or dkim=none, it could be a sign of a routing loop. We can use the aggregate reports to identify these patterns and drill down into the details of each failure.

One of the key indicators of a routing loop is the presence of multiple Received headers in the email headers, which can indicate that the email has been forwarded or rerouted multiple times. For instance, if we see an email with the following headers:

Received: from mailserver1.example.com (mailserver1.example.com [192.0.2.1])
 by mailserver2.example.com (Postfix) with ESMTP id 1234567890
 for <recipient@example.com>; Thu, 18 Feb 2023 14:30:00 +0000
Received: from mailserver2.example.com (mailserver2.example.com [192.0.2.2])
 by mailserver1.example.com (Postfix) with ESMTP id 2345678901
 for <recipient@example.com>; Thu, 18 Feb 2023 14:29:00 +0000

This could indicate that the email has been routed between mailserver1.example.com and mailserver2.example.com in a loop.

Another indicator of a routing loop is the presence of a high number of DMARC failures with a Disposition of none. This can indicate that the email has been rejected or blocked by the receiving email system due to a routing loop. For example:

{
 "domain": "example.com",
 "selector": "selector1",
 "disposition": "none",
 "dkim": "none",
 "spf": "none",
 "reason": {
 "type": "message",
 "comment": "mailserver1.example.com[192.0.2.1] (mailserver1.example.com[192.0.2.1])"
 }
}

In a hosted or managed setup, such as the one we offer at DMARC Engine, we can provide additional tools and insights to help identify and troubleshoot routing loops. For instance, our system can automatically detect and flag potential routing loops, and provide detailed reports and analytics to help our customers optimise their email routing and prevent DMARC failures.

It is also important to consider the impact of routing loops on email deliverability. When an email is caught in a routing loop, it can lead to a range of issues, including delayed or lost emails, increased spam filtering, and damage to the sender's reputation. To mitigate these risks, it is essential to implement effective email routing and DMARC policies, and to regularly monitor and analyse DMARC failures to identify and address potential routing loops.

In terms of concrete recommendations, we suggest that our customers implement the following best practices to prevent routing loops and optimise email deliverability:

• Implement a clear and consistent email routing policy, with well-defined rules for email forwarding and rerouting.
• Use a robust and reliable email routing system, such as a dedicated mail transfer agent (MTA), to handle email traffic.
• Regularly monitor and analyse DMARC failures to identify potential routing loops and other email deliverability issues.
• Implement a feedback loop with the receiving email system to detect and respond to routing loops and other email deliverability issues.
• Use a hosted or managed DMARC solution, such as the one we offer at DMARC Engine, to provide additional tools and insights to help identify and troubleshoot routing loops.

By following these best practices and staying vigilant for signs of routing loops, our customers can help prevent DMARC failures and optimise their email deliverability. In the next section, we will discuss how to analyse aggregate reports for routing loop detection, and provide additional insights and recommendations for identifying and addressing routing loops.

Analysing Aggregate Reports for Routing Loop Detection

Analysing aggregate reports is a crucial step in detecting routing loops that may be causing DMARC failures. At DMARC Engine, we organise our daily report analysis around identifying potential routing issues, as these can quickly lead to deliverability problems if not addressed promptly. The key to effective analysis lies in understanding the colour of the data presented in these reports, which often requires a deep dive into the specifics of each record.

When examining aggregate reports, we look for patterns that may indicate a routing loop. For instance, a high volume of emails being sent from a specific IP address to another, only to be bounced back, could suggest a loop. A real-world example of this can be seen in the following record snippet:

{
 "source_ip": "192.0.2.1",
 "count": 100,
 "policy_evaluated": {
 "disposition": "none",
 "dkim": "fail",
 "spf": "fail"
 },
 "identifiers": {
 "envelope_from": "example.com"
 }
}

In this example, the email is failing both DKIM and SPF checks, which could be due to a routing loop causing the email to be forwarded multiple times, thus breaking the DKIM signature and altering the SPF alignment.

To centre our analysis, we categorise the failures based on the policy evaluated disposition and the authentication results. This helps in identifying if the issue is primarily with DKIM, SPF, or a combination of both, which can point towards a routing loop. For example, if we notice a significant number of emails failing DKIM with a disposition of none, it might indicate that the emails are being forwarded without proper DKIM signing, a common issue in routing loops.

In a hosted or managed setup like ours, we have the advantage of aggregating reports from multiple domains and sources, which can help in identifying patterns that might not be visible when looking at reports for a single domain. This aggregated view allows us to optimise our analysis and provide more accurate recommendations to our customers on how to prevent routing loops.

One of the trade-offs in analysing aggregate reports is the balance between detail and volume. While more detailed reports can provide better insights into routing issues, they can also be more cumbersome to analyse, especially when dealing with a high volume of emails. To mitigate this, we use automated tools to parse the reports and highlight potential issues, allowing our team to focus on the most critical problems.

Another consideration is the timing of the analysis. Aggregate reports are typically received on a daily basis, but routing loops can occur at any time. Therefore, it's essential to have a system in place for real-time monitoring of email traffic to quickly identify and respond to potential routing issues. At DMARC Engine, we utilise real-time feedback reports (RUF) in addition to aggregate reports to get immediate feedback on authentication results, which helps in quicker detection and resolution of routing loops.

In practice, analysing aggregate reports for routing loop detection involves a combination of automated processing and human oversight. Automated systems can quickly process large volumes of data to identify potential patterns and anomalies, but human analysis is necessary to understand the context and make informed decisions. For example, what might appear as a routing loop could actually be a legitimate mailing list or forwarding service that is properly configured but not immediately apparent from the report data alone.

To illustrate this point, consider a scenario where an email is sent from example.com to a mailing list hosted on mailinglist.com, which then forwards the email to its subscribers. If the mailing list service does not properly handle DKIM signing or SPF alignment, it could appear as a routing loop in the aggregate reports. However, this is a legitimate use case, and simply blocking or restricting emails from mailinglist.com could interfere with desired communication. Thus, careful analysis and understanding of the email ecosystem are critical in distinguishing between actual routing loops and legitimate email forwarding practices.

In conclusion to this section, effective analysis of aggregate reports for routing loop detection requires a deep understanding of DMARC, SPF, and DKIM, as well as the ability to interpret complex data patterns. By leveraging automated tools, real-time monitoring, and human expertise, organisations can optimise their email routing to minimise DMARC failures and ensure reliable deliverability of their emails.

Understanding the Impact of Routing Loops on Email Deliverability

The impact of routing loops on email deliverability is a complex issue that can have significant consequences for organisations relying on email as a primary means of communication. At the centre of this issue is the way DMARC, SPF, and DKIM interact with email routing mechanisms. When a routing loop occurs, it can lead to a situation where emails are continuously forwarded between two or more mail servers, causing a rapid increase in the number of emails being sent. This can result in a high volume of emails being flagged as spam or blocked by recipient mail servers, ultimately affecting the organisation's email deliverability.

A key factor to consider is the role of DMARC in identifying and preventing routing loops. DMARC provides a mechanism for domain owners to specify which email senders are authorised to send emails on their behalf, and it also provides a way for recipient mail servers to report back to the domain owner on the emails that were received. However, when a routing loop occurs, the DMARC reports can become confusing, making it difficult to identify the root cause of the issue. For example, a DMARC report might show a high number of emails being sent from a particular IP address, but it may not be clear whether this is due to a routing loop or a legitimate email campaign.

To illustrate this point, consider the following example of a DMARC report:

<feedback>
 <report_metadata>
 <org_name>example.com</org_name>
 <email>postmaster@example.com</email>
 <extra_contact_info>https://example.com/dmarc</extra_contact_info>
 <report_id>1234567890</report_id>
 <date_range>
 <begin>2022-01-01T00:00:00Z</begin>
 <end>2022-01-01T23:59:59Z</end>
 </date_range>
 </report_metadata>
 <policy_published>
 <domain>example.com</domain>
 <adkim>r</adkim>
 <aspf>r</aspf>
 <p>reject</p>
 <sp>reject</sp>
 <pct>100</pct>
 </policy_published>
 <record>
 <row>
 <source_ip>192.0.2.1</source_ip>
 <count>100</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <dkim>pass</dkim>
 <spf>fail</spf>
 </policy_evaluated>
 </row>
 </record>
</feedback>

In this example, the DMARC report shows that 100 emails were sent from the IP address 192.0.2.1, but the SPF check failed. This could indicate a routing loop, but it could also be due to a misconfigured SPF record. To determine the root cause, it is necessary to analyse the email headers and the routing path of the emails.

In a hosted or managed setup, such as the one provided by DMARC Engine, the process of identifying and preventing routing loops is often automated. The system can analyse the DMARC reports and email headers to identify potential routing loops, and it can also provide recommendations for configuring SPF and DKIM records to prevent these loops. However, even with automated systems, it is still important for organisations to understand the impact of routing loops on email deliverability and to take steps to prevent them.

One of the key trade-offs to consider when implementing DMARC with routing loops is the balance between preventing spam and allowing legitimate emails to be delivered. If the DMARC policy is set to reject emails that fail the SPF or DKIM checks, it can prevent spam emails from being delivered, but it can also block legitimate emails that are caught in a routing loop. On the other hand, if the DMARC policy is set to allow emails that fail the SPF or DKIM checks, it can allow legitimate emails to be delivered, but it can also allow spam emails to be delivered.

To optimise email routing and minimise DMARC failures, organisations should consider implementing a few key strategies. Firstly, they should ensure that their SPF and DKIM records are correctly configured to include all authorised email senders. Secondly, they should implement a mechanism for monitoring and analysing DMARC reports to identify potential routing loops. Finally, they should consider implementing a feedback loop with their email service provider to ensure that any emails that are blocked due to DMARC failures are properly handled and do not result in a routing loop.

In terms of specific recommendations, organisations should consider the following:

• Ensure that all email senders are included in the SPF record, and that the record is properly formatted to include all IP addresses and domains.
• Implement a DMARC policy that is set to reject emails that fail the SPF or DKIM checks, but also provide a mechanism for allowing legitimate emails to be delivered.
• Monitor and analyse DMARC reports regularly to identify potential routing loops and take steps to prevent them.
• Consider implementing a feedback loop with the email service provider to ensure that any emails that are blocked due to DMARC failures are properly handled.

By following these recommendations and understanding the impact of routing loops on email deliverability, organisations can help to prevent spam emails from being delivered and ensure that legitimate emails are delivered to the intended recipient.

Practical Steps to Identify Routing Loops in DMARC Aggregate Reports

To effectively identify routing loops in DMARC aggregate reports, it is crucial to understand the structure and content of these reports. Aggregate reports are typically sent to the email address specified in the DMARC record, and they contain data on email messages that passed or failed DMARC authentication. The reports are usually in XML format, which can be cumbersome to read and analyse manually, especially for large volumes of email traffic.

In a hosted or managed setup, such as the one we operate at DMARC Engine, these reports are automatically collected and processed, providing customers with a user-friendly interface to view and analyse their DMARC data. However, for those managing their DMARC setup independently, it is essential to develop a strategy for collecting, processing, and analysing these reports to identify potential routing loops.

One of the first practical steps is to ensure that your DMARC record is correctly set up to receive aggregate reports. This involves specifying the email address where you want to receive these reports. For example, a DMARC record might include the following:

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

In this example, rua=mailto:dmarc@example.com specifies the email address where aggregate reports should be sent.

Once you are receiving aggregate reports, the next step is to analyse them for signs of routing loops. A key indicator of a routing loop is the presence of multiple authentication results for a single message, where the message is repeatedly forwarded between mail servers without being delivered to the final recipient. This can be identified by looking for repeated source_ip entries in the report with different result values (e.g., none, pass, fail).

For instance, consider the following snippet from an aggregate report:

<record>
 <row>
 <source_ip>192.0.2.1</source_ip>
 <count>5</count>
 <result>none</result>
 </row>
 <row>
 <source_ip>192.0.2.1</source_ip>
 <count>3</count>
 <result>fail</result>
 </row>
 <row>
 <source_ip>198.51.100.1</source_ip>
 <count>2</count>
 <result>pass</result>
 </row>
 <row>
 <source_ip>192.0.2.1</source_ip>
 <count>1</count>
 <result>none</result>
 </row>
</record>

Here, the repeated appearance of 192.0.2.1 with different results (none and fail) could indicate a routing loop, especially if this pattern persists across multiple reports.

To further investigate, it is helpful to look at the header_from domain and the source_ip to understand the path the email took. If the same header_from domain is seen with multiple source_ip addresses, especially if these IPs belong to different organisations or networks, it may suggest a routing loop involving multiple mail servers.

In our experience at DMARC Engine, automated tools and scripts can significantly streamline the process of analysing aggregate reports for signs of routing loops. These tools can filter out irrelevant data, highlight patterns indicative of routing issues, and even alert administrators to potential problems. For example, a simple script can be written to parse the XML reports, extract relevant fields, and flag records that meet certain criteria (e.g., repeated source_ip with varying result values).

When implementing such automated analysis, it is crucial to consider the potential for false positives. Not all repeated authentication results indicate a routing loop; some may be due to legitimate forwarding practices or email list servers. Therefore, any automated system should be designed to flag potential issues for human review rather than taking automatic corrective action.

In addition to analysing aggregate reports, configuring your SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) records correctly is vital to prevent routing loops. SPF helps in defining which IP addresses are allowed to send emails on behalf of your domain, while DKIM involves encrypting a hash of the email headers and content, which can be verified by the recipient's mail server. Incorrectly configured SPF or DKIM records can lead to authentication failures, which may contribute to or exacerbate routing loops.

For instance, an overly restrictive SPF record might prevent legitimate mail servers from sending emails on your behalf, potentially causing emails to be forwarded unnecessarily and increasing the risk of a routing loop. On the other hand, a too-permissive SPF record might allow spammers to send emails that appear to come from your domain, leading to DMARC failures and potential routing issues.

In a managed setup, tools are often available to help optimise SPF and DKIM configurations, such as SPF flattening tools that help in managing complex SPF includes, or DKIM key management tools that assist in rotating keys and ensuring they are correctly configured across all sending mail servers.

Ultimately, identifying and resolving routing loops in DMARC aggregate reports requires a combination of careful analysis, appropriate tooling, and a deep understanding of email authentication protocols and practices. By following practical steps to identify potential routing loops and taking corrective action, organisations can improve their email deliverability and reduce the risk of DMARC failures.

Configuring SPF and DKIM to Prevent Routing Loops

When it comes to preventing routing loops in a DMARC setup, configuring SPF and DKIM correctly is centre stage. A well-configured SPF record can help prevent unwanted email routing, while DKIM can ensure that emails are authenticated correctly, thus minimising the risk of routing loops. In a hosted setup like ours at DMARC Engine, we often see customers struggle with configuring these records, especially when they have complex email routing setups.

To start with, let's consider a simple example of an SPF record that can help prevent routing loops. Suppose we have a domain, example.com, that uses a third-party email service, mailchimp.net, to send emails. A basic SPF record for example.com might look like this:

v=spf1 include:mailchimp.net -all

This record tells the world that example.com uses mailchimp.net to send emails, and that any email not coming from mailchimp.net should be rejected. However, this record does not take into account the possibility of routing loops. To mitigate this, we can add a few more includes to the SPF record, like this:

v=spf1 include:mailchimp.net include:_spf.example.com -all

In this example, we've added an include for _spf.example.com, which is a subdomain that we use to route emails internally. By including this subdomain in the SPF record, we can ensure that emails that are routed internally are not rejected by the SPF check.

DKIM configuration is also crucial in preventing routing loops. When an email is routed through multiple servers, the DKIM signature can become invalid, causing the email to fail DMARC checks. To prevent this, we can use a technique called "DKIM signing with a relaxed canonicalisation". This involves setting the c parameter in the DKIM signature to relaxed, like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;

By using a relaxed canonicalisation, we can ensure that the DKIM signature remains valid even if the email is routed through multiple servers.

In a hosted setup, we often see customers who have complex email routing setups, with multiple email services and internal routing rules. To configure SPF and DKIM correctly in these scenarios, we need to carefully analyse the email routing flow and ensure that all email services and internal routing rules are included in the SPF record. We also need to ensure that DKIM signing is configured correctly, with a relaxed canonicalisation to prevent DKIM signature invalidation.

For example, suppose we have a customer who uses example.com to send emails, and they have a complex email routing setup that involves multiple email services, including mailchimp.net, sendgrid.net, and amazon ses. To configure SPF correctly, we would need to include all of these email services in the SPF record, like this:

v=spf1 include:mailchimp.net include:sendgrid.net include:amazon ses -all

We would also need to ensure that DKIM signing is configured correctly, with a relaxed canonicalisation, to prevent DKIM signature invalidation.

In addition to configuring SPF and DKIM correctly, we also need to consider the impact of email routing loops on DMARC checks. When an email is routed through multiple servers, the DMARC check can fail, causing the email to be rejected. To prevent this, we can use a technique called "DMARC alignment", which involves setting the adkim and aspf parameters in the DMARC record to r (relaxed), like this:

v=DMARC1; p=reject; pct=100; rua=mailto:example@example.com; ruf=mailto:example@example.com; adkim=r; aspf=r

By using DMARC alignment with relaxed parameters, we can ensure that the DMARC check passes even if the email is routed through multiple servers.

In short, configuring SPF and DKIM correctly is crucial in preventing routing loops in a DMARC setup. By including all email services and internal routing rules in the SPF record, and using a relaxed canonicalisation for DKIM signing, we can ensure that emails are authenticated correctly and that routing loops are prevented. Also, using DMARC alignment with relaxed parameters can help prevent DMARC check failures due to email routing loops. As a hosted DMARC provider, we have seen firsthand the importance of correct SPF and DKIM configuration in preventing routing loops, and we recommend that all our customers carefully analyse their email routing flow and configure their SPF and DKIM records accordingly.

Real-World Examples of Routing Loop Scenarios and Solutions

When dealing with DMARC and email routing loops, it is crucial to understand the complexities and nuances that can arise in real-world scenarios. A hosted or managed setup, such as the one we operate at DMARC Engine, can help mitigate some of these issues, but it is essential to be aware of the potential pitfalls and how to address them.

One common scenario we encounter is when a customer has a mail server that is configured to send emails to a forwarding service, which then redirects the emails to the final destination. This can create a routing loop if the forwarding service is not properly configured to handle DMARC. For instance, if the mail server is set up to send emails to a forwarding service at forwarding-service.example.com, and the forwarding service is configured to forward emails to final-destination.example.net, a routing loop can occur if the final-destination.example.net server is also configured to send emails to forwarding-service.example.com.

To illustrate this, consider the following example. Suppose we have a customer with the domain example.com, and they have a mail server at mail.example.com. They also use a forwarding service at forwarding-service.example.com to redirect emails to final-destination.example.net. The DMARC record for example.com is set up as follows:

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

The SPF record for example.com is set up as follows:

example.com. IN TXT "v=spf1 a:mail.example.com include:forwarding-service.example.com -all"

The DKIM record for example.com is set up as follows:

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt4aux7pNOhj+0xQm8DdX0xVrDjvK5KjY9r2y2w0eJH4rD6JYtj8q9Z3xK4L4rOiYbQziQzJQn4yR0j7zj5B3pY7xK4L4rOiYbQziQzJQn4yR0j7zj5B3pY7xK4L4rOiYbQziQzJQn4yR0j7zj5B3pY7xK"

In this scenario, if the final-destination.example.net server is not properly configured to handle DMARC, it may attempt to send emails back to forwarding-service.example.com, which can create a routing loop. To resolve this issue, we need to ensure that the final-destination.example.net server is configured to handle DMARC correctly, and that the forwarding service is set up to prevent routing loops.

Another scenario we encounter is when a customer has multiple mail servers, each with its own DMARC, SPF, and DKIM configuration. This can create complexity when trying to troubleshoot routing loop issues. For instance, if one mail server is configured to send emails to a forwarding service, and another mail server is configured to send emails directly to the final destination, a routing loop can occur if the forwarding service is not properly configured to handle DMARC.

To illustrate this, consider the following example. Suppose we have a customer with the domain example.com, and they have two mail servers, mail1.example.com and mail2.example.com. They also use a forwarding service at forwarding-service.example.com to redirect emails to final-destination.example.net. The DMARC record for example.com is set up as follows:

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

The SPF record for example.com is set up as follows:

example.com. IN TXT "v=spf1 a:mail1.example.com a:mail2.example.com include:forwarding-service.example.com -all"

The DKIM record for example.com is set up as follows:

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt4aux7pNOhj+0xQm8DdX0xVrDjvK5KjY9r2y2w0eJH4rD6JYtj8q9Z3xK4L4rOiYbQziQzJQn4yR0j7zj5B3pY7xK4L4rOiYbQziQzJQn4yR0j7zj5B3pY7xK4L4rOiYbQziQzJQn4yR0j7zj5B3pY7xK"

In this scenario, if the mail2.example.com server is not properly configured to handle DMARC, it may attempt to send emails to the forwarding service, which can create a routing loop. To resolve this issue, we need to ensure that both mail servers are configured to handle DMARC correctly, and that the forwarding service is set up to prevent routing loops.

In a hosted or managed setup, such as the one we operate at DMARC Engine, we can help mitigate these issues by providing a centralised configuration management system that allows customers to easily manage their DMARC, SPF, and DKIM configurations. We also provide automated reporting and analytics tools that can help identify routing loop issues and provide recommendations for resolving them.

However, even with a hosted or managed setup, it is still essential to ensure that the underlying mail servers and forwarding services are properly configured to handle DMARC. This requires careful planning and configuration to prevent routing loops and ensure that emails are delivered correctly.

To optimise email routing and prevent DMARC failures, we recommend the following best practices:

• Use a centralised configuration management system to manage DMARC, SPF, and DKIM configurations.
• Ensure that all mail servers and forwarding services are properly configured to handle DMARC.
• Use automated reporting and analytics tools to identify routing loop issues and provide recommendations for resolving them.
• Regularly review and update DMARC, SPF, and DKIM configurations to ensure they are aligned with changing email routing scenarios.
• Consider using a hosted or managed setup, such as the one we operate at DMARC Engine, to help mitigate routing loop issues and ensure that emails are delivered correctly.

By following these best practices, organisations can help prevent routing loop issues and ensure that their emails are delivered correctly, while also improving their overall email deliverability and reducing the risk of DMARC failures.

In addition to these best practices, it is also essential to consider the trade-offs and complexities involved in configuring DMARC, SPF, and DKIM to prevent routing loops. For instance, using a strict DMARC policy can help prevent routing loops, but it can also block legitimate emails if not configured correctly.

To illustrate this, consider the following example. Suppose we have a customer with the domain example.com, and they have a mail server at mail.example.com. They also use a forwarding service at forwarding-service.example.com to redirect emails to final-destination.example.net. The DMARC record for example.com is set up as follows:

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

In this scenario, if the final-destination.example.net server is not properly configured to handle DMARC, it may attempt to send emails back to forwarding-service.example.com, which can create a routing loop. To resolve this issue, we can adjust the DMARC policy to use a more relaxed setting, such as p=quarantine, to allow emails to be delivered even if they fail DMARC authentication.

However, using a more relaxed DMARC policy can also increase the risk of spam and phishing emails being delivered to the recipient's inbox. To mitigate this risk, we can use additional security measures, such as spam filtering and email authentication protocols, to help block malicious emails.

In a hosted or managed setup, such as the one we operate at DMARC Engine, we can help organisations navigate these trade-offs and complexities by providing expert guidance and support. We can also help organisations configure their DMARC, SPF, and DKIM settings to prevent routing loops and ensure that emails are delivered correctly, while also improving their overall email deliverability and reducing the risk of DMARC failures.

Ultimately, preventing routing loop issues and ensuring that emails are delivered correctly requires careful planning, configuration, and ongoing management. By following best practices, considering the trade-offs and complexities involved, and using a hosted or managed setup, organisations can help optimise their email routing and prevent DMARC failures, while also improving their overall email deliverability and reducing the risk of spam and phishing emails.

In our experience, the key to preventing routing loop issues is to ensure that all mail servers and forwarding services are properly configured to handle DMARC, and that the underlying email routing scenario is carefully planned and managed. This requires a deep understanding of DMARC, SPF, and DKIM, as well as the ability to analyse and troubleshoot complex email routing scenarios.

By providing expert guidance and support, and using automated reporting and analytics tools, we can help organisations navigate these complexities and ensure that their emails are delivered correctly, while also improving their overall email deliverability and reducing the risk of DMARC failures.

In the next section, we

Trade-Offs and Considerations for Implementing DMARC with Routing Loops

When implementing DMARC with routing loops, there are several trade-offs and considerations that need to be taken into account to ensure email deliverability and prevent authentication failures. One of the primary concerns is the impact of routing loops on SPF, which can lead to a high number of DNS lookups and potentially cause emails to be delayed or blocked. For instance, if a message is forwarded through multiple mail servers, each server may add its own SPF record, resulting in a long chain of DNS lookups that can exceed the 10 lookup limit imposed by SPF.
To mitigate this issue, it is essential to optimise SPF records and ensure that they are properly configured to handle routing loops. This can be achieved by using a hosted or managed DMARC setup, such as the one provided by DMARC Engine, which can help to simplify the process of managing SPF records and prevent authentication failures.
A key consideration when implementing DMARC with routing loops is the use of the spf alignment mode, which can help to prevent SPF authentication failures caused by routing loops. The spf alignment mode checks if the domain in the From header matches the domain in the SPF record, allowing for a more flexible authentication mechanism that can handle routing loops.
However, the spf alignment mode also introduces some trade-offs, such as the potential for increased complexity and the need for more careful configuration. For example, if the spf alignment mode is not properly configured, it can lead to false positives or false negatives, which can impact email deliverability.
To illustrate this, consider the following example of an SPF record that uses the spf alignment mode:

v=spf1 include:_spf.example.com -all

In this example, the SPF record includes the _spf.example.com domain, which is a subdomain that is used for routing loops. The -all mechanism at the end of the record specifies that all IP addresses that are not explicitly allowed should be rejected.
However, if the spf alignment mode is not properly configured, it can lead to authentication failures. For instance, if the domain in the From header does not match the domain in the SPF record, the email may be blocked or delayed.
To prevent such issues, it is crucial to carefully configure the spf alignment mode and ensure that it is properly aligned with the domain in the From header. This can be achieved by using a hosted or managed DMARC setup, which can provide more flexibility and control over the configuration of SPF records.
Another consideration when implementing DMARC with routing loops is the impact on DKIM, which can also be affected by routing loops. DKIM uses a digital signature to authenticate the sender of an email, and routing loops can cause the signature to become invalid.
To mitigate this issue, it is essential to ensure that DKIM is properly configured to handle routing loops. This can be achieved by using a hosted or managed DMARC setup, which can help to simplify the process of managing DKIM records and prevent authentication failures.
A key consideration when implementing DMARC with routing loops is the use of the dkim alignment mode, which can help to prevent DKIM authentication failures caused by routing loops. The dkim alignment mode checks if the domain in the From header matches the domain in the DKIM record, allowing for a more flexible authentication mechanism that can handle routing loops.
However, the dkim alignment mode also introduces some trade-offs, such as the potential for increased complexity and the need for more careful configuration. For example, if the dkim alignment mode is not properly configured, it can lead to false positives or false negatives, which can impact email deliverability.
To illustrate this, consider the following example of a DKIM record that uses the dkim alignment mode:

k1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB"

In this example, the DKIM record uses the dkim alignment mode to specify the domain that should be used for authentication. The k1._domainkey.example.com selector specifies the domain that should be used for the DKIM signature, and the v=DKIM1 tag specifies the version of the DKIM protocol that should be used.
However, if the dkim alignment mode is not properly configured, it can lead to authentication failures. For instance, if the domain in the From header does not match the domain in the DKIM record, the email may be blocked or delayed.
To prevent such issues, it is crucial to carefully configure the dkim alignment mode and ensure that it is properly aligned with the domain in the From header. This can be achieved by using a hosted or managed DMARC setup, which can provide more flexibility and control over the configuration of DKIM records.
In addition to the considerations mentioned above, it is also essential to consider the impact of routing loops on email deliverability. Routing loops can cause emails to be delayed or blocked, which can impact the overall deliverability of emails.
To mitigate this issue, it is essential to ensure that email routing is properly configured to handle routing loops. This can be achieved by using a hosted or managed DMARC setup, which can help to simplify the process of managing email routing and prevent authentication failures.
A key consideration when implementing DMARC with routing loops is the use of email routing protocols such as SMTP, which can help to prevent routing loops. SMTP uses a set of rules to determine the best path for an email to take, and it can help to prevent routing loops by avoiding loops in the email routing path.
However, SMTP also introduces some trade-offs, such as the potential for increased complexity and the need for more careful configuration. For example, if SMTP is not properly configured, it can lead to false positives or false negatives, which can impact email deliverability.
To illustrate this, consider the following example of an SMTP configuration that uses routing loops:

smtp.example.com. 300 IN MX 10 smtp.example.com
smtp.example.com. 300 IN MX 20 smtp2.example.com

In this example, the SMTP configuration uses two mail servers, smtp.example.com and smtp2.example.com, to handle email routing. The MX 10 and MX 20 records specify the priority of each mail server, with the lower priority number indicating the preferred mail server.
However, if the SMTP configuration is not properly configured, it can lead to routing loops. For instance, if the smtp.example.com mail server is not properly configured to handle emails from the smtp2.example.com mail server, it can cause emails to be delayed or blocked.
To prevent such issues, it is crucial to carefully configure the SMTP configuration and ensure that it is properly aligned with the email routing path. This can be achieved by using a hosted or managed DMARC setup, which can provide more flexibility and control over the configuration of email routing.
In short, implementing DMARC with routing loops requires careful consideration of several trade-offs and considerations, including the impact on SPF, DKIM, and email deliverability. By using a hosted or managed DMARC setup and carefully configuring the spf and dkim alignment modes, email routing protocols such as SMTP, and DKIM records, organisations can help to

Optimising Email Routing to Minimise DMARC Failures

To optimise email routing and minimise DMARC failures, it is essential to understand the intricacies of email routing and how it interacts with DMARC, SPF, and DKIM. A common issue we see at DMARC Engine is the misconfiguration of email routing, which can lead to DMARC failures and negatively impact email deliverability. For instance, when a message is forwarded from one server to another, the SPF check may fail if the forwarding server is not included in the SPF record of the original domain.

To mitigate this, organisations can use a technique called SPF record chaining, where the forwarding server includes the original domain's SPF record in its own SPF record, using the include directive. This allows the receiving server to verify the SPF check for the original domain. For example, if a message is forwarded from example.com to forwarder.example.net, the SPF record for forwarder.example.net might include the following:

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

This tells the receiving server to include the SPF record of example.com when verifying the SPF check for messages forwarded by forwarder.example.net.

Another critical aspect of optimising email routing is to ensure that DKIM signatures are correctly configured and aligned with the domain's DMARC policy. When a message is signed with a DKIM key, the receiving server verifies the signature by checking the DKIM-Signature header against the public key published in the domain's DNS. However, if the message is forwarded or modified in transit, the DKIM signature may become invalid, leading to DMARC failures.

To avoid this, organisations can use a technique called DKIM key rotation, where multiple DKIM keys are published in the domain's DNS, each with a different selector. This allows the sending server to rotate through different DKIM keys, reducing the impact of key compromise or expiration. For example, a domain might publish the following DKIM keys:

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB"
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB"

This allows the sending server to sign messages with either the default or selector1 key, reducing the impact of key compromise or expiration.

In a hosted or managed setup, such as DMARC Engine, the process of optimising email routing and minimising DMARC failures is often automated through the use of advanced algorithms and machine learning techniques. These systems can analyse aggregate reports and identify potential routing loops and misconfigurations, providing recommendations for remediation. For example, DMARC Engine's automated system might detect a routing loop between two servers and recommend the addition of an SPF record include directive to resolve the issue.

When it comes to configuring SPF and DKIM to prevent routing loops, there are several best practices that organisations should follow. Firstly, it is essential to ensure that all sending servers are included in the SPF record of the domain, using the ip4 or ip6 directives for IPv4 and IPv6 addresses, respectively. For example:

example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip6:2001:db8::1 -all"

This tells the receiving server that messages from the IP addresses 192.0.2.1 and 2001:db8::1 are authorised to send on behalf of the domain example.com.

Secondly, organisations should ensure that DKIM signatures are correctly aligned with the domain's DMARC policy. This can be achieved by using a consistent selector for all DKIM keys and ensuring that the DKIM signature is included in the message headers. For example:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; t=1643723900; bh=...; h=from:to:subject; b=...

This tells the receiving server that the message has been signed with the selector1 key and that the signature should be verified against the public key published in the domain's DNS.

Finally, organisations should regularly monitor their aggregate reports to identify potential routing loops and misconfigurations. This can be achieved by using a hosted or managed setup, such as DMARC Engine, or by manually analysing the reports and implementing remediation steps as needed. By following these best practices and optimising email routing, organisations can minimise DMARC failures and ensure that their emails are delivered to the intended recipient.

In real-world scenarios, the impact of routing loops on email deliverability can be significant. For example, if a message is forwarded from one server to another without proper SPF and DKIM configuration, the receiving server may reject the message or mark it as spam. This can lead to a loss of reputation for the sending domain and negatively impact email deliverability. To avoid this, organisations should ensure that their email routing is correctly configured and that SPF and DKIM are properly aligned with the domain's DMARC policy.

In terms of trade-offs and considerations, organisations should be aware that optimising email routing and minimising DMARC failures often requires a balance between security and deliverability. For example, implementing strict SPF and DKIM policies may improve security but may also lead to false positives and rejected messages. Similarly, using a hosted or managed setup may simplify the process of optimising email routing but may also introduce additional costs and complexity.

To illustrate this, consider a scenario where an organisation uses a third-party mailing list service to send marketing emails. The mailing list service may use a different domain and IP address than the organisation's primary domain, which can lead to SPF and DKIM misconfigurations and routing loops. To resolve this, the organisation may need to add the mailing list service's domain and IP address to their SPF record and ensure that the DKIM signature is correctly aligned with the domain's DMARC policy. This may require additional configuration and testing to ensure that the emails are delivered correctly and that the organisation's reputation is not negatively impacted.

In conclusion to this section, optimising email routing to minimise DMARC failures requires a deep understanding of email routing, SPF, DKIM, and DMARC. By following best practices, such as SPF record chaining, DKIM key rotation, and regular monitoring of aggregate reports, organisations can ensure that their emails are delivered to the intended recipient and that their reputation is not negatively impacted. Whether using a hosted or managed setup or manual configuration, the key is to strike a balance between security and deliverability, and to be aware of the trade-offs and considerations involved in optimising email routing.

Related reading

• Quantifying the Impact of DNS Propagation Delays on DMARC Deployment
• DMARC and SPF Record Interactions with Greylisting
• DMARC, SPF, and DKIM for Domains with Automated Subdomain Provisioning