A free lookup can answer a narrow question quickly. It cannot, by that fact alone, establish a maintained authentication programme. Evaluate the tool against a reader task: inspecting a public record, checking one message, analysing reports or running continuing operations. Price and evidence scope are different dimensions.
Describe the evidence boundary
A DNS lookup shows the answer returned through a particular resolver at a particular time. A message-header analyser interprets supplied headers, whose provenance matters. A report parser turns supplied reports into a usable structure. None of these observations automatically identifies every authorised sender or proves reliable delivery to every receiver.
DMARC's protocol checks and receiver handling are described in RFC 9989; aggregate reporting is described in RFC 9990. Use those standards to understand the evidence, not as proof that a particular utility implements every current requirement. Verify the actual tool version, documented scope and output.
Use a requirement-and-evidence matrix
Illustrative buyer worksheet: public record inspection requires a timestamped lookup result; sender diagnosis requires a trusted received sample and the sending owner; historical trend review requires retained reports with deduplication and coverage notes; ongoing remediation requires an assigned person and change authority. For each row, mark what the tool supplies, what must be added and who performs that work.
A tool that satisfies the first row may still be useful even if it does not satisfy the fourth. Avoid describing it as inadequate merely because it was built for a narrower task. Conversely, do not represent a green record check as proof of the whole programme.
Check privacy and repeatability
Before pasting a message or report into a hosted utility, review what will be transmitted, the service's privacy terms and the organisation's approval requirements. Prefer redacted or synthetic samples when they answer the question. Public DNS and a private customer message have different sensitivity. Do not assume that a zero-price service has no data-handling obligations.
For a repeatable investigation, preserve input provenance, time, tool version when available, result and interpretation. If the utility cannot export or retain the necessary evidence, decide whether a separate authorised record is sufficient. Test malformed or incomplete inputs safely rather than accepting every displayed result as authoritative.
Compare total work without inventing savings
Measure the time required to collect inputs, interpret output, chase owners, make approved changes and verify results. A commercial or managed service also requires evidence of its actual scope and does not automatically remove those duties. Choose the smallest approach that meets your requirements, then document the remaining responsibilities. This guide does not rank tools or assert any unverified free or paid product capability.
Work through four hypothetical evidence decisions
These are written teaching inputs and proposed interpretations, not executed rules, lookup results or a named-tool comparison.
- Public record inspection: suppose a supplied string is v=DMARC1; p=none. Displaying it unchanged proves only the supplied text was preserved. It does not establish what DNS currently returns or validate full policy discovery. Obtain a timestamped resolver response for a real investigation.
- Missing message: suppose the header input is empty. Keep message authentication indeterminate and request a trusted received sample; never turn missing evidence into a pass.
- Unaligned identity: suppose From is billing.brand.test, the sole DKIM signature is stipulated valid with d=vendor.other.test, and no aligned SPF pass exists. That stipulated message has no passing aligned mechanism. This assumes the full set of relevant authentication evidence; an incomplete header subset would not establish the same conclusion. Verify real receiver provenance and the full protocol context before live diagnosis.
- Missing reporting interval: suppose no report was supplied for a declared window. Record coverage as unknown; investigate collection and receiver participation rather than treating the gap as zero mail or zero failures.
A real comparison must run the same authorized inputs against pinned tools, retain their actual outputs and identify each discrepancy. No script or external tool was executed for this article.
Source scope
RFC 9989 Sections 4.4, 5.3.5 and 5.4 distinguish alignment, message evaluation and receiver handling. RFC 9990 Sections 3.1, 7 and 8 describe aggregate evidence and privacy/security considerations. Neither specifies staffing hours, prices or commercial operating commitments. Work estimates, cost examples and evaluation gates here are original editorial guidance, not observed customer results or standards-mandated budgets.