Check whether a domain's email authentication is set up correctly.
Checks MX, SPF (in TXT), DMARC and a common default DKIM selector, resolved live via public DNS.
Email / MX Records Checker looks up the DNS records that control how a domain sends and authenticates email: its MX records (which mail servers handle incoming mail), its SPF record (which servers are authorized to send mail as that domain), and its DMARC policy (what should happen to mail that fails authentication). Together these three checks give a fast health snapshot of a domain's email deliverability setup.
MX records tell the internet which mail servers should receive email for the domain — without them, or with them misconfigured, incoming mail simply bounces. SPF (Sender Policy Framework) is a TXT record listing which mail servers are allowed to send email claiming to be from your domain; without it, receiving mail servers have no way to distinguish your legitimate mail from a spammer forging your domain, which hurts deliverability and makes spoofing easier. DMARC builds on SPF and DKIM by publishing a policy telling receiving servers what to do with mail that fails those checks (quarantine, reject, or do nothing), and can also request reporting so you learn about spoofing attempts against your domain.
DKIM (DomainKeys Identified Mail) records live at a provider-specific subdomain like selector._domainkey.example.com, where the "selector" is chosen by your email provider (Google Workspace, Microsoft 365, SendGrid, etc.) and isn't guessable from the base domain alone. Because of this, DKIM can't be auto-discovered the way MX, SPF and DMARC can — check your provider's setup documentation for your exact selector, then use our DNS Lookup tool with a TXT query on that specific subdomain to verify it.
Marketing teams check this before a major email campaign launch to confirm authentication is properly configured and won't land in spam. IT administrators use it after migrating email providers to confirm MX records point correctly to the new service. Security-conscious domain owners use it to confirm a DMARC policy is actually published, since a missing DMARC record makes domain spoofing significantly easier for phishing campaigns.
Yes — publishing a DMARC record with a reject policy and no active mail servers is a recommended practice specifically to prevent your unused domain from being spoofed in phishing campaigns.
These refer to the qualifier at the end of the SPF record (~all for soft fail, -all for hard fail) — hard fail tells receiving servers to reject unauthorized senders outright, while soft fail asks them to treat it with suspicion but not necessarily block it.
This is common with domains set up for mail receiving without much attention to sending authentication — it's a security gap worth fixing even if the domain sends relatively little outbound mail.
No — a domain should have exactly one SPF TXT record; multiple SPF records is an invalid configuration that can cause authentication to fail unpredictably.
It confirms a policy is published, but the specific policy value (none/quarantine/reject) determines how strictly it's enforced — a "p=none" policy publishes visibility only and doesn't actually block spoofed mail.
Idiot Website Tools