DNS & Email Security Checker - SPF, DMARC, DKIM & MX in Bulk

Check any list of domains for their DNS configuration and email authentication posture: A and AAAA records, nameservers, MX hosts, SPF, DMARC and DKIM, plus a guess at which DNS and mail provider they use.

No API key, no proxy, no rate limits: it queries DNS directly.

What you get per domain

Field	Example
domain	example.com
resolves	whether the domain has address records at all
ipv4, ipv6	A and AAAA records
nameservers, dnsProvider	ns1.example.net, Cloudflare
mxHosts, hasMx	["10 aspmx.l.google.com"]
hasNullMx	domain explicitly declares it accepts no mail (RFC 7505)
mailProvider	Google Workspace, Microsoft 365, Proofpoint, ...
spfRecord, hasSpf, spfPolicy	the record and whether it ends in -all or ~all
dmarcRecord, hasDmarc, dmarcPolicy	the record and none, quarantine or reject
dmarcReportingAddress	the rua= address collecting DMARC reports
dkimSelectorsFound, hasDkim	which common selectors publish a key
emailSecurityScore	0 to 3, one point each for SPF, DMARC and DKIM
txtRecords	all TXT records, useful for verification tokens
soaEmail	the zone's hostmaster address

Input

• domains - the domains to check, separated by commas, spaces or newlines
• dkimSelectors - which DKIM selectors to probe. Defaults to the common ones: google, selector1, selector2, k1, default, dkim, mail
• maxResults - cap on how many domains to process

Example input

{
  "domains": "example.com, stripe.com, github.com",
  "dkimSelectors": "google,selector1,selector2,k1,default"
}

Use cases

• Email deliverability audits - find which domains in a portfolio still lack SPF, DMARC or DKIM
• Security assessments - a DMARC policy of p=none means the domain can be spoofed with no enforcement, and this reports it in one column
• Lead generation for security and email vendors - a list of companies with emailSecurityScore below 2 is a qualified prospect list
• Vendor and technology mapping - mailProvider and dnsProvider reveal whether a company runs Google Workspace, Microsoft 365 or something else, which is strong B2B targeting signal
• M&A and due diligence - assess the DNS and email hygiene of an acquisition target from outside
• Phishing defence preparation - identify your own domains that are not yet protected

Why these three records matter

SPF says which servers may send for a domain. DKIM signs the messages. DMARC tells receivers what to do when the first two fail, and where to report it. A domain with SPF only is still trivially spoofable in practice, because nothing instructs receivers to act.

dmarcPolicy is therefore the single most informative field here: reject means enforcement, quarantine means partial, none means monitoring only, and a missing record means nothing at all.

Notes

• DKIM keys live under selector names that are chosen per sending service, so absence of a selector is not proof that DKIM is unused. The list of probed selectors covers the common providers; add your own if you know them.
• mailProvider and dnsProvider are inferred from hostname patterns and stay empty for self-hosted or unusual setups.
• txtRecords often contains domain verification tokens for SaaS products, which is another useful technology signal.
• A hasNullMx domain publishes an empty MX on purpose to say it receives no email. Treat those as unreachable rather than misconfigured.
• DKIM detection requires a real public key in the record. A selector publishing v=DKIM1; p= with an empty key is a revoked selector, not protection, and is reported as absent.
• Everything here is public DNS data; the actor sends no mail and connects to no mail server.