The State of DMARC: Insights from a Large-Scale Study of the .de TLD

Analyzing Deployment Across 11.6 Million .de Domains

Michael Hudak

July 16, 2025

Introduction: Securing the Domain

Methodology: How We Analyzed 11.6 Million .de Domains

DMARC Configuration Deep Dive: Policy and Reporting

Bonus Finding: Unexpected TXT Queries to Honeypots

Conclusion

Abstract

Email faces constant threats like spoofing and phishing. To counter this, email authentication protocols like SPF and DKIM verify email origins. However, these lacked clear instructions for handling authentication failures and reporting.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) fills this gap. It builds on SPF and DKIM, ensuring sender alignment, allowing domain owners to set policies for unauthenticated emails, and providing reporting on authentication outcomes.

Our analysis of over 11.6 million .de domains revealed that 14 % have a DMARC record. Among domains with an MX record, meaning they are configured to send emails, 17 % have DMARC. However, nearly half of all domains have the policy set to none, which renders DMARC ineffective for them.

That means that only around 7 % of all domains are potentially secured against email spoofing.

Email constitutes a fundamental component of contemporary communication, serving diverse functions from business transactions and personal correspondence to marketing and information dissemination. Its widespread adoption, however, renders it a conduit for malicious activities. Email spoofing, characterized by the forgery of sender addresses, and phishing, which involves the use of deceptive emails to illicitly acquire sensitive information, represent prevailing threats that erode trust and inflict financial and reputational damage.

To counter such threats, email authentication mechanisms have been developed. Their primary function is to verify that that domain's owner authorizes an email purporting to originate from a specific domain.

SPF

Sender Policy Framework (SPF) is one such protocol, permitting domain owners to list authorized mail server IP addresses within their Domain Name System (DNS) records. Receiving mail servers can subsequently consult this list to figure out if the sending server's IP address is authorized.

DKIM

DomainKeys Identified Mail (DKIM) enables the cryptographic signing of outgoing emails. Domain owners publish a public cryptographic key in their DNS records, and sending mail servers attach a digital signature, generated with the corresponding private key, to email messages. Recipient servers can then retrieve the public key via DNS to validate the signature, thereby verifying message integrity and authenticating its origin.

DMARC

Although SPF and DKIM provide fundamental verification layers, they did not initially provide mechanisms for domain owners to issue explicit handling instructions for messages failing these authentication checks, nor did they offer standardized reporting capabilities. Domain-based Message Authentication, Reporting, and Conformance (DMARC) was developed to address these limitations. DMARC uses SPF and DKIM, introducing a requirement for identifier alignment, which ensures the domain in the visible "From" header corresponds to the domains validated by SPF and/or DKIM. Furthermore, DMARC enables domain owners to publish a policy via a DNS record, suggesting to receivers how to manage emails that fail DMARC verification, such as p=none for monitoring, p=quarantine to recommend placement in spam repositories, or p=reject to advise message rejection. DMARC also incorporates reporting mechanisms, both aggregate and forensic, which supply domain owners with feedback from recipient servers regarding messages purporting to originate from their domain, including authentication outcomes and source IP addresses. Further information about DMARC can be found in our article. We also described e-mail spoofing.

DMARC adoption is considered pertinent for contemporary organizations. It enhances defenses against domain abuse for phishing and spoofing, thereby safeguarding brand integrity and recipient security.

Notwithstanding the advantages, an understanding of the practical adoption and configuration patterns of DMARC is relevant. To elucidate this, a comprehensive, large-scale analysis was conducted, concentrating on the German top-level domain (.de). The investigation involved the examination of DNS records from over 11.6 million active .de domains to determine the prevalence of DMARC deployment, appraise the configured policies, and figure out the email authentication maturity level within a prominent country-code top-level domain.

The analysis of DMARC deployment status, even within a solitary top-level domain, represents a significant undertaking. Consequently, a methodology was devised emphasizing extensive data acquisition and rigorous analytical procedures. The present investigation concentrates exclusively on organizational domains registered under the `.de` top-level domain, specifically excluding subdomains from the analytical purview.

Data Acquisition

We aggregated domain names from multiple sources to build a comprehensive list. These included the Common Crawl URL index (specifically, version CC-MAIN-2024-30), various publicly available domain lists, and commercial domain datasets (using version current as of March 2025). We did not use .de zone files for this study, as they are generally not shared by DENIC.

The raw lists were processed to ensure quality and uniqueness. We performed domain validity checks using the Public Suffix List to filter out invalid entries and focused exclusively on organizational domains.

It's important to note that these aggregated lists may contain domains that have since expired or were never registered. Furthermore, we acknowledge the possibility that some sources might include honeypots or digital watermarks (unique domain names inserted to track list usage), although we have no direct knowledge of such inclusions in our specific source mix.

