Our DNS research scanner.
If you found research-scanner.dmarc-analyzer.net in your logs, this page explains exactly what it asked for, why, and how to make it stop.
What it is
We run a long-running survey of how domains configure email authentication — DMARC, SPF, MTA-STS, TLS-RPT and BIMI. It reads public DNS records and nothing else. The point is measuring change: anyone can look up how many domains publish a strict policy today, but how that share moves over years only exists if somebody was already recording it.
Where the traffic comes from
All of it originates from one host. Both addresses have matching forward and reverse DNS, so you can confirm it is us rather than someone borrowing the name.
| Hostname | research-scanner.dmarc-analyzer.net |
| IPv4 | 178.105.202.3 |
| IPv6 | 2a01:4f8:c014:da0e::1 |
| User-Agent | DmarcAnalyzerResearch/1.0 (+https://dmarc-analyzer.net/research/) |
Most queries arrive over IPv6, since that is what the host prefers when a nameserver publishes both.
What it requests
For each domain, a small fixed set of public DNS lookups:
_dmarc.<domain>— the DMARC policy record<domain>TXT — to find the SPF record, and the records itsincludeandredirectterms point to_mta-sts.<domain>— the MTA-STS announcement_smtp._tls.<domain>— the TLS-RPT recorddefault._bimi.<domain>— the BIMI recordNS— which nameservers the domain is delegated toMX— where the domain receives mailDS— whether the domain is DNSSEC-signed
Where a domain announces MTA-STS, we also fetch its published policy over
HTTPS at /.well-known/mta-sts.txt on the
mta-sts subdomain — the same request any sending mail server
makes, carrying the User-Agent above. That is the only HTTP traffic we
generate.
What it never does
- No port scanning. We open no connections other than DNS and the single HTTPS request above.
- No authentication, ever. Nothing is logged into, guessed at, or probed for weaknesses.
- No mail. The survey sends none and receives none.
- Public records only. Everything read is already served to anyone who asks.
How often
The broad survey runs once a month across a public ranking of the most-visited domains, so a given domain sees roughly one pass of the queries above every thirty days. A much smaller curated list is checked daily to catch policy changes quickly. We rate-limit per nameserver and back off on failures rather than retrying hard — if our traffic is ever noticeable, something is wrong on our side and we want to hear about it.
Excluding a domain
Email research@dmarc-analyzer.net with the domain or nameserver, and we will exclude it. No justification needed and no argument — an operator who does not want to be surveyed is entitled not to be. The same address reaches us for corrections, method questions, or anything that looks wrong.
What we publish
Aggregate statistics only. Findings are reported as percentages across a population — never as a list naming individual organisations as misconfigured. Every published figure states the population, the date, how many domains resolved, and what counted as what, so the result can be checked or reproduced.
The survey is run by the team behind DMARC Analyzer, an open-source, self-hosted DMARC monitoring tool. It reads the same public records for the domains you choose to monitor — the difference is that there you point it at your own domains deliberately, and the reports stay on your own infrastructure.