Understanding SenderRadar: the email map of a domain

SenderRadar draws the email map of a domain. Starting from a name typed into the search form, the site reconstructs what the email ecosystem sees of that domain: its receiving servers, its authentication rules, the subdomains attached to it and the way it answers for names that do not exist. The result is a one-page report, kept for thirty days, that serves as a neutral, educational entry point into topics usually scattered across RFCs and technical documentation.

What the site maps#

A SenderRadar report brings together four layers of information about a single domain.

The domain's email configuration. For the domain entered and for its organizational domain (the one from which policies are inherited), the report shows the MX, SPF and DMARC records as published in DNS, then analyses them: number of DNS lookups consumed by SPF, qualifier of the all mechanism, DMARC validity and policy, requested alignment, report recipients. Each block expands to show the raw record and the full analysis.

Known subdomains. A domain does not always send from its apex. Newsletters leave from news.example.com, application notifications from mail.example.com, support from help.example.com. The report lists the subdomains SenderRadar knows for this domain, each with an MX / SPF / DMARC summary. This is often where oversights hide: a subdomain that sends without SPF, or that inherits a DMARC policy of none while the apex is at reject.

The provider behind the MX. MX hosts are matched against a known provider when the pattern is recognisable (office suite, filtering service, email router, hosting company). This classification shows at a glance who receives a domain's mail and reveals mixed setups, where several providers share inbound delivery.

Wildcard behaviour. Some DNS zones answer for any subdomain, whether it exists or not. When this is the case, the report flags it, displays the generic configuration returned by the wildcard (its MX, SPF and DMARC) and hides the subdomains that merely repeat it, so that the list is not artificially inflated.

History, under construction#

Beyond the snapshot, SenderRadar aims to show how a domain evolves: a change of MX provider, a move from a DMARC policy of none to quarantine and then reject, subdomains appearing or disappearing. This historical dimension is under construction. It is neither promised for a given date nor guaranteed in its final form; what is visible today is what is available today.

Who SenderRadar is for#

• Mail administrators and IT teams, to check that an SPF or DMARC roll-out is consistent across all subdomains, not only on the apex.
• Marketing and CRM teams, to understand why a router or a mailbox provider rejects or quarantines their campaigns, and to talk to their sending provider on concrete grounds.
• Security teams, to measure the spoofing surface of a domain: a subdomain with no DMARC and no MX can still be used by a third party to send in its name.
• The curious and students, who want to see what an SPF record with nested include mechanisms, or a DMARC policy with its tags, actually looks like.

The guide and the glossary accompany the report: each notion displayed links to a page that explains it and says what to do about it.

What SenderRadar is not#

It is not a monitoring service. A report is a snapshot taken at analysis time, kept for thirty days, then deleted. There are no alerts, no periodic checks, no notification when a record changes. Watching a domain continuously requires a tool built for that purpose.

It is not a consultancy. The site explains what each value means and what the generally accepted good practice is, but it does not handle implementation, does not negotiate with routers and does not audit a sending infrastructure. The guide's recommendations are generic and must be adapted to each context.

It is not a sending test tool. SenderRadar reads what is published in DNS; it does not send test messages, does not verify a DKIM signature on a real email and does not measure an inbox placement rate.

Where the information comes from#

SenderRadar relies on its own analysis base. That base is what makes it possible to know a domain's subdomains, to match MX hosts to a provider and, in time, to trace a history. The records shown in a report are those observed at analysis time; they may differ from what DNS returns at the moment the report is read, especially if the domain was changed in between.

Free of charge, with quotas#

The service is free. To remain available to everyone, the number of analyses per day is limited: a reduced quota without an account, a higher quota with a free account, which also gives access to the history of one's own tests over thirty days. The FAQ details how quotas work, how long results are kept and how to suggest an improvement.