Reading a SenderRadar report block by block

A SenderRadar report reads from top to bottom: the identity of the organizational domain, then the searched domain, then the subdomains, then the wildcard behaviour. Each block opens with badges that summarise its state and expands to show the raw record and its analysis. This page describes every block, every badge, and what to do when a value is not the one expected.

The header: analysis date and expiry date#

The line under the domain name gives the date of the analysis and the date until which the report remains available (thirty days). The values shown are those observed on the analysis date; if the domain has been changed since, a new analysis is needed to see the current state.

The Whois block of the organizational domain#

The report opens with the registration details of the organizational domain: registrar, registrant when published, creation, update and expiry dates, status (for instance clientTransferProhibited), name servers, abuse contact and whether DNSSEC is enabled.

This block puts the domain in context: a domain created a few days ago, without DNSSEC and with generic name servers, does not have the same profile as one registered fifteen years ago. An expiry date that is close deserves a check with the registrar. The registry may not answer; the block then says so without blocking the rest of the report.

The "Searched domain" and "Organizational domain" blocks#

If the name entered is a subdomain, the report shows two blocks: the subdomain, then the organizational domain it depends on. If the name is already the organizational domain, a single block appears. Each has three rows.

MX row#

Each MX host is preceded by a badge: the name of the recognised provider, or "Unclassified" when the pattern is not known. "No MX" means the domain does not receive mail. That is not an anomaly for a send-only subdomain, but a domain with neither MX nor a restrictive DMARC policy remains usable by a third party to send in its name. In the expanded view, the table gives the host, its priority (the lowest is contacted first) and its classification.

SPF row#

The first badge is the record status: ok in green; permerror in red when the record is unusable (invalid syntax, several SPF records, limit exceeded); other statuses in orange flag a warning. "No SPF" means no record was found.

Two badges complete the status:

• n/10 lookups: the number of DNS resolutions consumed by the include, a, mx, ptr, exists and redirect mechanisms. RFC 7208 allows ten; beyond that, receivers return permerror and the record protects nothing. A counter at 8 or 9 means every new provider must be watched.
• all= followed by the qualifier: -all (hardfail) rejects any sender not listed, ~all (softfail) marks it without rejecting, ?all decides nothing, +all authorises everyone and empties the record of meaning.

The expanded view adds:

• Void lookups: resolutions that returned NXDOMAIN or no answer. Beyond two, the RFC requires a permerror. This is usually an include pointing at a provider no longer used, or a misspelled name.
• Blocks all sending: "Yes" if the record reduces to v=spf1 -all, which is the recommended configuration for a domain that never sends.
• Record size: in bytes, with a warning above 512, the historical limit of UDP answers.
• Uses macros: the macro letters present (%{i}, %{d}...). Macros are legitimate but make evaluation depend on each message; the lookup counter can then only be estimated.
• Max include depth: the deepest nesting level. A deep tree is fragile: every intermediate provider can break the chain.
• Mechanism tree: each mechanism, its qualifier and its evaluation status, with include entries indented. This is where a forgotten provider or a duplicated include shows up.

DMARC row#

The main badge is the policy: p=reject in green, p=quarantine in orange, p=none or a missing p in red. "No DMARC" means no record was found at _dmarc.<domain>. A "valid (RFC 7489)" badge confirms the record is syntactically correct; otherwise the expanded view lists the reasons.

The expanded view gives each tag:

• Policy (p): what the receiver should do with a message that is not aligned. The usual path is none (observation), then quarantine, then reject.
• Subdomain policy (sp): policy applied to subdomains without their own record. When absent, it equals p. An sp=none under a p=reject leaves subdomains open.
• Percentage (pct): share of messages to which the policy applies. A pct=10 at reject is not a reject.
• DKIM alignment (adkim) and SPF alignment (aspf): r (relaxed, same organizational domain) or s (strict, identical domain). Relaxed is the default and fits most cases.
• Failure options (fo): conditions under which forensic reports are sent.
• Aggregate reports (rua) and Forensic reports (ruf): recipient addresses. Without rua, there is no visibility on failures; it is the first tag to fill in.

A subdomain without its own record shows "Inherited from" followed by the organizational domain: RFC 7489 states that it takes that domain's policy (sp if defined, otherwise p).

The table of identified subdomains#

Each row is a known subdomain, with three columns of compact badges. Under MX, a single badge names the provider; a + accompanies a recognised provider mixed with unclassified hosts; "Mixed" flags several providers. Under SPF, the status in green or orange. Under DMARC, the subdomain's p= policy, green for reject. Clicking a row loads the full detail, identical to that of the main blocks.

The useful reading is across rows: spot the subdomains that send (MX or SPF present) and remain at p=none or without SPF, while the apex is protected.

The Wildcard DNS block#

When it appears, this block indicates that *.<domain> answers for any non-existent name. It shows the generic configuration returned (the wildcard's MX, SPF and DMARC, or "None" for each) and says how many tested subdomains returned only that configuration and were hidden from the table. A wildcard with MX deserves attention: it accepts mail for an infinity of addresses, and a wildcard without DMARC lets every invented name inherit the organizational domain's policy, provided one exists.

Going further#

A SenderRadar report describes what is published; it does not say how a real message is handled on arrival. To test an email send or monitor a domain over time, dedicated tools exist, to be chosen according to each sender's volumes and constraints.