Free Email DNS Checker

What is an Email DNS Checker?

An Email DNS Checker is a public lookup tool that reviews the DNS records involved in sending and receiving email for a domain. Website DNS and email DNS often live together in the same zone, but they solve different problems. Website records route browsers to a web server. Email records tell other mail systems where to deliver messages, which senders are authorized, how signatures should be verified, and what receivers should do when authentication fails.

This checker focuses on the records that usually matter most for operational email: MX, SPF, DKIM, DMARC, BIMI, MTA-STS, and TLS-RPT. It turns those records into a grade, score, and set of recommendations. The score is a configuration signal, not a guarantee of deliverability. Inbox placement also depends on sender reputation, message content, bounce rates, complaint rates, list quality, and the policies of each receiving provider.

If you need a broader DNS lookup, use the DNS checker. For website transport and browser security, use the SSL checker, HTTPS checker, and Security Headers Checker.

What DNS records are needed for email?

The most common email DNS setup includes MX records for receiving mail, SPF to list approved sending systems, DKIM to verify signed messages, and DMARC to connect SPF and DKIM to a domain-level policy. A domain can technically send mail without all of these records, but many modern receivers treat missing or weak authentication as a risk signal. For business email, newsletters, transactional mail, password resets, invoices, and support messages, those records are part of the baseline.

BIMI, MTA-STS, and TLS-RPT are useful additions. BIMI can show a verified brand logo in some inboxes when other requirements are met. MTA-STS helps receiving servers announce a policy for encrypted SMTP delivery. TLS-RPT gives a domain a way to receive reports about TLS delivery problems. These records are optional, so the checker treats missing values as warnings rather than hard failures.

What are MX records?

MX records tell other mail servers where to deliver inbound email for a domain. Each MX record has a mail exchanger hostname and a priority. Lower priority numbers are tried first. A domain can publish more than one MX record for redundancy, but the records should point to the mail provider that actually handles the mailbox or inbound routing service.

If MX records are missing, inbound email may fail or depend on fallback behavior that should not be relied on. If MX records point to an old provider, mail can disappear into the wrong system after a migration. This checker passes MX when at least one public MX record is found.

What is SPF?

SPF, or Sender Policy Framework, is a TXT record that lists which servers and services can send email for a domain. A typical SPF record starts with v=spf1 and includes mechanisms such as include, ip4, ip6, a, or mx. The ending matters. A hard fail ending, -all, asks receivers to reject senders that are not listed. A soft fail ending, ~all, is more cautious and is often used during setup or migration.

SPF can break when a domain publishes more than one SPF record, when a provider include is missing, or when the record uses weak mechanisms such as +all. The checker flags multiple SPF records as a failure, warns on +all, ptr, and ~all, and passes a single SPF record that ends with -all and includes recognized sender mechanisms.

What is DKIM?

DKIM, or DomainKeys Identified Mail, lets a sender attach a cryptographic signature to outgoing email. Receivers use a public key from DNS to verify that the message was signed by a system authorized by the domain. DKIM records are published under selectors, such as selector1._domainkey.example.com. The selector is chosen by the email provider, which is why DKIM can be harder to check than SPF or DMARC.

This checker scans common selectors by default and also lets you enter a provider-specific selector. If no selector is provided and the scan finds nothing, the result is a warning because a valid DKIM record may exist under an unknown selector. If you provide a selector and it is missing, the result is stronger because the checker is looking for a specific expected record.

What is DMARC?

DMARC builds on SPF and DKIM. It tells receivers what policy the domain owner wants applied when messages fail authentication and alignment checks. The common policies are p=none, p=quarantine, and p=reject. Monitoring with p=none is useful during rollout because it lets you collect reports before asking receivers to quarantine or reject failures.

A stronger production setup usually moves toward p=quarantine or p=reject after legitimate senders have been verified. The checker also looks for rua because aggregate reports help you see which sources are passing or failing. DMARC without reports can still enforce a policy, but it gives you less visibility into mistakes and abuse.

What is BIMI?

BIMI, or Brand Indicators for Message Identification, is an optional DNS record that points to a brand logo for inboxes that support it. BIMI generally depends on strong email authentication and, for some providers, a verified mark certificate. It can help recipients recognize a brand, but it is not a standalone deliverability fix.

Missing BIMI is normal for many domains, especially small sites and internal tools. The checker reports it because it is part of the modern email DNS landscape, but missing BIMI only has a small effect on the score.

What are MTA-STS and TLS-RPT?

MTA-STS, or Mail Transfer Agent Strict Transport Security, lets a receiving domain publish a policy that asks sending mail servers to use authenticated TLS when delivering mail. TLS-RPT gives senders a reporting address for TLS delivery failures. Together, they help teams improve encrypted mail transport and observe problems that might otherwise be invisible.

These records are optional and require more than a TXT record to deploy fully. MTA-STS also needs a policy file served over HTTPS. The checker verifies whether the DNS records exist and explains them as useful hardening signals, not mandatory requirements for every domain.

Common email DNS problems

• The domain has no MX records, so inbound mail has nowhere clear to go.
• SPF is missing, duplicated, or copied with a weak +all mechanism.
• SPF uses ptr, which is discouraged because it can be slow and unreliable.
• SPF ends with ~all while the domain is ready for a stricter -all policy.
• DMARC is missing or still set to p=none after the sending sources have been verified.
• DMARC has no rua address, so aggregate reports are not being collected.
• DKIM is enabled at the mail provider but the published selector is different from the selector being checked.
• Optional transport records such as MTA-STS and TLS-RPT are missing from domains that send important mail.

The best fix depends on the email provider. Google Workspace, Microsoft 365, Postmark, Mailgun, Resend, SendGrid, and other providers each publish their own SPF includes, DKIM selectors, and onboarding steps. Always copy records from the provider dashboard and keep only one SPF and one DMARC record at each DNS name.

How to improve email deliverability

Start with correctness before optimization. Make sure MX records point to the right provider. Publish one SPF record that includes every legitimate sender and avoids overly broad mechanisms. Enable DKIM for every service that sends mail for the domain. Add DMARC with reporting, watch the reports, and move toward quarantine or reject when legitimate mail is passing.

After the DNS foundation is stable, review sending practices. Use consistent From domains, avoid sudden volume spikes, remove bouncing addresses, honor unsubscribes, and keep transactional and marketing streams cleanly separated when possible. DNS records help receivers trust the identity of your mail, but healthy sending behavior is what keeps that trust over time.