25 July 2026 · DMARC Engine · 37 min read
Introduction to DMARC Alignment Challenges with Multi-Tenant ESPs
When implementing DMARC for organisations that utilise multi-tenant Email Service Providers (ESPs), one of the most significant challenges centres around achieving and maintaining DMARC alignment. This is particularly crucial as misalignment can lead to failed DMARC checks, resulting in emails being flagged as spam or even blocked by recipient mail servers. In our experience managing DMARC for numerous customers, we have encountered a variety of issues related to DMARC alignment with multi-tenant ESPs. For instance, a common problem arises when an organisation uses a multi-tenant ESP that shares its sending infrastructure across multiple customers, making it difficult to achieve domain alignment without compromising the security and deliverability of emails.
To illustrate this challenge, consider a scenario where an organisation, let's call it example.com, uses a multi-tenant ESP like esp.io to send marketing emails. The ESP uses a shared domain, mail.esp.io, for all its customers. When example.com sets up its DMARC record with an organisational domain alignment, it might look something like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:aggrep@example.com; ruf=mailto:forensics@example.com; fo=1"However, because the ESP uses mail.esp.io as the return path domain, the DMARC check will fail alignment, as mail.esp.io does not match example.com. This can be mitigated by using a subdomain of example.com as the return path domain, but this requires coordination with the ESP and may not always be feasible.
In a hosted or managed DMARC setup, such as the one we operate at DMARC Engine, we often see customers struggle with the trade-offs involved in configuring DMARC for multi-tenant ESPs. For example, to achieve domain alignment, an organisation might need to use a subdomain for the return path, which can add complexity to their email infrastructure. On the other hand, not achieving domain alignment can lead to deliverability issues, as recipient mail servers may flag emails as spam or block them outright.
One approach to mitigate these issues is to use a technique called "domain alignment via subdomain", where the organisation sets up a subdomain, such as esp.example.com, and configures the ESP to use this subdomain as the return path domain. This way, the DMARC check can pass alignment, as the subdomain matches the organisational domain. However, this approach requires careful planning and coordination with the ESP, as well as updates to the organisation's DNS records.
In our experience, the key to successfully implementing DMARC with multi-tenant ESPs is to carefully evaluate the trade-offs involved and to choose a configuration that balances security and deliverability. This may involve using a combination of techniques, such as domain alignment via subdomain, and closely monitoring aggregate reports to identify and address any alignment issues that may arise. By taking a proactive and informed approach to DMARC configuration, organisations can optimise their email deliverability and protect their brand from spam and phishing attacks.
To further complicate matters, some multi-tenant ESPs may use different sending infrastructures for different types of emails, such as marketing emails versus transactional emails. This can lead to inconsistent DMARC alignment, as different emails may have different return path domains. For example, a marketing email might have a return path domain of mail.esp.io, while a transactional email has a return path domain of transactional.esp.io. In this scenario, the organisation would need to configure its DMARC record to account for both return path domains, which can add complexity to the setup.
In the next section, we will delve deeper into the impact of shared sending infrastructure on DMARC alignment, and explore the initial considerations and trade-offs involved in configuring DMARC for multi-tenant ESPs. We will also examine the pitfalls of organisational domain alignment with multi-tenant ESPs, and provide operational guidance for configuring DMARC records in these scenarios. By understanding the challenges and complexities involved, organisations can better navigate the process of implementing DMARC with multi-tenant ESPs, and optimise their email deliverability and security.
Understanding the Impact of Shared Sending Infrastructure on DMARC Alignment
When organisations utilise multi-tenant Email Service Providers (ESPs), one of the most significant challenges they face is ensuring DMARC alignment. At the centre of this issue is the shared sending infrastructure used by these ESPs. In a typical setup, a multi-tenant ESP will have a pool of IP addresses that are used by multiple customers to send emails. This colour the way DMARC alignment is handled, as the ESP's domain, rather than the customer's domain, is often used in the SPF and DKIM records.
For instance, consider a scenario where a company, let's call it Example Ltd, uses a multi-tenant ESP to send marketing emails. The ESP, in this case, uses a shared IP address, say 192.0.2.1, to send emails on behalf of Example Ltd and several other customers. The ESP's domain, esp.example, is used in the SPF record, which might look something like this:
v=spf1 include:esp.example -allIn this setup, when Example Ltd sends an email via the ESP, the email's From header will contain Example Ltd's domain, example.co.uk, but the Return-Path header will contain the ESP's domain, esp.example. This can cause issues with DMARC alignment, as the domain in the From header does not match the domain in the Return-Path header.
To optimise DMARC alignment in such scenarios, it is crucial to understand how the shared sending infrastructure is organised. In some cases, the ESP may use a dedicated IP address for each customer, which can simplify the DMARC alignment process. However, this is not always the case, and the use of shared IP addresses is more common.
In a hosted or managed setup, such as the one we use at DMARC Engine, we often see customers struggling to configure DMARC records correctly due to the complexities of shared sending infrastructure. To mitigate this, we recommend that customers use a subdomain for their email sending, which can help to improve DMARC alignment. For example, instead of using example.co.uk as the From header domain, Example Ltd could use email.example.co.uk. This subdomain can then be used in the SPF and DKIM records, which helps to ensure that the domain in the From header matches the domain in the Return-Path header.
Another important consideration is the use of DKIM signing domains. When using a multi-tenant ESP, it is common for the ESP to use their own domain as the DKIM signing domain. However, this can cause issues with DMARC alignment, as the DKIM signing domain does not match the domain in the From header. To avoid this, we recommend that customers use a custom DKIM signing domain that matches their own domain. For instance, Example Ltd could use dkim.example.co.uk as their DKIM signing domain, which would be included in the DKIM record:
k1._domainkey.example.co.uk. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4fbmP/QhVx5HjJNQ6s8VwZ8wGvKlK8K1yr58Jm7V3r2K3K2rK3K3K2rK3K2rK3K2rK3K2rK"In this example, the k1._domainkey.example.co.uk record is used to publish the DKIM public key, which is then used by the ESP to sign emails on behalf of Example Ltd.
In short, understanding the impact of shared sending infrastructure on DMARC alignment is crucial for organisations using multi-tenant ESPs. By using a subdomain for email sending, custom DKIM signing domains, and carefully configuring SPF and DKIM records, organisations can improve DMARC alignment and reduce the risk of email deliverability issues. At DMARC Engine, we have seen firsthand the importance of careful configuration and planning when it comes to DMARC alignment, and we recommend that organisations take a proactive approach to managing their email infrastructure to ensure optimal deliverability.
Configuring DMARC for Multi-Tenant ESPs: Initial Considerations and Trade-Offs
When configuring DMARC for multi-tenant Email Service Providers (ESPs), several initial considerations and trade-offs must be taken into account to optimise deliverability and prevent alignment issues. One of the primary concerns is the organisational domain alignment, which can be tricky to manage with shared sending infrastructure. For instance, if a multi-tenant ESP uses a single IP address for multiple customers, the DMARC record for each customer's domain must be carefully configured to avoid false positives or negatives.
A common approach is to use a subdomain for each customer, such as customer1.espdomain.com and customer2.espdomain.com. This allows each customer to have their own DMARC record, which can be configured independently. However, this approach requires careful planning and organisation to ensure that each subdomain is properly aligned with the customer's domain.
Example of a DMARC record for a subdomain:
_dmarc.customer1.espdomain.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:aggrep@customer1.com; ruf=mailto:forensics@customer1.com; fo=1"In a hosted or managed setup, such as the one we operate at DMARC Engine, we often see customers struggling to configure DMARC records for their multi-tenant ESPs. A key trade-off to consider is the balance between security and deliverability. A strict DMARC policy can help prevent spoofing, but it can also lead to false positives and deliverability issues if not properly aligned. On the other hand, a more relaxed policy may improve deliverability but compromise security.
To mitigate these risks, we recommend a phased approach to implementing DMARC. Start with a monitoring-only policy (p=none) and gradually move to a more restrictive policy (p=quarantine or p=reject) once you have verified that your DMARC records are properly aligned and your ESP is configured correctly. It is also essential to monitor your aggregate reports regularly to identify and address any alignment issues promptly.
Another critical consideration is the use of SPF and DKIM records in conjunction with DMARC. SPF records help specify which IP addresses are authorised to send email on behalf of a domain, while DKIM records provide an additional layer of authentication by adding a digital signature to emails. When using a multi-tenant ESP, it is crucial to ensure that the ESP's IP addresses are included in the customer's SPF record and that the DKIM signature is aligned with the customer's domain.
Example of an SPF record for a multi-tenant ESP:
customer1.com. IN TXT "v=spf1 include:espdomain.com -all"In our experience, one of the most common pitfalls is the failure to include all the necessary IP addresses in the SPF record. This can lead to emails being flagged as spam or rejected by receivers. To avoid this, we recommend using a robust SPF record that includes all the IP addresses used by the ESP, as well as any other authorised senders.
In addition to SPF and DKIM, it is also important to consider the use of BIMI (Brand Indicators for Message Identification) records, which provide an additional layer of authentication and can help improve deliverability. BIMI records specify a logo that can be displayed in the recipient's inbox, providing an visual indicator of the email's authenticity.
Example of a BIMI record:
default._bimi.customer1.com. IN TXT "v=BIMI1; l=https://customer1.com/logo.png; a=mailto:security@customer1.com"In short, configuring DMARC for multi-tenant ESPs requires careful consideration of several factors, including organisational domain alignment, SPF and DKIM records, and BIMI records. By taking a phased approach to implementation, monitoring aggregate reports regularly, and ensuring proper alignment of DMARC records, you can optimise deliverability and prevent alignment issues. As a managed DMARC provider, we have seen firsthand the importance of careful planning and configuration in achieving successful DMARC deployment.
The Pitfalls of Organisational Domain Alignment with Multi-Tenant ESPs
When dealing with multi-tenant Email Service Providers (ESPs), organisational domain alignment can be a complex issue, often leading to unforeseen pitfalls. The primary concern is ensuring that the domain used for sending emails aligns with the domain specified in the DMARC record, to avoid authentication failures. In a multi-tenant setup, where numerous senders share the same infrastructure, achieving this alignment can be particularly challenging.
One common issue arises when a sender's organisational domain does not match the domain of the ESP's shared sending infrastructure. For instance, consider a company called Example Ltd, which uses a multi-tenant ESP to send emails from their domain, example.com. However, the ESP's sending infrastructure is set up under the domain esp.io. If Example Ltd's DMARC record is configured with an organisational domain of example.com, but the emails are sent from esp.io, this will cause a mismatch, resulting in DMARC authentication failures.
To mitigate this, some ESPs provide custom domain configuration options, allowing senders to set up a custom domain that matches their organisational domain. For example, Example Ltd could set up a custom domain mail.example.com with the ESP, which would then be used as the sending domain. This approach can help achieve organisational domain alignment, but it requires careful configuration and may involve additional costs.
In a hosted or managed setup, such as the one provided by DMARC Engine, the process of configuring custom domains is often streamlined. The platform provides a straightforward interface for setting up custom domains, and the support team can assist with the configuration process. However, even with a managed setup, it is essential to carefully plan and test the configuration to ensure that organisational domain alignment is achieved.
Another pitfall to watch out for is the use of subdomains in multi-tenant ESPs. When a sender uses a subdomain, such as news.example.com, to send emails, the DMARC record for the parent domain (example.com) may not apply. This can lead to authentication failures, as the subdomain is not explicitly specified in the DMARC record. To address this issue, it is recommended to configure a separate DMARC record for the subdomain, which can be a time-consuming process, especially for senders with multiple subdomains.
# Example DMARC record for a parent domain
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"
# Example DMARC record for a subdomain
_dmarc.news.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"In some cases, the ESP may provide a mechanism for automatically generating DMARC records for subdomains. However, this approach can be limited, and it is often more reliable to manually configure the DMARC records for each subdomain.
The colour and presentation of the email can also impact DMARC alignment. For instance, if an email contains images or links that are hosted on a different domain, this can affect the DMARC authentication process. To avoid issues, it is recommended to use a consistent domain for all email content, including images and links.
When optimising DMARC alignment with multi-tenant ESPs, it is crucial to centre the configuration process around the organisational domain. This involves carefully planning and testing the configuration to ensure that the sending domain aligns with the domain specified in the DMARC record. By doing so, senders can avoid common pitfalls and ensure that their emails are properly authenticated, reducing the risk of delivery issues and improving the overall email deliverability.
In addition to careful planning and testing, it is also essential to monitor the DMARC aggregate reports to identify any alignment issues. These reports provide valuable insights into the authentication process, allowing senders to pinpoint and address any problems. By regularly reviewing the reports and making adjustments to the configuration as needed, senders can optimise their DMARC alignment and improve their email deliverability.
In a hosted or managed setup, the DMARC aggregate reports are often provided through a centralised dashboard, making it easier to monitor and analyse the reports. The support team can also assist with interpreting the reports and providing guidance on how to address any alignment issues.
To illustrate the importance of monitoring DMARC aggregate reports, consider the following example. A sender notices that their emails are being flagged as spam by a particular mailbox provider. Upon reviewing the DMARC aggregate reports, they discover that the emails are failing DMARC authentication due to a mismatch between the sending domain and the domain specified in the DMARC record. By adjusting the configuration to ensure organisational domain alignment, the sender can resolve the issue and improve their email deliverability.
In conclusion to this section, the pitfalls of organisational domain alignment with multi-tenant ESPs can be significant, but by carefully planning and testing the configuration, monitoring DMARC aggregate reports, and optimising the setup, senders can avoid common issues and improve their email deliverability. The next section will provide operational guidance for configuring DMARC records with multi-tenant ESPs, including real-world examples and best practices for achieving organisational domain alignment.
Operational Guidance for Configuring DMARC Records with Multi-Tenant ESPs
When configuring DMARC records for multi-tenant Email Service Providers (ESPs), it is crucial to centre your strategy around the nuances of organisational domain alignment, as this is where most of the pitfalls lie. A key decision point is whether to use a relaxed or strict alignment mode, which dictates how the domain of the sender's address is matched against the domain in the SPF or DKIM signature.
For instance, if you are using a multi-tenant ESP like Mailchimp or Sendgrid, you may need to configure DMARC records for each of your customers, taking into account their specific domain alignment requirements. This can become complex, especially when dealing with a large number of customers, each with their own set of sending domains.
In a hosted or managed setup, such as the one we operate at DMARC Engine, we often see customers struggle with the colour of their DMARC policy, which determines the action to be taken when a message fails DMARC validation. The policy can be set to none, quarantine, or reject, and the choice of policy colour has significant implications for deliverability.
To illustrate this, consider the following DMARC record snippet:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:aggrep@example.com; ruf=mailto:forensics@example.com; fo=1"In this example, the policy is set to none, which means that the receiver will not take any action when a message fails DMARC validation, but will instead send an aggregate report to the specified email address. This is often the preferred choice for organisations that are just starting to implement DMARC, as it allows them to monitor and analyse their email traffic without affecting deliverability.
However, when moving to a stricter policy, such as quarantine or reject, it is essential to carefully consider the potential impact on legitimate email traffic. A reject policy, for instance, can cause emails from legitimate senders to be blocked if they do not align with the organisation's domain, which can lead to a significant loss of business.
To mitigate this risk, we recommend a phased approach to implementing DMARC, starting with a monitoring phase where the policy is set to none, and then gradually moving to a stricter policy as the organisation gains more insight into its email traffic. This approach allows for the identification and remediation of any issues that may cause legitimate emails to fail DMARC validation, thereby optimising deliverability.
Another critical aspect of configuring DMARC records for multi-tenant ESPs is the handling of subdomains. In many cases, ESPs will use subdomains to send emails on behalf of their customers, which can cause issues with DMARC alignment if not properly configured.
For example, if an ESP is using the subdomain esp.example.com to send emails, the DMARC record for this subdomain must be configured to align with the organisation's domain. This can be achieved by using the sp tag in the DMARC record, which specifies the policy for subdomains.
Consider the following DMARC record snippet:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:aggrep@example.com; ruf=mailto:forensics@example.com; fo=1; sp=none; spl=example.com"In this example, the sp tag is set to none, which means that the subdomain esp.example.com will inherit the DMARC policy of the parent domain example.com. The spl tag is used to specify the parent domain, which in this case is example.com.
By properly configuring the DMARC records for subdomains, organisations can ensure that their emails are authenticated correctly and that DMARC alignment is maintained, even when using multi-tenant ESPs.
In addition to the technical aspects of configuring DMARC records, it is also essential to consider the operational implications of managing DMARC for multiple customers. This includes monitoring and analysing aggregate reports, troubleshooting issues, and maintaining up-to-date records.
In a hosted or managed setup, such as the one we operate at DMARC Engine, we provide our customers with a range of tools and services to help them manage their DMARC configuration, including automated reporting and analytics, as well as expert support and guidance.
By taking a proactive and structured approach to configuring DMARC records for multi-tenant ESPs, organisations can optimise their email deliverability, reduce the risk of phishing attacks, and improve their overall email security posture.
Ultimately, the key to successful DMARC implementation is to carefully consider the specific requirements of your organisation, including the use of multi-tenant ESPs, and to develop a tailored strategy that takes into account the nuances of organisational domain alignment, subdomain handling, and policy configuration.
By doing so, organisations can ensure that their DMARC configuration is optimised for their specific use case, and that they are able to reap the benefits of improved email deliverability and security.
It is also worth noting that, when dealing with multi-tenant ESPs, the use of BIMI (Brand Indicators for Message Identification) can also play a crucial role in enhancing email security and deliverability. BIMI allows organisations to specify a logo that will be displayed in the recipient's inbox, providing an additional layer of authentication and visual verification.
However, the implementation of BIMI requires careful consideration of the DMARC configuration, as well as the use of a compatible email client. In a hosted or managed setup, such as the one we operate at DMARC Engine, we provide our customers with guidance and support on implementing BIMI, as well as other advanced email security features.
In short, configuring DMARC records for multi-tenant ESPs requires a deep understanding of the technical and operational aspects of DMARC, as well as a tailored approach that takes into account the specific requirements of your organisation. By following the guidance outlined in this section, organisations can optimise their DMARC configuration, improve their email deliverability, and reduce the risk of phishing attacks.
To further illustrate the complexities of configuring DMARC records for multi-tenant ESPs, let us consider a real-world example. Suppose we have a customer who is using a multi-tenant ESP to send emails on behalf of their organisation. The customer has a domain example.com, and the ESP is using the subdomain esp.example.com to send emails.
The customer wants to implement DMARC with a reject policy, but they are concerned about the potential impact on legitimate email traffic. To mitigate this risk, we recommend a phased approach to implementing DMARC, starting with a monitoring phase where the policy is set to none, and then gradually moving to a stricter policy as the organisation gains more insight into its email traffic.
We also recommend that the customer configures their DMARC records to include the sp and spl tags, to ensure that the subdomain esp.example.com is properly aligned with the organisation's domain.
By following this approach, the customer can ensure that their DMARC configuration is optimised for their specific use case, and that they are able to reap the benefits of improved email deliverability and security.
In the next section, we will provide real-world examples of DMARC record snippets for multi-tenant ESPs, to further illustrate the complexities of configuring DMARC records in a multi-tenant environment.
Real-World Examples of DMARC Record Snippets for Multi-Tenant ESPs
When dealing with multi-tenant Email Service Providers (ESPs), the configuration of DMARC records can become complex due to the shared sending infrastructure. A key challenge is ensuring that the DMARC alignment is correct, which involves matching the domain used in the From header of an email with the domain identified by the SPF or DKIM authentication mechanisms. In this section, we will delve into real-world examples of DMARC record snippets for multi-tenant ESPs, highlighting the centre of the issue: how to correctly configure DMARC to avoid alignment pitfalls.
One common scenario involves a company, let's call it example.com, using a multi-tenant ESP like Mailchimp or Sendgrid. The ESP might use a shared domain, such as mail.example.com or snt.example.com, for sending emails on behalf of example.com. To set up DMARC, example.com would need to create a DMARC record that includes the ESP's shared domain in the SPF and/or DKIM configurations.
For instance, if example.com uses Mailchimp, which uses mailchimp.net as part of its sending infrastructure, the DMARC record for example.com might look something like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; sp=none; adkim=r; aspf=r; fo=1; rf=afrf; ri=86400; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com;"In this example, the rua and ruf tags are used to specify where aggregate and forensic reports should be sent, respectively. However, this record does not explicitly include Mailchimp's domain, which could lead to DMARC alignment issues if Mailchimp sends emails with a From header domain that does not match the domain in the DMARC record.
To address this, example.com might need to adjust its DMARC record to include Mailchimp's domain in the SPF configuration, like so:
example.com. IN TXT "v=spf1 include:mailchimp.net -all"This SPF record tells receiving mail servers that emails sent from mailchimp.net are authorised to send on behalf of example.com. However, this alone does not solve the DMARC alignment issue, as the From header domain must also match the domain in the DMARC record.
A more complex scenario arises when a multi-tenant ESP uses subdomains for each of its customers. For example, if example.com uses an ESP that assigns it the subdomain example.sendesps.com, the DMARC record for example.com would need to account for this subdomain. The ESP might provide a DKIM key that example.com can use in its DMARC record, such as:
selector._domainkey.example.com. IN TXT "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB;"This DKIM key is used to sign emails sent by the ESP, allowing receiving mail servers to verify the authenticity of the emails. However, if the From header domain does not match the domain in the DMARC record, DMARC alignment will fail, even if the DKIM signature is valid.
To optimise DMARC alignment, it is crucial to carefully configure the DMARC record to include all relevant domains and subdomains used by the multi-tenant ESP. This may involve working closely with the ESP to understand its sending infrastructure and ensuring that all necessary domains are included in the DMARC record.
In a hosted or managed setup, such as the one provided by DMARC Engine, the process of configuring DMARC records for multi-tenant ESPs can be simplified. DMARC Engine can help customers identify the correct domains and subdomains to include in their DMARC records, reducing the risk of DMARC alignment issues. Also, DMARC Engine's aggregate report analysis can help customers monitor their DMARC alignment and identify any issues that may arise.
In real-world scenarios, the colour of the DMARC alignment issue can vary greatly depending on the specific setup and configuration. For instance, some multi-tenant ESPs may use a combination of shared and dedicated domains, requiring a more nuanced approach to DMARC configuration. In such cases, it is essential to carefully evaluate the trade-offs between different configuration options and choose the one that best optimises DMARC alignment.
Ultimately, the key to successful DMARC alignment with multi-tenant ESPs is a deep understanding of the sending infrastructure and careful configuration of the DMARC record. By working closely with the ESP and using tools like DMARC Engine, customers can ensure that their DMARC alignment is correct, reducing the risk of email deliverability issues and improving the overall security of their email ecosystem.
Aggregate Report Analysis for DMARC Alignment Issues with Multi-Tenant ESPs
When dealing with multi-tenant Email Service Providers (ESPs), one of the centre pieces of DMARC alignment analysis is the aggregate report, which provides a colour of the email authentication issues that may be occurring. These reports are typically sent to the domain owner on a daily basis, and contain a wealth of information about the authentication results of emails sent from their domain. In a hosted or managed setup, such as the one we operate at DMARC Engine, these reports are collected and analysed automatically, providing our customers with a clear view of their DMARC alignment issues.
To give you a better understanding of what these reports look like, let's take a look at a sample aggregate report:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<version>1.0</version>
<report_metadata>
<org_name>example.com</org_name>
<email>reports@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>10</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<row>
<source_ip>198.51.100.1</source_ip>
<count>20</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>
</feedback>In this example, we can see that the report is for the domain example.com, and it covers the date range from 2022-01-01T00:00:00Z to 2022-01-01T23:59:59Z. The report contains two rows, each representing a different source IP address that sent emails from the example.com domain. The first row shows that 10 emails were sent from the IP address 192.0.2.1, and that both DKIM and SPF failed. The second row shows that 20 emails were sent from the IP address 198.51.100.1, and that both DKIM and SPF passed.
When analysing these reports, it's essential to look for trends and patterns that may indicate DMARC alignment issues. For example, if we see a large number of emails failing DKIM or SPF from a particular IP address, it may indicate that the ESP is not properly configured to send emails from our domain. In a multi-tenant ESP setup, this can be particularly challenging, as multiple customers may be sharing the same sending infrastructure.
To optimise our DMARC alignment, we need to carefully analyse these reports and identify the root cause of any authentication issues. This may involve working with the ESP to update their configuration, or making changes to our own DMARC records. In some cases, we may need to use a more relaxed alignment policy, such as relaxed or none, to allow for more flexibility in our email sending infrastructure.
One of the common pitfalls when analysing aggregate reports is to focus too much on the individual rows, rather than looking at the overall trends and patterns. For example, we may see a single row with a high count of failed emails, but if we look at the overall report, we may see that the majority of emails are passing authentication. In this case, it may not be necessary to take immediate action, but rather to monitor the situation and see if the issue persists.
In a hosted or managed setup, such as the one we operate at DMARC Engine, we use automated tools to analyse these reports and identify potential issues. Our system can detect trends and patterns in the data, and alert our customers to potential problems before they become major issues. We also provide our customers with a clear and easy-to-understand interface to view their aggregate reports, making it simpler for them to identify and troubleshoot DMARC alignment issues.
When troubleshooting DMARC alignment issues, it's essential to have a clear understanding of the email sending infrastructure, including the ESPs and other systems that are sending emails from our domain. In a multi-tenant ESP setup, this can be particularly complex, as multiple customers may be sharing the same infrastructure. To make things more complicated, some ESPs may use multiple IP addresses or domains to send emails, which can make it difficult to identify the root cause of any authentication issues.
To overcome these challenges, we recommend working closely with the ESP to understand their email sending infrastructure, and to identify any potential issues that may be affecting DMARC alignment. We also recommend using a combination of automated tools and manual analysis to identify trends and patterns in the aggregate reports, and to troubleshoot any issues that may arise. By taking a proactive and collaborative approach, we can optimise our DMARC alignment and ensure that our emails are being properly authenticated.
In terms of specific recommendations, we suggest the following:
- Regularly review aggregate reports to identify trends and patterns in email authentication results
- Work closely with the ESP to understand their email sending infrastructure and to identify potential issues
- Use automated tools to analyse aggregate reports and identify potential problems
- Monitor the overall trends and patterns in the data, rather than focusing too much on individual rows
- Consider using a more relaxed alignment policy, such as
relaxedornone, to allow for more flexibility in the email sending infrastructure - Use a clear and easy-to-understand interface to view aggregate reports, making it simpler to identify and troubleshoot DMARC alignment issues.
By following these recommendations, we can optimise our DMARC alignment and ensure that our emails are being properly authenticated, even in complex multi-tenant ESP setups.
Troubleshooting Common DMARC Alignment Issues with Multi-Tenant ESPs
When dealing with multi-tenant Email Service Providers (ESPs), troubleshooting DMARC alignment issues can be a complex task, requiring a deep understanding of the underlying infrastructure and configuration. At DMARC Engine, we have encountered a variety of issues that can cause DMARC alignment problems, and in this section, we will discuss some of the most common pitfalls and provide guidance on how to troubleshoot them.
One of the most common issues we see is with organisational domain alignment, where the domain used in the From header does not match the domain used in the SPF or DKIM records. For example, if a company uses a multi-tenant ESP to send emails from a subdomain, such as news.example.com, but the SPF record is set up for the parent domain example.com, this can cause alignment issues. To troubleshoot this, we recommend checking the From header domain and the SPF/DKIM records to ensure they match, and if not, updating the records to use the correct domain.
Another common issue is with selector rotation, where the DKIM selector is not properly rotated, causing the DKIM signature to fail validation. To troubleshoot this, we recommend checking the DKIM selector rotation policy and ensuring that it is set up to rotate the selector regularly, such as every 30 days. We also recommend monitoring the DKIM signature validation rates to detect any issues with selector rotation.
Example of a DKIM record with a rotated selector:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0TpeWU0Qvw0Ad0tAOmQ5owIwIDAQAB"In a hosted or managed setup, such as DMARC Engine, the DKIM selector rotation is typically handled automatically, and the customer does not need to worry about rotating the selector. However, it is still important for the customer to understand how the selector rotation works and to monitor the DKIM signature validation rates to detect any issues.
We also see issues with SPF record configuration, where the SPF record is not properly set up to include all the IP addresses used by the multi-tenant ESP. To troubleshoot this, we recommend checking the SPF record to ensure it includes all the IP addresses used by the ESP, and if not, updating the record to include the missing IP addresses.
Example of an SPF record that includes multiple IP addresses:
example.com. IN TXT "v=spf1 include:_spf.example.net include:_spf.example.io -all"In addition to these common issues, we also see problems with DMARC record configuration, where the DMARC record is not properly set up to handle subdomains or to specify the correct policy. To troubleshoot this, we recommend checking the DMARC record to ensure it is set up to handle subdomains and to specify the correct policy, such as p=none or p=quarantine.
Example of a DMARC record that handles subdomains and specifies the correct policy:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"To optimise DMARC alignment with multi-tenant ESPs, we recommend regularly monitoring the DMARC aggregate reports to detect any issues with alignment, and updating the DMARC record and SPF/DKIM records as needed to ensure proper alignment. We also recommend working closely with the ESP to ensure that their infrastructure is properly configured to support DMARC alignment.
In terms of trade-offs, one of the main considerations is the balance between security and deliverability. A strict DMARC policy, such as p=reject, can help prevent spoofing and phishing attacks, but it can also cause legitimate emails to be rejected if the alignment is not properly configured. A more relaxed policy, such as p=none, can help ensure deliverability, but it may not provide the same level of security.
Ultimately, the key to troubleshooting common DMARC alignment issues with multi-tenant ESPs is to carefully monitor the DMARC aggregate reports and to regularly review the DMARC record and SPF/DKIM records to ensure they are properly configured. By taking a proactive approach to DMARC alignment, organisations can help prevent spoofing and phishing attacks, and ensure that their emails are delivered to the intended recipients.
At DMARC Engine, we have seen firsthand the importance of proper DMARC alignment, and we recommend that all organisations take the time to carefully review their DMARC configuration and to regularly monitor their DMARC aggregate reports to ensure they are properly aligned. By doing so, organisations can help protect their brand and prevent spoofing and phishing attacks, and ensure that their emails are delivered to the intended recipients.
In our experience, the centre of any effective DMARC alignment strategy is a deep understanding of the underlying infrastructure and configuration, as well as a commitment to regularly monitoring and updating the DMARC record and SPF/DKIM records as needed. By taking a proactive and informed approach to DMARC alignment, organisations can help ensure the security and deliverability of their emails, and protect their brand from spoofing and phishing attacks.
To colour outside the lines, as it were, and think creatively about DMARC alignment, we recommend considering the use of additional security measures, such as BIMI and MTA-STS, to further enhance the security and deliverability of emails. By taking a holistic approach to email security, organisations can help ensure that their emails are properly aligned and delivered to the intended recipients, and that their brand is protected from spoofing and phishing attacks.
In our operational experience, we have found that a key part of optimising DMARC alignment is to organise the DMARC record and SPF/DKIM records in a logical and consistent manner, and to regularly review and update them as needed. By doing so, organisations can help ensure that their emails are properly aligned and delivered to the intended recipients, and that their brand is protected from spoofing and phishing attacks.
To summarise our approach, we recommend a proactive and informed approach to DMARC alignment, which includes regularly monitoring the DMARC aggregate reports, reviewing and updating the DMARC record and SPF/DKIM records as needed, and considering the use of additional security measures to further enhance email security. By taking this approach, organisations can help ensure the security and deliverability of their emails, and protect their brand from spoofing and phishing attacks.
In practice, this means working closely with the ESP to ensure that their infrastructure is properly configured to support DMARC alignment, and regularly reviewing and updating the DMARC record and SPF/DKIM records as needed to ensure proper alignment. It also means considering the use of additional security measures, such as BIMI and MTA-STS, to further enhance email security, and taking a holistic approach to email security that includes regular monitoring and review of the DMARC aggregate reports.
By following this approach, organisations can help ensure that their emails are properly aligned and delivered to the intended recipients, and that their brand is protected from spoofing and phishing attacks
Best Practices for Optimising DMARC Alignment with Multi-Tenant ESPs
When working with multi-tenant Email Service Providers (ESPs), optimising DMARC alignment is crucial to prevent email deliverability issues. One of the key challenges is ensuring that the From domain aligns with the domain used in the SPF or DKIM authentication, a requirement for DMARC to pass. To achieve this, it is essential to carefully evaluate the sending infrastructure and configure DMARC records accordingly.
A common pitfall is the use of shared sending infrastructure, where multiple customers share the same IP address or domain. In such cases, the ESP may use a generic domain, such as esp.example.com, for sending emails. This can cause DMARC alignment issues if the From domain does not match the domain used in the SPF or DKIM authentication. For instance, if a customer uses the domain customer.com in the From header, but the ESP uses esp.example.com for sending, DMARC will fail if the SPF or DKIM record is not configured to include the ESP's domain.
To mitigate this issue, it is recommended to use a subdomain for sending emails, such as customer.esp.example.com. This allows the ESP to use a unique domain for each customer, which can be used in the SPF or DKIM authentication. For example, the SPF record for customer.esp.example.com could include the IP addresses of the ESP's sending infrastructure:
customer.esp.example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 -all"This approach requires careful planning and coordination with the ESP to ensure that the subdomain is properly configured and used for sending emails.
Another best practice is to use DMARC's sp and adkim tags to specify the alignment mode for subdomains. The sp tag allows you to specify the alignment mode for subdomains, while the adkim tag allows you to specify the alignment mode for DKIM signatures. For example:
_dmarc.customer.com. IN TXT "v=DMARC1; p=none; sp=quarantine; adkim=r; aspf=r"In this example, the sp tag is set to quarantine, which means that emails from subdomains will be quarantined if they fail DMARC alignment. The adkim tag is set to r, which means that DKIM signatures must be aligned with the From domain.
When using a hosted or managed DMARC setup, such as DMARC Engine, it is essential to ensure that the setup is properly configured to handle multi-tenant ESPs. For instance, DMARC Engine allows you to configure custom DMARC records for each domain, which can be used to specify the alignment mode for subdomains. Also, DMARC Engine provides detailed aggregate reports that can help you identify DMARC alignment issues with multi-tenant ESPs.
In terms of operational guidance, it is recommended to regularly monitor DMARC aggregate reports to identify any alignment issues. This can help you detect potential issues before they affect email deliverability. For example, if you notice that a large number of emails are failing DMARC alignment due to a mismatch between the From domain and the domain used in the SPF or DKIM authentication, you can take corrective action to update the DMARC records or configure the ESP to use a subdomain for sending emails.
To illustrate this, let's consider an example of a DMARC aggregate report that shows a high number of emails failing DMARC alignment:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>customer.com</org_name>
<email>abuse@customer.com</email>
<extra_contact_info>https://customer.com/dmarc</extra_contact_info>
<report_id>1234567890</report_id>
<date_range>
<begin>2023-02-01T00:00:00Z</begin>
<end>2023-02-01T23:59:59Z</end>
</date_range>
</report_metadata>
<policy_published>
<domain>customer.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>quarantine</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>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
</record>
</feedback>In this example, the report shows that 100 emails failed DMARC alignment due to a mismatch between the From domain and the domain used in the DKIM signature. To address this issue, you could update the DMARC record to include the ESP's domain in the SPF or DKIM authentication, or configure the ESP to use a subdomain for sending emails.
In conclusion to this section, optimising DMARC alignment with multi-tenant ESPs requires careful planning, coordination with the ESP, and regular monitoring of DMARC aggregate reports. By following best practices such as using subdomains for sending emails, specifying alignment modes for subdomains, and regularly monitoring DMARC aggregate reports, you can help prevent email deliverability issues and ensure that your emails are properly authenticated.