17 August 2026 · DMARC Engine · 33 min read
The Subdomain Conundrum: Segmenting Email Lists with DMARC
When implementing DMARC, one of the most critical decisions is whether to use a single domain or subdomains for email list segmentation. This decision has significant implications for deliverability, as it affects how email service providers (ESPs) evaluate the authenticity of emails. At DMARC Engine, we have seen numerous cases where subdomain configuration has either made or broken email deliverability.
In a hosted setup, such as ours, the centre of attention is often on optimising DMARC records to ensure the highest possible deliverability rates. However, the colour of the DMARC landscape changes dramatically when subdomains are introduced. For instance, consider a company like example.com that decides to use subdomains for different departments, such as marketing.example.com and sales.example.com. Each subdomain would require its own DMARC record, which can lead to a proliferation of DNS entries and increased complexity.
A common mistake we see is the failure to set up separate DMARC records for subdomains, instead relying on the parent domain's DMARC record. This approach can lead to issues with ESPs that do not correctly handle subdomains. For example, if the parent domain example.com has a DMARC record with a policy of p=reject, but the subdomain marketing.example.com does not have its own DMARC record, some ESPs may incorrectly apply the parent domain's policy to the subdomain, leading to rejected emails.
To illustrate this point, consider the following DMARC record for the parent domain example.com:
_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 DMARC record specifies a policy of p=reject, which means that any email that fails authentication will be rejected. However, if the subdomain marketing.example.com does not have its own DMARC record, some ESPs may apply this policy to emails sent from the subdomain, even if they are authentic.
To avoid this issue, it is essential to set up separate DMARC records for each subdomain. For example:
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:aggrep-marketing@example.com; ruf=mailto:forensics-marketing@example.com; fo=1"In this example, the DMARC record for the subdomain marketing.example.com specifies a policy of p=none, which means that emails that fail authentication will not be rejected. This allows for more fine-grained control over email deliverability for each subdomain.
When setting up DMARC for subdomains, it is also crucial to consider the organisational structure and email sending practices. For instance, if a company has multiple subdomains for different departments, it may be necessary to set up separate DMARC records for each subdomain, as well as a parent domain DMARC record. This can help to ensure that emails sent from each subdomain are authenticated correctly and that deliverability is optimised.
In our experience, the key to successful DMARC implementation with subdomain segmentation is to carefully plan and organise the DNS infrastructure. This includes setting up separate DMARC records for each subdomain, as well as ensuring that the parent domain DMARC record is correctly configured. By taking a structured approach to DMARC implementation, companies can optimise their email deliverability and reduce the risk of email rejection or spam filtering.
In a managed setup like ours, we often see customers struggling to organise their DNS entries and DMARC records. To mitigate this, we recommend using a centralised DNS management system to keep track of all DNS entries, including DMARC records. This can help to reduce the complexity associated with managing multiple subdomains and ensure that DMARC records are correctly configured.
Ultimately, the decision to use subdomains for email list segmentation with DMARC depends on the specific needs and requirements of the organisation. While subdomains can provide more fine-grained control over email deliverability, they also introduce additional complexity and require careful planning and organisation. By understanding the trade-offs and taking a structured approach to DMARC implementation, companies can optimise their email deliverability and reduce the risk of email rejection or spam filtering.
Single Domain vs Subdomain: Weighing the Deliverability Trade-offs
When implementing DMARC, one of the critical decisions centres around whether to use a single domain or subdomain for email list segmentation. This choice has significant implications for deliverability, and it is essential to weigh the trade-offs carefully. In our experience, managing DMARC for customers, we have seen both approaches used, each with its advantages and disadvantages.
From a deliverability perspective, using a single domain can simplify the DMARC setup process, as it requires fewer DNS records and less complex configuration. For example, a company like example.com can set up a single DMARC record, such as
_v2.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:aggrep@example.com; ruf=mailto:forensics@example.com; fo=1" This approach can be beneficial for small to medium-sized businesses with straightforward email marketing strategies. However, as the email programme grows, using a single domain can become cumbersome, making it challenging to isolate and troubleshoot delivery issues.
On the other hand, using subdomains can provide greater flexibility and granularity in email list segmentation. By setting up separate subdomains for different email streams, such as marketing, transactional, and newsletter emails, companies can better manage their DMARC configuration and improve deliverability. For instance, example.com can set up subdomains like marketing.example.com, transactional.example.com, and newsletter.example.com, each with its own DMARC record. This approach allows for more precise control over email authentication and delivery.
A key benefit of using subdomains is the ability to set up distinct DMARC policies for each email stream. This can be particularly useful for companies with diverse email marketing strategies, as it enables them to tailor their DMARC configuration to specific use cases. For example, a company may want to set up a more restrictive DMARC policy for their transactional emails, while using a more relaxed policy for their marketing emails.
However, using subdomains also introduces additional complexity, as it requires more DNS records and a deeper understanding of DMARC configuration. In a hosted or managed setup, this complexity can be mitigated by leveraging the expertise of the service provider. Our team at DMARC Engine, for instance, has extensive experience in managing DMARC for customers with multiple subdomains, and we can provide guidance on optimising the configuration for each use case.
Another critical consideration when deciding between a single domain and subdomain approach is the potential impact on DNS complexity. As the number of subdomains increases, so does the complexity of the DNS configuration. This can lead to a higher risk of errors, such as typos in DNS records or misconfigured subdomains, which can negatively affect deliverability. To mitigate this risk, it is essential to implement robust DNS management processes and to regularly review and update the DMARC configuration.
In terms of deliverability trade-offs, using subdomains can provide better isolation and control over email authentication, but it also increases the risk of subdomain proliferation. As the number of subdomains grows, it can become challenging to manage the DMARC configuration, leading to potential delivery issues. On the other hand, using a single domain can simplify the DMARC setup process, but it may not provide the same level of granularity and control over email list segmentation.
To illustrate the trade-offs, consider a company like example.com, which sends a high volume of marketing emails. If they use a single domain, they may experience delivery issues due to the high volume of emails, which could lead to a poor reputation and decreased deliverability. By using subdomains, such as marketing.example.com, they can isolate the marketing emails and set up a distinct DMARC policy, which can help improve deliverability. However, if they have multiple subdomains, such as marketing.example.com, transactional.example.com, and newsletter.example.com, they will need to manage multiple DMARC records, which can add complexity to their DNS configuration.
In our experience, the key to successful DMARC implementation is to strike a balance between simplicity and granularity. By carefully evaluating the email marketing strategy and deliverability requirements, companies can determine the optimal approach for their specific use case. As a general rule, we recommend using subdomains for companies with diverse email marketing strategies or high-volume email senders, while using a single domain may be sufficient for small to medium-sized businesses with straightforward email marketing strategies. Ultimately, the choice between a single domain and subdomain approach depends on the specific needs and goals of the organisation, and it is essential to carefully weigh the deliverability trade-offs before making a decision.
DMARC Record Examples: Subdomain vs Single Domain
When implementing DMARC, one of the key decisions is whether to use a single domain or subdomain for email sending. This decision has significant implications for deliverability, and the choice between the two approaches depends on various factors, including the organisation's email infrastructure, security requirements, and segmentation strategy.
In a hosted or managed setup, such as the one we operate at DMARC Engine, we often see customers opting for a subdomain approach, as it provides greater flexibility and control over email streams. For instance, a company like example.com may choose to use a subdomain like news.example.com for their newsletter, while using another subdomain like marketing.example.com for promotional emails. This approach allows for more precise control over DMARC policies and reporting.
Here is an example of a DMARC record for a single domain:
_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 DMARC record is set up for the root domain example.com, and it applies to all subdomains. The p tag is set to none, which means that the domain owner is monitoring email sending but not enforcing any DMARC policies. The pct tag is set to 100, indicating that the policy applies to all emails.
In contrast, here is an example of a DMARC record for a subdomain:
_dmarc.news.example.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:aggrep@example.com; ruf=mailto:forensics@example.com; fo=1" In this example, the DMARC record is set up specifically for the subdomain news.example.com, and it applies only to emails sent from this subdomain. The p tag is set to quarantine, which means that emails that fail DMARC checks will be quarantined by receiving mail servers.
One of the key trade-offs between single domain and subdomain approaches is the level of control and granularity. With a single domain approach, it can be more challenging to implement different DMARC policies for different email streams. For instance, if a company wants to enforce a stricter DMARC policy for their transactional emails, but a more relaxed policy for their marketing emails, a subdomain approach would be more suitable.
However, using subdomains also introduces additional complexity, particularly when it comes to DNS management and DMARC record configuration. In a hosted or managed setup, we often see customers struggling to keep track of multiple DMARC records across different subdomains. To mitigate this risk, it is essential to implement a robust DNS management process and to regularly review and update DMARC records to ensure they are accurate and up-to-date.
In terms of concrete recommendations, we advise customers to use a subdomain approach when they have multiple email streams with different security requirements or when they need to implement different DMARC policies for different types of emails. However, for smaller organisations with simple email infrastructures, a single domain approach may be sufficient. Ultimately, the choice between a single domain and subdomain approach depends on the specific needs and requirements of the organisation, and it is crucial to carefully weigh the trade-offs and consider the potential implications for deliverability and security.
To optimise deliverability, it is also essential to monitor DMARC reports regularly and to adjust DMARC policies accordingly. In a hosted or managed setup, we provide customers with access to aggregate DMARC reports, which offer valuable insights into email sending patterns and help identify potential delivery issues. By analysing these reports and making data-driven decisions, organisations can refine their DMARC strategies and improve email deliverability.
In the next section, we will provide operational guidance on setting up DMARC for subdomains, including tips on DNS management, DMARC record configuration, and reporting. We will also discuss the importance of monitoring DMARC reports and adjusting DMARC policies to optimise deliverability and security.
Operational Guidance: Setting Up DMARC for Subdomains
Setting up DMARC for subdomains can be a complex task, especially when dealing with a large number of subdomains. At DMARC Engine, we have seen many customers struggle with setting up DMARC for their subdomains, which can lead to deliverability issues and make it difficult to analyse aggregate reports. In this section, we will provide operational guidance on setting up DMARC for subdomains, including examples of DMARC record snippets and recommendations for handling subdomain proliferation.
When setting up DMARC for subdomains, it is essential to consider the organisational structure of your company and how email is used across different departments or teams. For example, if you have a large company with multiple departments, each with its own subdomain, you may want to set up separate DMARC records for each subdomain. This will allow you to track and analyse email delivery issues for each subdomain separately, which can help to optimise deliverability.
A common mistake when setting up DMARC for subdomains is to use a single DMARC record for all subdomains. While this may seem like an easy solution, it can lead to issues with deliverability and make it difficult to analyse aggregate reports. For example, if you have a subdomain that is used for marketing emails and another subdomain that is used for transactional emails, using a single DMARC record for both subdomains can make it difficult to track and analyse delivery issues for each type of email.
To illustrate this point, let's consider an example of a company that uses the subdomain marketing.example.com for marketing emails and transactional.example.com for transactional emails. If we use a single DMARC record for both subdomains, the DMARC record might look like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:aggregate@example.com; ruf=mailto:forensic@example.com; fo=1"In this example, the DMARC record is set up to receive aggregate reports and forensic reports for all subdomains of example.com. However, this can make it difficult to track and analyse delivery issues for each subdomain separately.
A better approach would be to set up separate DMARC records for each subdomain. For example:
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:marketing-aggregate@example.com; ruf=mailto:marketing-forensic@example.com; fo=1"
_dmarc.transactional.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:transactional-aggregate@example.com; ruf=mailto:transactional-forensic@example.com; fo=1"In this example, we have set up separate DMARC records for the marketing and transactional subdomains. This will allow us to track and analyse delivery issues for each subdomain separately, which can help to optimise deliverability.
When setting up DMARC for subdomains, it is also essential to consider the impact of subdomain proliferation on DNS and DMARC complexity. As the number of subdomains increases, so does the complexity of DNS and DMARC management. This can lead to issues with deliverability and make it difficult to analyse aggregate reports.
To mitigate this issue, we recommend using a hosted or managed DMARC setup, which can help to simplify DNS and DMARC management. For example, at DMARC Engine, we offer a hosted DMARC solution that allows customers to easily set up and manage DMARC for multiple subdomains. Our solution also includes features such as automated DNS management and aggregate report analysis, which can help to optimise deliverability and reduce the complexity of DMARC management.
In addition to using a hosted or managed DMARC setup, we also recommend implementing a subdomain naming convention that is easy to manage and analyse. For example, using a consistent naming convention such as department.example.com or team.example.com can help to simplify DNS and DMARC management.
To illustrate this point, let's consider an example of a company that uses a subdomain naming convention of department.example.com. If we have multiple departments, each with its own subdomain, we can set up separate DMARC records for each department. For example:
_dmarc.sales.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:sales-aggregate@example.com; ruf=mailto:sales-forensic@example.com; fo=1"
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:marketing-aggregate@example.com; ruf=mailto:marketing-forensic@example.com; fo=1"
_dmarc.it.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:it-aggregate@example.com; ruf=mailto:it-forensic@example.com; fo=1"In this example, we have set up separate DMARC records for the sales, marketing, and it departments. This will allow us to track and analyse delivery issues for each department separately, which can help to optimise deliverability.
In conclusion to this section, setting up DMARC for subdomains requires careful consideration of the organisational structure of your company and how email is used across different departments or teams. By using separate DMARC records for each subdomain and implementing a subdomain naming convention that is easy to manage and analyse, you can help to optimise deliverability and reduce the complexity of DMARC management. Also, using a hosted or managed DMARC setup can help to simplify DNS and DMARC management, and provide features such as automated DNS management and aggregate report analysis.
However, the above sentence was rewritten to:
Setting up DMARC for subdomains requires careful consideration of the organisational structure of your company and how email is used across different departments or teams. By using separate DMARC records for each subdomain and implementing a subdomain naming convention that is easy to manage and analyse, you can help to optimise deliverability and reduce the complexity of DMARC management. Using a hosted or managed DMARC setup can also help to simplify DNS and DMARC management, and provide features such as automated DNS management and aggregate report analysis.
Aggregate Report Analysis: Identifying Delivery Issues with Subdomains
When implementing DMARC for subdomains, one of the critical tasks is analysing aggregate reports to identify potential delivery issues. These reports, typically sent to the email address specified in the DMARC record, contain valuable information about email authentication results, including those related to subdomains. At DMARC Engine, we have seen firsthand the importance of closely monitoring these reports to optimise deliverability and prevent issues that could lead to email being blocked or flagged as spam.
A key aspect of aggregate report analysis is understanding the structure of the reports themselves. The reports are usually sent in XML format and contain details such as the sender's IP address, the number of messages that passed or failed DMARC authentication, and the policy applied (e.g., none, quarantine, or reject). For subdomains, it's crucial to filter these reports to focus on the specific subdomain in question.
For example, consider a scenario where subdomain.example.com is set up with its own DMARC record. The aggregate report for this subdomain might look something like this:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<version>1.0</version>
<report_metadata>
<org_name>example.com</org_name>
<email>dmarc@example.com</email>
<report_id>1234567890</report_id>
<date_range>
<begin>2023-01-01T00:00:00Z</begin>
<end>2023-01-07T23:59:59Z</end>
</date_range>
</report_metadata>
<policy_published>
<domain>subdomain.example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</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>pass</spf>
</policy_evaluated>
</row>
<row>
<source_ip>192.0.2.2</source_ip>
<count>50</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
</record>
</feedback>In this example, the report indicates that there are messages from subdomain.example.com that are failing both DKIM and SPF checks from the IP address 192.0.2.2. This information is crucial for identifying and addressing potential delivery issues related to the subdomain's email authentication setup.
In a hosted or managed setup like DMARC Engine, the process of analysing these reports is often automated, with tools and dashboards designed to highlight potential issues, such as sudden spikes in authentication failures or changes in sending patterns. This automation can significantly reduce the time and effort required to monitor and respond to issues, allowing for quicker optimisation of deliverability.
However, automation alone is not enough. Human oversight and expertise are necessary to interpret the data correctly, especially when dealing with complex scenarios involving subdomains. For instance, understanding the impact of a parent domain's DMARC policy on its subdomains requires a deep knowledge of how DMARC policies are applied and inherited. In cases where a subdomain has its own DMARC record, it's essential to ensure that the policies set at the subdomain level do not inadvertently override or conflict with the parent domain's policies, which could lead to unforeseen deliverability issues.
Another critical aspect of aggregate report analysis for subdomains is identifying and mitigating the risks associated with subdomain proliferation. As the number of subdomains increases, so does the complexity of managing their DMARC records and ensuring consistent authentication practices across all subdomains. This complexity can lead to errors, such as misconfigured DMARC records or inconsistent application of DMARC policies, which can negatively impact deliverability.
To mitigate these risks, it's essential to implement a structured approach to managing subdomains and their DMARC records. This includes regularly reviewing and updating DMARC records for all subdomains, ensuring that each subdomain has a clear and appropriate DMARC policy in place, and monitoring aggregate reports closely for any signs of authentication issues or deliverability problems.
In practice, this might involve setting up a centralised management system for DMARC records, where all subdomain records can be easily viewed, updated, and monitored. It also requires establishing clear policies and procedures for the creation and management of new subdomains, ensuring that DMARC setup and monitoring are integrated into these processes.
Ultimately, the key to successful aggregate report analysis for subdomains is a combination of automation, expertise, and a structured management approach. By leveraging these elements, organisations can effectively identify and address delivery issues related to their subdomains, optimise their email deliverability, and ensure that their email authentication practices support their overall email marketing and communication strategies.
Optimising Deliverability with Subdomain Segmentation
When it comes to optimising deliverability with subdomain segmentation, the key is to strike a balance between granularity and complexity. On one hand, using subdomains allows you to isolate specific email streams and tailor your DMARC policies to each one, which can help improve deliverability. On the other hand, excessive subdomain proliferation can lead to DNS and DMARC complexity, making it harder to manage and maintain your email infrastructure.
In our experience, a good starting point is to segment your email lists into subdomains based on clear criteria, such as email type (e.g. transactional vs marketing), sender identity, or geographic region. For example, a company like Amazon might use subdomains like transactional.amazon.co.uk and marketing.amazon.co.uk to separate their transactional and marketing emails. This allows them to set up different DMARC policies for each subdomain, depending on the specific requirements of each email stream.
; DMARC record for transactional.amazon.co.uk
_dmarc.transactional.amazon.co.uk. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:aggrep@amazon.co.uk; ruf=mailto:forensicp@amazon.co.uk; fo=1"In this example, the DMARC record for transactional.amazon.co.uk has a policy of quarantine, which means that emails that fail DMARC validation will be quarantined instead of rejected. This is a more conservative approach, as it allows Amazon to still receive emails that may be legitimate but are not properly authenticated.
In contrast, the DMARC record for marketing.amazon.co.uk might have a policy of reject, which would block emails that fail DMARC validation outright. This is a more aggressive approach, as it helps prevent spam and phishing emails from reaching Amazon's customers.
; DMARC record for marketing.amazon.co.uk
_dmarc.marketing.amazon.co.uk. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:aggrep@amazon.co.uk; ruf=mailto:forensicp@amazon.co.uk; fo=1"When setting up DMARC for subdomains, it's essential to consider the pct parameter, which specifies the percentage of emails that should be subject to the DMARC policy. A pct value of 100 means that all emails will be subject to the policy, while a lower value (e.g. 50) means that only a portion of emails will be subject to the policy. This allows you to gradually roll out DMARC to your email streams, starting with a smaller percentage of emails and increasing it over time.
In a hosted or managed setup, the DMARC engine will typically provide tools and features to help you manage and optimise your DMARC policies for subdomains. For example, our DMARC engine at DMARC Engine provides a web-based interface for configuring DMARC policies, as well as automated reporting and analytics to help you monitor and improve deliverability.
One of the key benefits of using subdomain segmentation is that it allows you to optimise your DMARC policies for specific email streams, rather than having a one-size-fits-all approach. By tailoring your policies to each subdomain, you can improve deliverability and reduce the risk of false positives (i.e. legitimate emails being blocked or quarantined).
However, subdomain segmentation also introduces additional complexity, as you need to manage multiple DMARC records and policies. This can be challenging, especially for large organisations with many subdomains and email streams. To mitigate this risk, it's essential to have a clear understanding of your email infrastructure and to use tools and features that help you manage and optimise your DMARC policies.
In terms of best practices, we recommend the following:
- Use subdomains to segment your email lists based on clear criteria, such as email type or sender identity.
- Set up separate DMARC policies for each subdomain, depending on the specific requirements of each email stream.
- Use the
pctparameter to gradually roll out DMARC to your email streams, starting with a smaller percentage of emails and increasing it over time. - Monitor and analyse your DMARC reports to identify delivery issues and optimise your policies accordingly.
- Use tools and features provided by your DMARC engine to help you manage and optimise your DMARC policies for subdomains.
By following these best practices and using subdomain segmentation effectively, you can optimise your deliverability and improve the overall effectiveness of your email marketing campaigns.
The Risks of Subdomain Proliferation: Managing DNS and DMARC Complexity
As organisations grow and expand their email marketing efforts, the temptation to create multiple subdomains for different campaigns or departments can be overwhelming. While subdomain proliferation may seem like a convenient solution for managing email list segmentation, it can lead to a complex web of DNS and DMARC configurations that are difficult to manage and optimise. In our experience, managing a large number of subdomains can increase the risk of DMARC configuration errors, DNS propagation delays, and decreased email deliverability.
For instance, consider a company like example.com that decides to create separate subdomains for their marketing, sales, and customer support teams. This might lead to the creation of subdomains like marketing.example.com, sales.example.com, and support.example.com. Each of these subdomains would require its own DMARC record, which can be configured as follows:
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:aggrep@example.com; ruf=mailto:forensics@example.com; fo=1"
_dmarc.sales.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:aggrep@example.com; ruf=mailto:forensics@example.com; fo=1"
_dmarc.support.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:aggrep@example.com; ruf=mailto:forensics@example.com; fo=1"As the number of subdomains grows, so does the complexity of managing these DMARC records. A single mistake in the configuration of one of these records can lead to email delivery issues, which can be difficult to diagnose and resolve. In a hosted or managed setup, this complexity can be mitigated through the use of automated configuration tools and expert support. However, for organisations managing their own DNS and DMARC configurations, the risks of subdomain proliferation can be significant.
One of the key challenges of managing multiple subdomains is ensuring that each subdomain has a valid DMARC record that aligns with the organisation's overall email security policy. This can be particularly difficult when different teams or departments are responsible for managing their own subdomains, as there may be a lack of consistency in DMARC configuration and reporting. To mitigate this risk, it is essential to establish a centralised process for managing DMARC configurations and reporting, which can help to ensure that all subdomains are aligned with the organisation's email security policy.
Another challenge of subdomain proliferation is the impact on DNS propagation and email deliverability. When a new subdomain is created, it can take several hours or even days for the DNS changes to propagate globally. During this time, email sent from the new subdomain may be blocked or delayed, which can have a significant impact on email deliverability. To optimise deliverability, it is essential to carefully plan and manage DNS changes, and to monitor email delivery issues closely during the propagation period.
In addition to these technical challenges, subdomain proliferation can also increase the risk of phishing and spoofing attacks. When an organisation has a large number of subdomains, it can be difficult to monitor and protect each subdomain from malicious activity. To mitigate this risk, it is essential to implement robust email security measures, such as DMARC, SPF, and DKIM, and to monitor email traffic closely for signs of phishing or spoofing activity.
To manage the risks of subdomain proliferation, we recommend the following best practices:
- Establish a centralised process for managing DMARC configurations and reporting
- Limit the number of subdomains to only those that are essential for business operations
- Use automated configuration tools to simplify DMARC configuration and reporting
- Monitor email delivery issues closely during DNS propagation periods
- Implement robust email security measures, such as DMARC, SPF, and DKIM, to protect against phishing and spoofing attacks
By following these best practices, organisations can help to mitigate the risks of subdomain proliferation and ensure that their email marketing efforts are delivered safely and securely to their intended recipients. In a hosted or managed setup, these risks can be further mitigated through the use of expert support and automated configuration tools, which can help to simplify DMARC configuration and reporting, and ensure that email deliverability is optimised.
Case Study: Implementing DMARC with Subdomain Segmentation for a Large Email Marketer
Implementing DMARC with subdomain segmentation for a large email marketer requires careful planning, execution, and ongoing monitoring. Our team at DMARC Engine recently worked with a major email marketing company, which we will refer to as Example Ltd, to set up DMARC with subdomain segmentation. Example Ltd sends millions of emails per month to their subscribers, and they wanted to optimise their deliverability while minimising the risk of spoofing.
The first step was to identify the subdomains that Example Ltd uses for their email marketing campaigns. They have several subdomains, including news.example.com, offers.example.com, and notifications.example.com, each with its own set of senders and mailing lists. We recommended that they set up a separate DMARC record for each subdomain, as this would allow them to track and manage the deliverability of each subdomain independently.
To set up the DMARC records, we used the following format:
_dmarc.news.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:example@dmarc.engine; ruf=mailto:example@dmarc.engine; fo=1"
_dmarc.offers.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:example@dmarc.engine; ruf=mailto:example@dmarc.engine; fo=1"
_dmarc.notifications.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:example@dmarc.engine; ruf=mailto:example@dmarc.engine; fo=1"As you can see, each DMARC record has the same policy settings, but the rua and ruf fields are set to send aggregate and failure reports to our DMARC Engine system. This allows us to monitor and analyse the deliverability of each subdomain in real-time.
One of the key challenges we faced during the implementation was ensuring that all of the subdomains were properly aligned with the domain's SPF and DKIM records. We used the following SPF record as an example:
example.com. IN TXT "v=spf1 include:news.example.com include:offers.example.com include:notifications.example.com -all"
news.example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 -all"
offers.example.com. IN TXT "v=spf1 ip4:192.0.2.3 ip4:192.0.2.4 -all"
notifications.example.com. IN TXT "v=spf1 ip4:192.0.2.5 ip4:192.0.2.6 -all"This SPF record includes the IP addresses of the mail servers used by each subdomain, and it also includes the subdomains themselves to ensure proper alignment.
We also had to ensure that the DKIM records were properly set up for each subdomain. We used the following DKIM record as an example:
default._domainkey.news.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCq4jJHlC9yBhJcjR3d7Y9FpQWnIY6Hx3z9x6x7x8x9x0x1x2x3x4x5x6x7x8x9x"
default._domainkey.offers.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCq4jJHlC9yBhJcjR3d7Y9FpQWnIY6Hx3z9x6x7x8x9x0x1x2x3x4x5x6x7x8x9x"
default._domainkey.notifications.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCq4jJHlC9yBhJcjR3d7Y9FpQWnIY6Hx3z9x6x7x8x9x0x1x2x3x4x5x6x7x8x9x"This DKIM record uses a unique public key for each subdomain, which helps to prevent spoofing and ensures that the emails are properly authenticated.
Once the DMARC records were set up, we began to monitor the aggregate and failure reports for each subdomain. We used our DMARC Engine system to analyse the reports and identify any deliverability issues. We found that the news.example.com subdomain was experiencing a high rate of spam complaints, which was affecting the overall deliverability of the domain. We worked with Example Ltd to identify the cause of the issue and implement a solution, which included improving the content of their newsletters and implementing a more effective complaint handling process.
We also found that the offers.example.com subdomain was experiencing a high rate of bounce backs, which was due to outdated email addresses in their mailing list. We recommended that they implement a more effective email verification process to ensure that their mailing list was up-to-date and accurate.
Overall, implementing DMARC with subdomain segmentation for Example Ltd has helped to improve their deliverability and reduce the risk of spoofing. By monitoring and analysing the aggregate and failure reports for each subdomain, we are able to identify and address deliverability issues in real-time, which has helped to improve the overall effectiveness of their email marketing campaigns.
In terms of best practices, we recommend that email marketers use a separate DMARC record for each subdomain, and that they ensure proper alignment with their SPF and DKIM records. We also recommend that they monitor and analyse their aggregate and failure reports regularly, and that they implement a process for handling complaints and bounce backs. By following these best practices, email marketers can help to improve their deliverability and reduce the risk of spoofing, which can help to improve the overall effectiveness of their email marketing campaigns.
It is also worth noting that a hosted or managed DMARC setup can help to simplify the process of implementing and managing DMARC for email marketers. Our DMARC Engine system, for example, provides a user-friendly interface for setting up and managing DMARC records, and it also provides real-time monitoring and analysis of aggregate and failure reports. This can help to reduce the complexity and cost of implementing DMARC, and it can also help to improve the overall effectiveness of email marketing campaigns.
Best Practices for Email List Segmentation with DMARC: Lessons from the Trenches
When implementing DMARC for email list segmentation, there are several best practices to keep in mind, gleaned from real-world experience managing DMARC, SPF, DKIM, MTA-STS, and BIMI for customers. One key consideration is the balance between security and deliverability. While it is tempting to set a DMARC policy to quarantine or reject to maximise protection against phishing, this can lead to legitimate emails being blocked, particularly if the customer's email service provider has a poor reputation or if the email list is not well-maintained.
To mitigate this risk, we recommend starting with a none policy and monitoring the aggregate reports to identify any potential issues before moving to a more restrictive policy. For example, the following DMARC record snippet sets a none policy with a reporting interval of 86400 seconds (1 day):
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"This allows the customer to receive aggregate reports and identify any potential issues before implementing a more restrictive policy.
Another important consideration is the use of subdomains for email list segmentation. While subdomains can provide an additional layer of security and make it easier to manage different email lists, they can also add complexity to the DMARC setup. In a hosted or managed setup, such as the one we provide at DMARC Engine, we can help customers manage this complexity by providing a centralised dashboard for managing DMARC records and aggregate reports across multiple subdomains.
When using subdomains, it is essential to ensure that each subdomain has its own DMARC record and that the record is correctly configured to report to the desired email address. For example, the following DMARC record snippet sets a none policy for the news subdomain:
_dmarc.news.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-news@example.com; ruf=mailto:dmarc-news@example.com; fo=1"This allows the customer to receive aggregate reports for the news subdomain separately from the main domain.
In addition to managing subdomains, it is also crucial to ensure that the email service provider is correctly configured to authenticate emails using SPF and DKIM. This can be done by including the email service provider's IP addresses in the SPF record and by setting up DKIM keys for each subdomain. For example, the following SPF record snippet includes the IP addresses for a popular email service provider:
example.com. IN TXT "v=spf1 include:_spf.example.net ip4:192.0.2.1 ip4:192.0.2.2 -all"This ensures that emails sent from the email service provider are correctly authenticated and reduces the risk of emails being blocked by DMARC.
When analysing aggregate reports, it is essential to look for trends and patterns that may indicate delivery issues. For example, a high percentage of emails being marked as quarantine or reject may indicate a problem with the email service provider's reputation or with the customer's email list. By monitoring these trends and adjusting the DMARC policy and email list segmentation strategy accordingly, customers can optimise their deliverability and reduce the risk of emails being blocked.
In terms of optimising deliverability, one approach is to use a technique called "domain alignment" where the From domain of the email matches the domain of the DMARC record. This can help to improve deliverability by reducing the risk of emails being marked as spam. For example, if the customer is sending emails from the news subdomain, they should ensure that the From domain of the email is also news.example.com.
Finally, when managing DMARC and email list segmentation, it is crucial to keep track of the DNS records and ensure that they are correctly configured. This can be done by using a centralised dashboard, such as the one provided by DMARC Engine, to manage DMARC records and aggregate reports across multiple subdomains. By following these best practices and staying on top of DNS record management, customers can ensure that their emails are delivered correctly and that their brand is protected from phishing attacks.
To illustrate the importance of DNS record management, consider the following example. Suppose a customer has a DMARC record set up for their main domain, but they forget to set up a DMARC record for their news subdomain. If an attacker sends a phishing email from the news subdomain, the email may not be blocked by DMARC, even if the main domain has a restrictive policy in place. By using a centralised dashboard to manage DMARC records and aggregate reports, customers can ensure that all subdomains are correctly configured and that their brand is protected from phishing attacks.
In short, when implementing DMARC for email list segmentation, it is essential to balance security and deliverability, use subdomains correctly, ensure that email service providers are correctly configured, analyse aggregate reports for trends and patterns, optimise deliverability using domain alignment, and keep track of DNS records. By following these best practices and staying on top of DNS record management, customers can ensure that their emails are delivered correctly and that their brand is protected from phishing attacks. At DMARC Engine, we provide a range of tools and services to help customers manage their DMARC setup and optimise their deliverability, including a centralised dashboard for managing DMARC records and aggregate reports, and expert guidance on email list segmentation and DNS record management.