DomainDNSCheck

Email Security Checker

Enter a domain to review every DNS record that affects how its email is delivered, authenticated and protected, all in a single report.

  • Email security
  • Live check
  • Free, no sign-up
  • Results are not published

For example example.com — URLs and email addresses are accepted too.

Selectors cannot be discovered reliably from DNS. Find yours in a message header: DKIM-Signature … s=selector.

At a glance

What it checks
Review a domain's complete mail posture in one pass: MX, SPF, DMARC, MTA-STS, TLS-RPT and BIMI.
Data source
MX, SPF, DMARC, DKIM (with a selector), MTA-STS (policy fetched over HTTPS), TLS-RPT and BIMI records.
Freshness
Live check; results are cached for up to 10 minutes
Limits
A passive DNS and policy review; no mail is sent and no mailbox is tested. Methodology
Cost
Free, no account needed

Understanding the result

What is covered

The checker runs the following lookups in parallel and combines their findings:

  • MX: where mail for the domain is delivered, and whether each server resolves. See the MX Checker for details.
  • SPF: which servers may send for the domain, including the 10-lookup limit. See the SPF Checker.
  • DMARC: the policy for mail that fails authentication, and reporting. See the DMARC Checker.
  • MTA-STS: whether sending servers must use verified TLS when delivering to you.
  • TLS-RPT: where other servers should report TLS delivery problems.
  • BIMI: whether the domain publishes a brand logo for supporting mail clients.

DKIM is not included automatically because a selector is needed to look it up. Use the DKIM Checker with the selector from one of your messages.

MTA-STS, TLS-RPT and BIMI explained

MTA-STS has two parts: a TXT record at _mta-sts.example.com announcing a policy, and the policy file itself at https://mta-sts.example.com/.well-known/mta-sts.txt. The checker reads both. A policy in enforce mode is a PASS, testing is INFO, and none is a WARNING. If the TXT record exists but the policy file cannot be fetched or is invalid, that is a WARNING, because senders will not be able to apply it. No record at all is INFO.

TLS-RPT is a TXT record at _smtp._tls.example.com containing a rua address for daily reports about failed encrypted deliveries. It is a PASS when present and INFO when absent, and pairs naturally with MTA-STS.

BIMI is a TXT record at default._bimi.example.com pointing to a logo, and optionally a certificate. Mail clients only display BIMI logos for domains with an enforcing DMARC policy, so the record is a PASS with p=quarantine or p=reject and a WARNING otherwise.

Domains that do not use email

Parked domains and website-only domains are attractive to spammers because nobody watches them. If a domain never sends mail, the report will show missing MX and SPF findings; the right response is to publish records that say so explicitly: a null MX record (0 .), v=spf1 -all and a DMARC record with p=reject. MTA-STS and TLS-RPT findings are marked as not applicable when a domain has no mail servers.

What this check does not do

Every finding comes from public DNS, plus one HTTPS request for the MTA-STS policy file. The checker does not connect to your mail servers over SMTP, send test messages, check blocklists or read message content. A clean report means your published configuration is sound; actual delivery also depends on sending reputation and content. For reverse DNS of your outgoing mail server, use the Reverse DNS tool.

Frequently asked questions

Which findings should I fix first?

Start with FAIL findings in MX, SPF and DMARC, since those affect whether mail is delivered and whether others can spoof you. MTA-STS, TLS-RPT and BIMI are improvements to add once the basics are solid.

Do I need MTA-STS if my provider already uses TLS?

Most servers use TLS opportunistically, which an attacker on the network path can strip. MTA-STS tells senders to refuse delivery unless a valid certificate is presented, closing that gap.

Why is BIMI showing a warning even though my record is correct?

BIMI depends on DMARC enforcement. Until your DMARC policy is quarantine or reject, mail clients will not display the logo, so the tool flags the dependency.

How often should I run this check?

After any change to email providers or DNS, and periodically for domains you care about. Adding a new sending service is a common moment for SPF or DKIM to break.