Domain Intelligence — DNS, WHOIS, SSL & Subdomains

Give it a list of domains and get the full public record of each one: DNS records of every type, who registered it and when, whether its email can be spoofed, which providers it actually runs on, and every subdomain that has ever been issued an SSL certificate.

All from open infrastructure endpoints. No credentials, no port scanning, no intrusion — only what the domain's own DNS and the public certificate logs already publish.

A real row

apify.com:

Field	Value
registrar, registeredOn	Amazon Registrar, Inc. · 2009-06-02 (6,316 days old)
ipAddresses, nameservers	3.170.42.100 · ns-839.awsdns-40.net
providers	Google Workspace, Amazon SES, Mailgun
hasSpf / hasDmarc / hasDkim	yes · yes (p=reject) · yes
mailSecurityScore	3 / 3
subdomainCount	36 — including verify-company.apify.com, discord.apify.com

The mail-security check

Three DNS records decide whether a stranger can send email that appears to come from a domain: SPF says which servers may send, DKIM signs each message, DMARC tells receivers what to do when a message fails. A domain that sends mail without all three is trivially spoofable.

This Actor checks all three, reads the DMARC enforcement level — none merely reports, quarantine and reject actually block — and probes the eight DKIM selectors that Google, Microsoft, Mailchimp and the rest normally use. Anything missing is scored and explained in plain language.

Two of the three domains tested while building this came back at 2 out of 3. That proportion is typical, which is precisely why it sells: it is a specific, verifiable problem with a named fix.

The subdomain map

Every SSL certificate issued anywhere in the world is written to public Certificate Transparency logs. Reading them back for one domain reveals its subdomains — including staging servers, internal tools and admin panels that were never linked from anywhere.

This is entirely passive. Nothing is probed, nothing is connected to; the certificates were published by the certificate authorities themselves. It is also the single most revealing part of the record, and the reason security teams run this before anything else.

Who uses this

Security teams mapping their own or a supplier's external footprint. Sales and agency teams qualifying prospects by stack — everyone on a given mail provider, everyone missing DMARC. M&A and procurement doing technical diligence. Registrars and hosts finding domains about to expire. Fraud teams checking whether a domain was registered last week or a decade ago.

What it does not do

No port scanning, no vulnerability probing, no attempt to reach anything that is not publicly published. That is a deliberate limit: everything here can be run against a domain you do not own without touching its infrastructure at all.

Sources

Google and Cloudflare DNS over HTTPS for resolution, with automatic fallback between them. IANA's RDAP bootstrap to find each registry's authoritative server, then that registry's own RDAP endpoint. crt.sh for Certificate Transparency.

Frequently asked

Why is registration data missing for a .fr or .de domain? Because those registries restrict what they publish. The DNS, mail and certificate parts still work; registrationNote says when this is why.

Why are there fewer subdomains than I expected? Raise maxSubdomains. A large organisation can hold thousands of certificates and the default keeps the first hundred distinct hostnames.

Is a listed subdomain necessarily live? No. A certificate proves one was issued, not that the host still answers. Treat the list as history, which for security work is usually what you want.

Does a DMARC policy of none count as protected? No, and the output distinguishes it. none publishes a policy and asks receivers to do nothing about failures.