Data Collection

We used massdns, a high-performance stub resolver, renowned for its ability to handle massive numbers of DNS lookups concurrently.

We intentionally selected a low concurrency profile for massdns with the parameters hashmap-size 2, resolve-count 3, and retry never. This configuration was chosen to minimize the load on the public resolvers. Initial testing indicated that retries were extremely rare with this setup, making the retry never setting acceptable.

To ensure reliability and avoid overloading any single provider, we configured massdns to query a pool of 27 trusted, public DNS resolvers, including well-known services like Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). The queries were distributed across multiple AWS EC2 Spot instances to manage the workload effectively.

All DNS responses (including successes, timeouts, errors like NXDOMAIN, etc.) were logged in the newline-delimited JSON (ndjson) format, including metadata like Time-To-Live (TTL) values and the specific Resource Record (RR) data within the ndjson output. The complete raw dataset amounted to approximately 20 GB.

Due to the parallel nature of data collection across multiple instances, it was possible for the same domain to be queried more than once. These duplicate DNS response entries were identified and handled during the later data processing phase.

For each domain in our list, we specifically queried for the following DNS record types:

• MX (Mail Exchanger) records for the domain itself.
• TXT (Text) records for the domain itself.
• TXT records for the corresponding _dmarc subdomain (e.g., _dmarc.example.de) to retrieve the DMARC policy.

The DNS data collection occurred over a focused period between April 17th, 2025, and April 23rd, 2025. Querying for MX, and organizational TXT records took approximately 4 days, while the specific _dmarc TXT record lookups were completed in 2 days.

Data Processing

The raw ndjson data was processed using custom Python scripts. Each line (representing a JSON object for a single DNS request and response) was parsed and analyzed. The relevant information was aggregated into a structured format suitable for analysis.

Recognizing the complexities and potential variations in DMARC record syntax, we developed a dedicated Python library specifically for this project. This library was designed for robustness against parsing errors, adhering strictly to the DMARC specification outlined in RFC 7489.

For SPF records (found within TXT records at the organizational domain level), we performed targeted analysis rather than full, recursive parsing. Our scripts focused on identifying the presence of SPF records and extracting key properties, such as the all "mechanism" (~all, -all, ?all). SPF Includes were not queried, as this would require more DNS requests.

To ensure the accuracy of our collection and processing pipeline, we performed manual validation checks. A random sample of domains was selected, and their relevant DNS records (MX, TXT, _dmarc.TXT) were queried manually using the standard dig command-line tool. The results obtained via dig were compared against the data processed by our framework to confirm consistency and correctness.

Procedural considerations were made to minimize the operational burden on DNS servers during data acquisition. The datasets procured through this methodology are derived from publicly accessible records and are themselves openly available. Moreover, the management of all collected information adhered to ethical standards and data protection practices, ensuring responsible handling throughout the process.

Our findings show that only 1,627,705 domains (14.08 %) possess a valid DMARC record. 8,965,078 domains (77.57 %) have at least one MX record, suggesting a significant number of domains actively sending and receiving email.

7,405,449 domains have an MX record but no DMARC, highlighting a significant gap in protection. Interestingly, 68,076 domains have no MX record but a valid DMARC record, which, while not directly impacting email deliverability for those domains, indicates an awareness of DMARC's importance. 1,559,629 domains have both an MX record and a DMARC record, representing a more complete email setup.

A deeper look into the DMARC policies themselves reveals varied approaches. Out of the valid DMARC records, a significant portion (786,091 records or 47.05 %) are configured with a 'p=none' policy. While 'p=none' allows for valuable reporting without affecting email delivery, it doesn't actively block fraudulent emails. This contributes to the observation that only 7.65 % of all valid DMARC records are "effective" (i.e., having a policy other than 'none').

Beyond DMARC, our study also examined the broader email authentication landscape. We found that 6,342,102 domains (54.88 %) have an SPF record, indicating a good level of basic sender authentication. However, 4,776,255 domains (41.33 %) have both an MX record and an SPF record but no DMARC record, suggesting that many domains have initiated some level of email authentication but have yet to implement DMARC for comprehensive policy enforcement and reporting. Overall, 411,689 domains (3.6 %) of all analyzed domains have a valid E-Mail Auth config (SPF and DMARC without p='none'). It's also worth noting that a minimal 0.06 % of all DMARC records were found to have invalid syntax, indicating generally good adherence to syntax and formatting standards.

Beyond our primary focus on the DMARC adoption within the .de TLD, our monitoring infrastructure surfaced an intriguing secondary observation: a significant volume of DNS queries specifically targeting DMARC records on domains not actively used for email.

