Skip to content
Utiloom

Domain & Email Authentication Audit

Collect bounded MX, SPF, DMARC, CAA, BIMI, MTA-STS, and TLS-RPT DNS evidence with current RFC 9989 DMARC guidance.

NetworkNo DNS evidence retention

Reviewed July 13, 2026

Guide, examples, and validation Show

About this tool

Review public mail-authentication and domain-security DNS signals without treating record presence as message authentication, delivery, or provider eligibility.

  • Runs seven bounded DNS queries through one rate-limited and concurrency-limited server request, preserves exact lookup names, and returns a versioned no-store evidence report.
  • Distinguishes configured, review, not-found, and unavailable states while applying RFC 7208 SPF root-policy evidence and the RFC 9989 DMARC policy, test-mode, and historic-tag model.
  • Checks CAA and the DNS portions of BIMI, MTA-STS, and TLS-RPT without fetching assets, policies, certificates, mail servers, or report destinations.
  • Never guesses DKIM selectors and explains that SPF recursion, DMARC organizational-domain discovery, aligned messages, SMTP delivery, inbox placement, and BIMI display remain unverified.

How to use Domain Auth Audit

Enter a public domain or website URL, run the bounded DNS audit, then review the status, standards-based findings, exact answer records, and stated scope for all seven lookup names.

When this tool is useful

  • Reviewing mail and domain-security DNS before or after a controlled DNS change.
  • Capturing current MX, SPF, DMARC, CAA, BIMI, MTA-STS, and TLS-RPT evidence for incident or support triage.

Practical tips

  • Use the dedicated DKIM checker with a selector from the sending platform instead of guessing one.
  • Compare results after TTL and propagation windows, then validate authoritative DNS and real message headers separately.

Examples you can test

Load an example, compare the result with the expected output, then replace it with your own input.

Review a sending domain

Example input

example.com

Expected output

Timestamped, versioned evidence for seven public DNS answer sets

Configured records do not prove message-level alignment, SMTP delivery, transport security, or provider display.

Validation checklist

  • Confirm the audited hostname is the intended author or policy domain.
  • Read exact records and partial/advisory confidence instead of relying only on state labels.
  • Validate SPF recursively, DMARC alignment from real messages, and external BIMI or MTA-STS resources with dedicated workflows.

Frequently asked questions

Why is DKIM not included?

DKIM DNS names require a selector chosen by the sender. The audit never guesses selectors; use the dedicated DKIM checker with a known selector.

Does a configured SPF or DMARC record prove messages pass?

No. SPF depends on the evaluated identity, client IP, macros, and recursive DNS; DMARC also requires aligned SPF or DKIM for an individual message.

Does this validate MTA-STS or BIMI end to end?

No. It checks DNS syntax evidence only. It does not fetch the MTA-STS policy, BIMI SVG or certificate, connect to MX servers, or verify provider display.

What changed in current DMARC guidance?

RFC 9989 obsoletes RFC 7489, treats pct, rf, and ri as historic, adds the t test-mode tag, and treats a missing p tag as p=none.

Related tools

Keep the workflow moving

Continue with tools that handle a related input, output, or validation step.

SEO

SSL Certificate Checker

Inspect bounded live TLS certificate evidence.

Network
SEO

Technical Web Audit

Inspect bounded static response evidence from one public URL.

Network
SEO

DKIM Record Checker

Inspect bounded DKIM key evidence.

Network
SEO

Mixed Content Checker

Inspect bounded static mixed-content evidence.

Network