Skip to main content
Free public check · no account required

Enter only the domain. The scan reads public DNS and authoritative RDAP data; it does not send email or change your records.

Email authentication, with evidence

MailDNS shows what your domain tells mail servers.

MailDNS is a web application that checks and continuously monitors SPF, DKIM, DMARC, MX, and email transport security. It shows the record, rule, impact, and next safe action—without pretending DNS can promise inbox placement.

Diagnostic record

alerts.example · sample data

Illustrative, not live
  1. SPFVerified

    Sender policy resolves without a lookup-limit error

    v=spf1 include:_spf.sender.example -all

    The record is structurally usable for a message-specific check.

    Source
    TXT at alerts.example
    Rule
    RFC 7208 · evaluation limits
  2. DKIMVerified

    The supplied selector publishes a usable key

    selector1._domainkey.alerts.example → v=DKIM1; k=rsa; p=[sample key]

    MailDNS can verify selectors you provide; DNS cannot enumerate them.

    Source
    TXT at selector1._domainkey
    Rule
    RFC 6376 · key records
  3. DMARCReview

    Policy requests monitoring, not enforcement

    v=DMARC1; p=none; rua=mailto:[email protected]

    Failed authentication can be reported, but receivers are not asked to reject it.

    Source
    TXT at _dmarc.alerts.example
    Rule
    RFC 9989 · policy

A public scan observes configuration. Sender reputation and each mailbox provider's private filtering decisions remain outside what public DNS can prove.

Optional Google sign-in: when you choose it, MailDNS uses your Google name, email address, verified-email status, and profile image only to link or access your MailDNS account. MailDNS does not request access to Gmail, Google Drive, contacts, or messages. See the Privacy Notice.

Changes need context

A change becomes an incident record—not a screenshot.

Monitoring keeps the observation, source, rule version, impact, and recovery together. An operator can see what changed without reconstructing the event from scattered DNS tools.

  • Evidence at the moment of change

    Snapshots preserve the exact public value and when MailDNS observed it.

  • Explanation tied to a rule

    Findings cite the protocol rule and state what the observation does—and does not—prove.

SPF change record
Illustrative snapshot diff
Previous observationv=spf1 include:_spf.sender.example -all
Current observationv=spf1 include:_spf.sender.example include:legacy.example -all

Why it matters

The added include expands the evaluation path. MailDNS rechecks the lookup budget and records exactly which dependency introduced the change.

Next safe action: confirm that the legacy sender is still authorized before keeping the new include.

Diagnostic scope

One place for the layers that public evidence can verify.

Every check pairs its evidence with an explicit boundary. That keeps a healthy DNS record from being mistaken for a promise about sender reputation or inbox placement.

SPF
What MailDNS observesThe published policy, include and redirect path, syntax, and DNS lookup limits.
Honest boundaryA definitive message result also needs the sender IP, envelope sender, and HELO identity.
DKIM
What MailDNS observesThe key record and algorithm requirements for selectors you supply or discover from a message.
Honest boundaryDNS has no standard way to enumerate every selector a domain may use.
DMARC
What MailDNS observesPolicy discovery, alignment settings, enforcement intent, and aggregate-report destinations.
Honest boundaryReport delivery is voluntary and cannot represent every message or receiver.
MX & STARTTLS
What MailDNS observesReceiving routes and the TLS behavior observed by a probe from a named vantage point.
Honest boundaryMX does not identify outbound infrastructure, and one probe is not a global guarantee.
MTA-STS & TLS-RPT
What MailDNS observesPublished transport policy, policy-file retrieval, and reporting configuration.
Honest boundaryA correct policy does not prove that every remote delivery negotiated TLS.
DNSSEC & DANE
What MailDNS observesValidation-chain observations and TLSA records where the zone publishes them.
Honest boundaryMailDNS reports what resolvers and probes can validate, including their vantage and time.
CAA & RDAP
What MailDNS observesEffective CA authorization across resolvers plus authoritative registration dates, registrar identity, statuses, and expiration.
Honest boundaryCAA governs new issuance, not existing certificate validity; RDAP 404 is not registration availability and expiry is not a billing guarantee.

Precise about the evidence. Candid about the limit.

MailDNS is a configuration and transport control plane. It helps operators act on observable facts without turning them into an invented deliverability score.

MailDNS can prove

  • The public records and policy files observed during a scan.
  • Structural findings and evaluation paths tied to protocol rules.
  • The difference between stored snapshots of the same configuration.
  • The vantage point and time attached to a transport observation.

MailDNS cannot prove

  • Whether a particular message will land in the inbox.
  • A mailbox provider's private reputation or filtering decision.
  • Every DKIM selector a domain might use in the future.
  • Complete delivery data from receivers that choose not to report.

Start with a public baseline.

Run the free check to see the exact observations your monitoring history should begin with.

Check your domain