Observation Details

Over a one-month timeframe, we monitored DNS query logs for eight domains under our control. These domains spanned various Top-Level Domains (TLDs), including .de and .net. Despite these domains not being actively used in a way that should trigger DMARC-related lookups, we observed an average of approximately 73 TXT record requests per domain per day, specifically for the _dmarc subdomain.

Methodology

The DNS for these eight domains is managed using Amazon Web Services (AWS) Route 53. Route 53 is AWS's cloud DNS web service. We configured Route 53 to export detailed query logs to AWS CloudWatch Logs.

The collected logs capture information about each DNS query received for the hosted zones. We then ingested and parsed these logs, processing a total of 118,001 DNS requests across all record types (A, AAAA, NS, MX, TXT, etc.) for these eight domains during the observation month. Our analysis specifically filtered for TXT record queries directed at the DMARC subdomain.

Why is this Noteworthy?

This level of querying activity against the dmarc records is particularly noteworthy because the monitored domains were specifically configured not to engage in any email activity. These were not newly registered domains but rather "dropped" domains acquired by us, possessing varied histories but inactive at the time of monitoring and not set up as intentional honeypots. Also, we do not send any email from these domains.

Furthermore, their email authentication policies were deliberately strict: the SPF record (v=spf1 -all) explicitly forbids any server from sending email on their behalf. The DMARC policy was set to p=reject, instructing recipients to reject any email failing authentication checks - which, given the SPF policy, would encompass all emails purportedly from these domains. Consequently, standard DMARC operations, such as report generation triggered by email delivery attempts, should not occur. Indeed, despite configuring reporting addresses (rua and ruf), we received zero DMARC reports during the observation period, confirming the absence of legitimate email flow or standard reporting triggers. Therefore, the frequent external queries targeting the dmarc records lack a conventional operational explanation tied to email delivery or DMARC reporting mechanisms.

Potential Explanations

So, what could be driving these queries? We speculate on several possibilities:

• Reconnaissance Activities: Malicious actors or automated reconnaissance tools may systematically query DMARC records for vast numbers of domains. This helps them map the security posture of potential targets, understand which domains enforce email authentication, or simply inventory domain configurations as part of broader scanning efforts. The presence (or absence) and policy level (none, quarantine, reject) of a DMARC record can be valuable intelligence.
• Misconfigured Security Scanners: Automated vulnerability scanners or corporate security tools might be incorrectly configured. They could be performing checks for DMARC records on every domain they encounter or resolve, irrespective of whether the domain is expected to send email.
• Automated Tooling & Domain Validity Checks: Various internet-wide measurement platforms, bots, or tools designed to check domain health, availability, or gather general statistics might include DMARC lookups as part of their standard DNS query suite.
• Security Researchers: Other security researchers conducting large-scale studies on email authentication or DNS usage might be querying DMARC records across broad swaths of the internet, similar in principle to our own study, leading to queries against our monitored domains.

Relevance: Widespread Interest in DMARC

This bonus finding, while tangential to our core .de analysis, highlights a significant point: there appears to be widespread, automated interest in DMARC configurations across the internet, extending far beyond domains actively engaged in email communication. The volume of queries directed at essentially inert domains suggests that various actors view the presence and policy of a DMARC record as an important signal. It underscores the perceived importance of DMARC in the broader internet security landscape.

Projects like OpenIntel exemplify large-scale passive DNS data collection efforts, providing valuable insights into general DNS traffic patterns. However, such platforms do not typically focus on the specific phenomenon we observed – the targeted querying of DMARC records on non-email-sending domains. Our observation provides a small window into this specific, active monitoring behavior related to DMARC deployment itself.

Email authentication protocols like SPF, DKIM, and particularly DMARC are critical for securing the modern email ecosystem. Our comprehensive analysis of over 11.6 million .de domains reveals significant strides in DMARC adoption, with 7 % of domains having a potentially secure DMARC record. This indicates a lack of awareness and commitment to combating email-based threats like spoofing and phishing.

The observed widespread, automated querying of DMARC records on non-email-sending domains further underscores DMARC's perceived importance in the broader internet security landscape. It suggests that various actors, from security researchers to potential malicious entities, are actively monitoring DMARC configurations, recognizing their role in assessing a domain's security posture.

Ultimately, the journey towards a fully secure email environment requires continued effort. Organizations should prioritize implementing and properly configuring DMARC, moving towards enforcement policies to safeguard their brand integrity and protect recipients. As the digital threat landscape evolves, comprehensive email authentication is not merely a technical recommendation but a fundamental necessity for trusted communication.

DMARC Reference Sheet

DMARC Report Data

Source code of the research project