10 October 2026 · DMARC Engine · 14 min read
The Challenge of DMARC Monitoring at Scale
Large-scale senders face a unique set of challenges when it comes to DMARC monitoring, primarily due to the sheer volume of emails being sent and the complexity of their infrastructure. One of the main issues is handling the vast amount of data generated by aggregate reports, which can quickly become overwhelming. For instance, a single report from a major ISP can contain thousands of lines of data, making it difficult to pinpoint specific issues.
<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>In this example, the report indicates that 100 emails from the IP address 192.0.2.1 failed both DKIM and SPF checks, but were still delivered due to a policy of none. This highlights the need for effective monitoring and analysis tools to quickly identify and remediate issues.
A hosted or managed DMARC setup can help alleviate some of these challenges by providing automated report processing and analysis, as well as expert guidance on record configuration and optimisation. However, even with these benefits, large-scale senders must still carefully consider their DMARC record configuration to ensure it is optimised for their specific use case.
For example, setting a policy that is too strict can lead to legitimate emails being blocked, while a policy that is too lenient can leave the sender vulnerable to spoofing attacks. Finding the right balance is crucial, and requires careful monitoring and analysis of DMARC reports.
In addition, large-scale senders must also contend with the issue of subnet diversity, where emails are sent from a large range of IP addresses. This can make it difficult to maintain an accurate SPF record, and may require the use of techniques such as IP address aggregation or third-party SPF management services.
Ultimately, effective DMARC monitoring at scale requires a combination of technical expertise, automated tools, and careful planning to ensure that the sender's DMARC records are correctly configured and optimised for their specific use case. By prioritising DMARC monitoring and analysis, large-scale senders can help protect their brand and reputation, and ensure that their emails are delivered safely and securely.
Setting Up DMARC Monitoring: Key Considerations
When setting up DMARC monitoring for large-scale senders, there are several key considerations to keep in mind to ensure effective monitoring and to avoid common pitfalls. One of the most critical decisions is choosing the correct DMARC policy, as this will directly impact the level of protection and the volume of reports received. For example, a policy of p=none will provide monitoring only, without blocking any emails, whereas a policy of p=quarantine or p=reject will instruct receiving mail servers to take action on emails that fail DMARC validation.
A key trade-off to consider is the balance between protection and deliverability. A strict policy may provide better protection against phishing attacks, but may also lead to legitimate emails being blocked. On the other hand, a more relaxed policy may allow more spam to reach the inbox, but will also reduce the risk of false positives. In a hosted or managed setup, such as the one provided by DMARC Engine, this balance can be optimised through the use of advanced reporting and analytics tools, which provide detailed insights into email traffic and help to identify potential issues before they become major problems.
Another important consideration is the configuration of the DMARC record itself. The record should include the correct policy, as well as the email address or URL where aggregate reports will be sent. For example:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"In this example, the DMARC record specifies a policy of p=none, with aggregate reports being sent to dmarc@example.com. The pct=100 tag specifies that the policy should be applied to 100% of emails, and the fo=1 tag specifies that failure reports should be sent in a formatted manner.
When setting up DMARC monitoring, it is also essential to consider the impact of subdomains. If a domain has multiple subdomains, each subdomain should have its own DMARC record, to ensure that emails sent from each subdomain are properly authenticated. In a hosted or managed setup, this can be handled automatically, with the provider configuring DMARC records for each subdomain as needed.
In addition to the technical considerations, it is also important to consider the organisational and procedural aspects of DMARC monitoring. This includes ensuring that the email address or URL specified in the DMARC record is monitored regularly, and that any issues or problems identified through the reports are addressed promptly. This may involve setting up a centre of excellence for email security, with a dedicated team responsible for monitoring and responding to DMARC reports.
By carefully considering these key factors, large-scale senders can set up effective DMARC monitoring, which will help to protect their brand and reputation, and optimise their email deliverability. In the next section, we will take a deep dive into aggregate report analysis, and explore the insights and benefits that can be gained from these reports.
Aggregate Report Analysis: A Deep Dive
When analysing aggregate reports, it is crucial to centre your attention on the XML records that contain the actual data, rather than the email headers or body. The XML structure of these reports provides a colour-coded overview of the authentication results, which can be overwhelming at first glance. For instance, a report may contain multiple record elements, each representing a distinct authentication event.
<feedback>
<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>
</record>
<record>
<row>
<source_ip>198.51.100.1</source_ip>
<count>5</count>
<policy_evaluated>
<disposition>quarantine</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>
</feedback>In this example, the report indicates that there were 10 authentication failures from the IP address 192.0.2.1 and 5 successful authentications from 198.51.100.1. To optimise the analysis process, it is essential to organise these records by source IP address, disposition, and authentication results. This will enable you to identify trends and patterns that may indicate potential issues with your DMARC setup.
A common pitfall when analysing aggregate reports is to focus solely on the overall authentication rate, rather than examining the individual records in detail. This can lead to a false sense of security, as a high overall authentication rate may mask specific issues with certain source IP addresses or authentication mechanisms. For example, a report may indicate an overall authentication rate of 90%, but upon closer inspection, you may discover that a specific IP address is responsible for a large number of authentication failures.
In a hosted or managed DMARC setup, the analysis process is often automated, with the provider handling the organisation and filtering of aggregate reports. However, it is still crucial for the sender to understand the underlying data and to be able to interpret the reports effectively. This may involve working closely with the provider to configure the reporting settings and to ensure that the data is being accurately collected and analysed.
When analysing aggregate reports, it is also important to consider the trade-offs between different authentication mechanisms. For instance, a strict DMARC policy may result in a higher rate of false positives, where legitimate emails are incorrectly flagged as spam. On the other hand, a more relaxed policy may increase the risk of phishing attacks. To mitigate this risk, it is essential to carefully evaluate the authentication results and to adjust the DMARC policy accordingly.
In addition to analysing the authentication results, it is also crucial to monitor the reporting settings and to ensure that the aggregate reports are being correctly generated and sent to the designated email address. This may involve verifying the DNS settings, checking the email headers, and testing the reporting mechanism to ensure that it is functioning correctly.
To illustrate this point, consider the following example of a DMARC record that is correctly configured to generate aggregate reports:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-aggregate@example.com; ruf=mailto:dmarc-failure@example.com; fo=1"In this example, the rua parameter specifies the email address where the aggregate reports should be sent, while the ruf parameter specifies the email address where the failure reports should be sent. The fo parameter is set to 1, which indicates that failure reports should be generated for all authentication failures.
By carefully analysing the aggregate reports and adjusting the DMARC policy accordingly, large-scale senders can optimise their DMARC monitoring and improve the overall deliverability of their emails. This may involve working closely with a hosted or managed DMARC provider to configure the reporting settings and to ensure that the data is being accurately collected and analysed. Ultimately, the key to effective DMARC monitoring is to centre your attention on the details, rather than relying on high-level metrics or automated reporting tools.
Operational Guidance: Configuring DMARC Records
When configuring DMARC records for large-scale senders, it is crucial to centre your approach around the specific needs of your organisation, taking into account the colour of your brand and the potential impact on your email deliverability. A key decision is the choice of policy, with options ranging from none to quarantine or reject. For instance, a company like Barclays may choose a reject policy to optimise their email security, as seen in the following DMARC record snippet:
_dmarc.barclays.co.uk. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-aggregate@barclays.co.uk; ruf=mailto:dmarc-failure@barclays.co.uk; fo=1"In a hosted or managed setup, such as the one we use at DMARC Engine, the configuration of DMARC records is often automated, with the system generating the necessary records based on the customer's domain and policy preferences. However, it is still essential to understand the underlying configuration to ensure that it aligns with your organisation's needs.
Another critical aspect of DMARC record configuration is the alignment of SPF and DKIM with the domain's DMARC policy. For example, if a domain has a DMARC record with a reject policy, it is vital to ensure that the SPF and DKIM records are correctly configured to avoid false positives. A common pitfall is the misuse of the pct tag, which can lead to a significant portion of emails being blocked or quarantined. To avoid this, it is recommended to start with a low pct value, such as 10, and gradually increase it as the organisation becomes more comfortable with the DMARC policy.
In addition to the policy and alignment considerations, it is also important to configure the DMARC record to include the necessary reporting tags, such as rua and ruf. These tags enable the organisation to receive aggregate and failure reports, which are essential for monitoring and troubleshooting DMARC-related issues. For instance, the following DMARC record snippet includes the rua and ruf tags:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-aggregate@example.com; ruf=mailto:dmarc-failure@example.com; fo=1"By carefully configuring the DMARC record and considering the specific needs of the organisation, large-scale senders can effectively monitor and optimise their email deliverability, while also improving their overall email security posture. In our experience at DMARC Engine, a well-configured DMARC record is essential for ensuring the reliable delivery of emails and preventing spam and phishing attacks.
Common Pitfalls and Real-World Examples
When implementing DMARC monitoring, large-scale senders often encounter pitfalls that can hinder the effectiveness of their setup. One common issue is misconfigured SPF records, which can lead to authentication failures. For instance, a customer may have an SPF record that includes a third-party service, but forgets to update the record when the service's IP address changes. This can result in emails being flagged as spam or rejected by recipients.
A hosted setup like ours can help mitigate this issue by providing automated SPF record updates and alerts for changes in third-party services.
Another pitfall is not properly handling DKIM key rotation. DKIM keys should be rotated regularly to maintain security, but if not done correctly, it can cause email delivery issues.
For example, a sender may have a DKIM record like this:
DKIM1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCq4F4hM8DdDveoJ5R3X9jO6Z3jJ3J3Jj3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3j3
## Optimising DMARC Monitoring for Large-Scale Senders
To optimise DMARC monitoring for large-scale senders, it is crucial to centre your strategy around effective aggregate report analysis and record configuration. A key consideration is the `p` tag in the DMARC record, which defines the policy for handling unauthenticated emails. For instance, a record like markdown
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:aggrep@example.com; ruf=mailto:forensics@example.com; fo=1"
specifies that 100% of emails should be monitored, but no action should be taken on unauthenticated emails.
In a hosted setup, such as ours at DMARC Engine, the colour coding of the DMARC record generator can help identify potential issues, like an incorrect `p` tag value, before the record is deployed.
When optimising, large-scale senders should also consider the impact of subdomain configuration on their DMARC monitoring, as misconfigured subdomains can lead to a high volume of false negatives, and thus, unnecessary forensics reports.
To mitigate this, it is essential to organise subdomains into logical groups and apply a consistent DMARC policy across each group.
Ultimately, the goal of optimising DMARC monitoring is to strike a balance between security and deliverability, which can be achieved by carefully configuring DMARC records, effectively analysing aggregate reports, and continually refining the monitoring strategy to suit the specific needs of the organisation.
## Case Studies: Lessons Learned from DMARC Monitoring
At DMARC Engine, we have worked with numerous large-scale senders to optimise their DMARC monitoring setup. One notable example is a major online retailer that was experiencing issues with spam filters due to a high volume of unauthenticated emails being sent from their domain. Upon analysing their aggregate reports, we discovered that a significant number of emails were being sent via a third-party marketing platform that was not configured to use their domain's DMARC record.
The DMARC record in question was set up as follows:markdown
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"
We worked with the retailer to configure the marketing platform to use their domain's DMARC record, and also to set up a dedicated subdomain for marketing emails. This involved creating a new DMARC record for the subdomain, with a more restrictive policy:markdown
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"
```
By doing so, we were able to reduce the number of unauthenticated emails being sent from the retailer's domain, and improve their overall deliverability. This example highlights the importance of monitoring and analysing aggregate reports to identify potential issues with DMARC configuration.
Another common issue we encounter is the misconfiguration of SPF records. For instance, a company may have multiple SPF records set up for different subdomains, but fail to include all the necessary IP addresses in each record. This can lead to emails being flagged as spam or rejected by recipient mail servers. To avoid this, it is essential to regularly review and update SPF records to ensure they are accurate and comprehensive.
In a hosted or managed setup, such as the one provided by DMARC Engine, this process can be automated and streamlined, reducing the risk of human error. Our system, for example, allows customers to easily manage and update their SPF records, and provides alerts and notifications when potential issues are detected.
We also see cases where companies struggle to optimise their DMARC policy due to the complexity of their email infrastructure. For example, a company may have multiple email service providers, each with its own set of IP addresses and authentication mechanisms. In such cases, it is crucial to carefully evaluate the trade-offs between different policy settings, such as the percentage of emails to which the policy applies, and the action to take when an email fails authentication.
A real-world example of this is a company that had a DMARC policy set to p=none, but was still experiencing issues with spam filters due to a high volume of unauthenticated emails. After analysing their aggregate reports, we determined that the policy was not being applied to a sufficient percentage of emails, and recommended increasing the pct value to 100. This change allowed the company to better protect their domain from spam and phishing attacks, while also improving their deliverability.
In terms of best practices, we recommend that large-scale senders regularly review and update their DMARC records, and monitor their aggregate reports for potential issues. It is also essential to have a clear understanding of the company's email infrastructure, including all email service providers and their respective IP addresses and authentication mechanisms. By taking a proactive and informed approach to DMARC monitoring, companies can optimise their setup, improve their deliverability, and better protect their domain from spam and phishing attacks.
Our experience has shown that a well-configured DMARC setup, combined with regular monitoring and analysis, can significantly reduce the risk of email-based attacks, and improve the overall security and deliverability of a company's email communications.