Four types of evidence
Observed: A configuration directly returned from a public DNS lookup, with a recorded checking time. Reported: A statement inside a received message header; it may not be trustworthy by itself. Inferred: A possible explanation consistent with available evidence. Unknown: Information unavailable from the present inputs.
What our domain checker checks
We query TXT records at the entered domain for SPF policies, TXT at _dmarc.yourdomain, and MX records for inbound-mail context. The inspector checks presence, duplicates, selected syntax conditions, top-level SPF DNS-querying terms, and common DMARC alignment and subdomain-policy settings. A high SPF term count is a warning, not proof that any particular message exceeded the DNS lookup limit. An optional advanced check evaluates common SPF mechanisms for a supplied SMTP identity and IP with bounded recursive DNS lookups; unsupported macros and PTR return indeterminate rather than a guessed answer. Optional effective DMARC discovery checks exact and organizational-domain records using a bundled, dated Public Suffix List snapshot. The snapshot requires periodic maintenance.
Does the domain send or receive email?
Visitors can tell us whether the domain sends mail, receives it, does both, or is website-only. This statement is self-reported; DNS cannot establish the domain owner’s intentions. A website can send order confirmations, form alerts, password resets or other messages without hosting a mailbox. Missing MX records do not automatically break outgoing mail, and a missing MX record does not explicitly prohibit incoming mail.
A domain that genuinely never receives mail may choose a null MX record, exactly 0 ., with no other MX records. A non-sending SMTP identity may use v=spf1 -all. A suitable DMARC policy may help protect a non-sending visible From domain. These settings should not be published until legitimate traffic and any inherited policy are identified. They are not one-click fixes or requirements for every domain.
Why a green configuration result isn't an inbox guarantee
SPF checks a message's SMTP identity and sending infrastructure. DKIM requires a signature and selector from an actual message. DMARC evaluates authentication and alignment. None of these alone establish that a receiver placed a message in its inbox. Provider-side filtering and reputation data are generally not public.
How we handle headers
Pasted headers are parsed locally in your browser. We display the authentication results reported by the headers and caution that these fields may come from different or untrusted sources. When both DNS and headers are provided in the Problem Solver, we also show carefully qualified cross-evidence observations, such as a mismatch between a checked domain and the visible From domain or a DMARC pass reported alongside an SPF failure. These comparisons are not independent verification of cryptographic results. We do not transmit the raw text to our DNS lookup endpoint.
Reporting server filters and domain matching
A message can include several Authentication-Results headers, added by different hops or even forged. You can view claims separately for a named reporting server. This is a filter for investigation, not proof that a particular server produced or trusted the result. The identity comparison labels a reported SPF or DKIM pass as an exact match only when its stated authenticated domain exactly equals the visible From domain. For different domains we can compare organizational domains using the bundled Public Suffix List snapshot, including private suffixes. This can classify a reported SPF or DKIM pass as relaxed-aligned or unaligned, but a stale suffix snapshot or forged headers can change conclusions. Actual DMARC verification still requires a trustworthy recipient-side authentication result.
Advanced evaluation limits
SPF evaluation requires the correct SMTP MAIL FROM identity and actual sending IP. The bounded evaluator handles ip4, ip6, all, include, redirect, a, mx, exists and literal %{d} domain expansion, with safeguards for recursion, DNS lookup terms, MX hosts and void responses. Other macro forms and PTR are explicitly indeterminate; an indeterminate result is not a sender failure. A policy result for user-supplied values is not evidence that a real email used those values.
Effective DMARC lookup starts at the visible From hostname, then tries the organizational domain determined by the bundled public suffix snapshot. Public suffix changes can alter inheritance. Reported alignment is separate from policy discovery and from actual receiver enforcement.
Public standards and provider guidance
- RFC 7208 — SPF
- RFC 7489 — DMARC
- RFC 8601 — Authentication-Results
- Gmail sender guidelines
- Yahoo sender resources
- Microsoft sender support
Scope and changes
These tools provide diagnostic guidance, not DNS editing, authenticated test sending, direct visibility into provider filtering, or certification of sender reputation. Provider requirements may change; they should be verified against current guidance before production decisions.