Email & Domain Auth Checker: MX, SPF, DKIM & DMARC

Check an email or domain's deliverability signals and email-authentication posture — MX, SPF, DKIM, DMARC, disposable and role flags — using only public DNS records. No SMTP connection, no mailbox ping.

What it does

This tool tells you whether a domain is set up correctly to receive and authenticate mail — it does not confirm a specific mailbox exists. Everything it checks (MX, SPF, DKIM, DMARC) is a public DNS record. Reading them needs no SMTP handshake, no "ping the mailbox and see what bounces" trick that gets you greylisted or rate-limited by real mail providers, and no false confidence from a technique mail servers increasingly detect and block.

Who it's for

Marketing and email operations. Check your own sending domains before a campaign and confirm SPF is strict and DMARC is enforcing rather than none.

Sales and revenue operations. Clean an imported lead list: flag disposable domains and role addresses before they enter the CRM.

Security teams. Audit a domain portfolio's SPF/DKIM/DMARC coverage, including parked domains that should publish a reject policy purely to stop their name being spoofed.

Developers and AI agents. Call check_email_domain at signup and branch on status and disposable to accept, challenge or reject a registration — without ever touching SMTP.

When to use it, and when not to

Use it to read a domain's mail-authentication posture from DNS: MX, SPF with its qualifier, DMARC with its policy, DKIM selectors, plus disposable and role-address flags.

Do not use it to verify that a mailbox exists. That requires an SMTP probe, which large providers answer unreliably and which can harm your sending reputation — this tool deliberately does not do it.

Why it's built this way

• Honestly distinguishes five outcomes — a domain that does not exist (UNRESOLVABLE), one that resolves but cannot receive mail (NO_MX, including an explicit RFC 7505 null MX), a genuine DNS failure (LOOKUP_ERROR), bad input (INVALID_INPUT), and a fully-checked domain (OK). Most checkers collapse all of these into one generic failure.
• DNS-only, zero SMTP — no mailbox ping, no external paid API, near-zero marginal cost, and none of the false negatives (greylisting, accept-all servers, provider rate limits) that plague SMTP-based verifiers.
• Honest about DKIM — DKIM keys live at a selector-specific DNS name with no directory to discover it. Without a selector, this probes a handful of common ones (google, default, selector1, selector2, k1, dkim, mail) and reports exactly which were checked — never claiming "no DKIM" when it simply did not guess the right selector. It also filters out revoked or placeholder keys (an empty p= tag per RFC 6376) rather than counting them as a false positive.
• Bulk-ready — check up to 100 emails or domains in one call, 5 at a time, with a status-count summary. A single bad entry never fails the batch.
• Nothing stored — every check reads public DNS records and discards them once the response is built.

Tools

check_email_domain — check one email or domain's MX/SPF/DKIM/DMARC and disposable/role flags.

{ "input": "user@example.com" }

{
  "domain": "google.com",
  "status": "OK",
  "hasMX": true,
  "disposable": false,
  "roleAddress": false,
  "spf": { "present": true, "policy": "~all" },
  "dmarc": { "present": true, "policy": "reject" },
  "dkim": { "selectorsChecked": ["google", "default", "selector1"], "found": [] }
}

status is one of OK, INVALID_INPUT, UNRESOLVABLE, NO_MX, or LOOKUP_ERROR. Pass dkimSelector if you know your domain's exact selector.

bulk_check_email_domain — check up to 100 emails or domains in one call, with a status-count summary.

{ "inputs": ["user@example.com", "mailinator.com"] }

FAQ

Is this email deliverable? The check confirms the domain resolves, has real MX records, and publishes SPF/DKIM/DMARC — the signals that determine whether mail sent to that domain is likely to arrive and be trusted. Read status, not just one field. A clean configuration is also not a promise of inbox placement.

Does it detect disposable addresses? Yes — every domain is checked against a bundled snapshot of well-known public disposable domains. New services appear constantly, so disposable: false means "not on this known list," not a guarantee.

Does it verify the mailbox? No, deliberately. Mailbox-level verification relies on SMTP RCPT probing, which real providers throttle, block, or answer dishonestly often enough that the result is less trustworthy than DNS signals, not more.

Trust & limits

Every check reads only public DNS records — no SMTP connection, no external paid API, nothing stored beyond the response. This is a deliverability-signal and auth-record check, not mailbox verification and not a guarantee mail will be accepted — final delivery always depends on the receiving mail server's own policies.