Bulk Domain Intel: WHOIS/RDAP, DNS, Email Security & SSL

Paste a list of domains, URLs or e-mail addresses. For each one you get one flat JSON row with:

• Registration (RDAP, the official successor to WHOIS): registrar and IANA ID, creation, update and expiry dates, domain age, days to expiry, registry status codes and DNSSEC. Available for every generic TLD (.com, .net, .org, .io, .ai, .app, new gTLDs) and about 80 country-code TLDs. See which TLDs have registration data.
• DNS: A, AAAA, MX, NS, TXT and CAA records, plus the mail provider (Google Workspace, Microsoft 365, Proofpoint, Mimecast and others) and the DNS provider (Cloudflare, Route 53, Akamai and others).
• Email security grade (A–F, 0–100): SPF (DNS lookups counted recursively against the limit of 10), DMARC policy, pct and reporting domains, MTA-STS mode, TLS-RPT, BIMI, and common DKIM selectors. Each problem is listed in plain English.
• SSL/TLS certificate: whether it is valid, the issuer, days to expiry, SAN count, key type and TLS version. Expired or untrusted certificates are still read and reported.
• Tech stack (optional): hosting and CDN, CMS, JavaScript frameworks, analytics, ads, marketing, chat, consent and payment tools. Detection uses one homepage GET (headers and static HTML) plus SaaS clues in DNS: every TXT verification token, SPF senders and the www CNAME. Every detection comes with its evidence.

It works with no API key or login. Data comes only from official and public sources: the IANA RDAP bootstrap, the registries' own RDAP servers, public DNS, a TLS handshake and, in tech mode, one homepage request per domain.

Who it's for: sales ops and RevOps teams enriching account lists (mail provider, tech stack), security and IT teams auditing email spoofing protection and certificate expiry across a portfolio, domain investors and brand-protection teams watching expiry dates, SEO agencies, and AI agents that need a quick "what is this domain?" answer.

Input

Field	Type	Default	What it does
domains	array of strings	— (empty = apify.com as an example)	Domains, URLs or e-mails, one per item. https://www.Example.com/page → example.com; jane@acme.io → acme.io. A leading www. is removed; other subdomains are kept. Duplicates are removed. Up to 10,000 per run.
techStack	boolean	false	Adds tech-stack detection (one homepage GET per domain).
includeRdap	boolean	true	Registration data from RDAP. Turning it off does not change the price.
includeTls	boolean	true	TLS certificate check on port 443 (the apex first, then www.). Turning it off does not change the price.
maxRecords	integer	none	Optional cap on the number of domains checked (and charged).

{
  "domains": ["stripe.com", "https://www.shopify.com/pricing", "jane@notion.so"],
  "techStack": true
}

The fields above are checked against the input schema, so domains must be an array and maxRecords an integer. Callers that have something else can use the aliases, which are read leniently:

• domain, urls, websites or emails instead of domains. These take an array or a single string such as "a.com, b.com" (commas, semicolons, spaces and new lines all separate). Any other key containing "domain", "url", "website" or "hostname" (domainNames, domain_list, urlList) is read as the domain list too, with a warning in the log.
• Objects such as {"url": "https://x.com"}, {"website": ...} or {"domain": ...} work as items.
• tech, or "mode": "tech", instead of techStack; whois or rdap instead of includeRdap; ssl or tls instead of includeTls; limit instead of maxRecords. Other spellings of the field names also work (tech_stack, include_tls, TechStack) and take priority over the defaults the platform fills in. These accept "yes", "no", "on", "off" and numbers given as strings.

Inside an array, each item is one value: "exa mple.com" is rejected as a typo, never read as mple.com. Values that can't be a domain get a free row with status: "invalid_input" that says why. That covers IP addresses, localhost, spaces, an object with no URL field, and a top-level domain that does not exist such as shop.cmo (checked against the DNS root). If the input holds data only under field names the actor doesn't recognise (e.g. {"names": [...]}), you get one free row that names those fields, and nothing is checked or charged. The run never fails because of bad input, including text with broken Unicode characters.

Output

Every row has the same keys, whatever happens. Fields that don't apply are null or []. Here is a real row from a local run with {"domains": ["apify.com"]} (core mode):

{
  "position": 1,
  "input": "apify.com",
  "domain": "apify.com",
  "registrable_domain": "apify.com",
  "status": "ok",
  "checked_at": "2026-09-25T00:58:12Z",
  "registered": true,
  "registrar": "Amazon Registrar, Inc.",
  "registrar_iana_id": "468",
  "created_at": "2009-06-02T17:14:10Z",
  "updated_at": "2026-05-16T16:53:04Z",
  "expires_at": "2035-06-02T17:14:10Z",
  "domain_age_days": 6323,
  "days_to_expiry": 3172,
  "registry_status": ["client transfer prohibited"],
  "dnssec": true,
  "rdap_server": "rdap.verisign.com",
  "rdap_error": null,
  "resolves": true,
  "a": ["143.204.204.42", "143.204.204.5", "143.204.204.87", "143.204.204.97"],
  "aaaa": ["2600:9000:2058:2000:9:a03e:6540:93a1", "2600:9000:2058:2c00:9:a03e:6540:93a1", "2600:9000:2058:6200:9:a03e:6540:93a1", "2600:9000:2058:7200:9:a03e:6540:93a1", "2600:9000:2058:8400:9:a03e:6540:93a1", "2600:9000:2058:9200:9:a03e:6540:93a1", "2600:9000:2058:cc00:9:a03e:6540:93a1", "2600:9000:2058:f800:9:a03e:6540:93a1"],
  "mx": ["aspmx.l.google.com", "alt1.aspmx.l.google.com", "alt2.aspmx.l.google.com", "aspmx2.googlemail.com", "aspmx3.googlemail.com"],
  "ns": ["ns-1225.awsdns-25.org", "ns-1928.awsdns-49.co.uk", "ns-449.awsdns-56.com", "ns-839.awsdns-40.net"],
  "txt": ["v=MCPv1; k=ed25519; p=1rDnoEigwTr+4JjG89+sLbdNnswCnLjmaeT34srW53Y=", "v=spf1 a mx include:_spf.google.com include:mailgun.org include:amazonses.com include:19497222.spf05.hubspotemail.net -all", "aisle-domain-verification-ymx7gd=j3J4hCmXHIc9R0RNQCfa8xdSf", "google-site-verification=R_4agUZyHorQrO5QGFa6ZB_o-uDxq82NY-EteDUpPvo", "google-site-verification=XU737OZxx6NvGd3NQK9MRt98qxRMjx3RByq-O0cy16I", "google-site-verification=ZqRh2_YSBHj2bo_KsEdu6MfmTMKJYLpDDL3oPtOrN_A", "google-site-verification=jrECJwBG9eeO_FUrOMhp7JY1oF8JSBxhzmLsLGvrt9s", "mixpanel-domain-verify=44615d9c-27f2-4587-a781-8a0a1c734e9a", "openai-domain-verification=dv-WTM7Nna92Owwh4sgmDOVUyyt", "tito-domain-verification=pbg2696rvzbax2t4dl7h5ynqm", "zapier-domain-verification-challenge=2c358aa9-fa36-419f-b21a-ca9eb6f2791d"],
  "txt_count": 11,
  "caa": ["0 issue \"amazonaws.com\"", "0 issue \"digicert.com\"", "0 issue \"letsencrypt.org\"", "0 issuewild \"amazonaws.com\"", "0 issuewild \"letsencrypt.org\""],
  "mx_provider": "Google Workspace",
  "dns_provider": "Amazon Route 53",
  "dns_error": null,
  "email_security_grade": "A",
  "email_security_score": 100,
  "email_security_issues": [],
  "spf_record": "v=spf1 a mx include:_spf.google.com include:mailgun.org include:amazonses.com include:19497222.spf05.hubspotemail.net -all",
  "spf_all": "-all",
  "spf_includes": ["_spf.google.com", "mailgun.org", "amazonses.com", "19497222.spf05.hubspotemail.net"],
  "spf_dns_lookups": 10,
  "dmarc_record": "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@apify.com; ri=604800",
  "dmarc_policy": "reject",
  "dmarc_subdomain_policy": "reject",
  "dmarc_pct": 100,
  "dmarc_rua_domains": ["apify.com"],
  "dmarc_source": "domain",
  "mta_sts_mode": "enforce",
  "tls_rpt": true,
  "bimi_logo": "https://apify.com/ext/apify-bimi-logo.svg",
  "bimi_certificate_url": "https://apify.com/ext/apify-bimi-certificate.pem",
  "dkim_selectors_found": ["google"],
  "tls_valid": true,
  "tls_host": "apify.com",
  "tls_version": "TLSv1.3",
  "tls_issuer": "Amazon (Amazon RSA 2048 M04)",
  "tls_subject": "*.apify.com",
  "tls_san_count": 4,
  "tls_key": "RSA 2048",
  "tls_not_before": "2026-07-03T00:00:00Z",
  "tls_not_after": "2027-01-16T23:59:59Z",
  "tls_days_to_expiry": 113,
  "tls_error": null,
  "hosting": null,
  "www_cname": null,
  "http_status": null,
  "final_url": null,
  "http_server": null,
  "html_generator": null,
  "tech_names": [],
  "tech": [],
  "http_error": null,
  "note": null
}

With techStack: true, the tech fields are filled in. This excerpt is from a real run on allbirds.com:

{
  "domain": "allbirds.com",
  "hosting": "Shopify",
  "www_cname": "shops.myshopify.com",
  "http_status": 200,
  "final_url": "https://www.allbirds.com/",
  "http_server": "cloudflare",
  "tech_names": ["Apple (domain verification)", "Attentive", "Cloudflare", "DocuSign", "Google Search Console",
                 "Google Tag Manager", "Microsoft 365", "Miro", "OneTrust", "Shopify"],
  "tech": [
    {"name": "Shopify", "category": "Ecommerce", "evidence": "dns:www CNAME shops.myshopify.com"},
    {"name": "Cloudflare", "category": "CDN", "evidence": "header:server cloudflare"},
    {"name": "Google Tag Manager", "category": "Tag manager", "evidence": "html:googletagmanager.com/gtm.js"},
    {"name": "Attentive", "category": "SMS marketing", "evidence": "html:cdn.attn.tv"},
    {"name": "OneTrust", "category": "Consent management", "evidence": "html:optanon"},
    {"name": "Microsoft 365", "category": "Productivity", "evidence": "dns:TXT ms=ms"},
    {"name": "Apple (domain verification)", "category": "Business services", "evidence": "dns:TXT apple-domain-verification"},
    {"name": "DocuSign", "category": "E-signature", "evidence": "dns:TXT docusign"},
    {"name": "Google Search Console", "category": "SEO", "evidence": "dns:TXT google-site-verification"},
    {"name": "Miro", "category": "Productivity", "evidence": "dns:TXT miro-verification"}
  ],
  "http_error": null
}

Field notes

• txt / txt_count: txt holds at most 25 records, in a fixed order: policy records such as v=spf1 first, then alphabetical. txt_count is the total number published. Large companies often publish 50–110 TXT records. SPF parsing and tech detection always read all of them, not only the 25 shown.
• spf_dns_lookups: the RFC 7208 count, with every include:/redirect= followed to the end (up to 40 queries and 10 levels deep). If a target can't be resolved or those limits are hit, the number is a lower bound and the issue says "at least N".
• dmarc_policy: the policy that applies to the domain you asked about. For a subdomain with no DMARC record of its own, the organizational domain's record is used (dmarc_source: "organizational_domain"), and the policy that applies is that record's sp=, or its p= when there is no sp= (RFC 7489). The grade uses the same policy. Example from a real run: newsroom.ibm.com has no record, and ibm.com publishes p=reject; sp=none. The row therefore shows dmarc_policy: "none" and grade D (30), and the issue list explains why. dmarc_record always shows the record as published.
• dmarc_subdomain_policy: the policy that actually applies to subdomains. That is sp= when it is published; otherwise subdomains inherit p=.
• Duplicate records: if a domain publishes two SPF or two DMARC records (a misconfiguration that receivers treat as broken), the one shown is picked in a fixed order, so it doesn't change between runs. The issue list flags the duplicate.
• bimi_certificate_url: the a= URL of the BIMI certificate (VMC/CMC), exactly as published. The certificate itself is not downloaded or validated.
• registrar_iana_id: only real IANA registrar IDs are kept. Placeholders such as 0000 (used by some ccTLD registries) become null.
• email_security_grade is null when a lookup the grade depends on (_dmarc, _mta-sts, _smtp._tls or default._bimi) timed out. A timeout is never read as "no record". The issue list says which lookup failed, dns_error names it, and the row is partial.
• position: the domain's place among the valid values in your input. Rows are pushed in small batches as domains finish, so sort by position if order matters.

status values

status	meaning	charged?
ok	every enabled lookup answered	yes
partial	the domain exists and the row has data, but one section is missing. Causes: the TLD has no usable public RDAP (e.g. .de, .co, .eu, .jp, .edu, .tw); a registry rate limit or timeout; or a DNS lookup that kept failing. See rdap_error / dns_error.	yes
unregistered	the registry says "not found" and the name doesn't exist in DNS, so it is probably available	yes
not_in_dns	the name doesn't exist in DNS (NXDOMAIN), but the registry didn't confirm it is unregistered. Either the TLD has no public RDAP (a .de name that is probably available), or RDAP was off or failed, or the name is registered but not in DNS (on hold, or a subdomain that doesn't exist). note says which.	yes
error	every lookup failed (a network or upstream outage)	no (free row)
invalid_input	the value couldn't be read as a domain, or its top-level domain doesn't exist	no (free row)
not_checked	one summary row, added only when the run stopped before checking every domain because of your maximum charge or the run timeout. note says how many domains were left, lists the first few, and gives the reason.	no (free row)

The dataset has three views: Overview, Email security and Tech stack. You can export them as JSON, CSV or Excel.

Email security score

Part	Points
SPF	20 for one valid record, plus 15 for -all or 10 for ~all/redirect= (?all and +all score nothing). −10 if it needs more than 10 DNS lookups.
DMARC	10 for a valid record, plus 35 for p=reject or 25 for p=quarantine, scaled by pct (p=none scores 0 and is flagged). A subdomain that inherits its parent's record is scored on the parent's sp= policy.
MTA-STS	10 for enforce, 5 for testing
TLS-RPT	5
BIMI	5

Grades: A ≥ 85, B ≥ 70, C ≥ 50, D ≥ 30, F below 30. Domains that receive no mail (no MX, or a null MX) get the MTA-STS, TLS-RPT and BIMI points automatically. For a parked domain, -all plus p=reject is the whole job. DKIM results are reported but not scored, because selectors can't be listed from DNS.

Pricing

Pay per event: you pay only for rows you receive.

Event	Price	When
actor-start	$0.01	once per run, when the first paid row is delivered
domain-report	$0.003	per domain row (core mode, or tech mode when the homepage couldn't be fetched, e.g. a bot-protection 403)
domain-report-tech	$0.004	per domain row in tech mode where the homepage was fetched and fingerprinted

Invalid inputs, including typos with a non-existent TLD, are free, and so are rows where every lookup failed and the not_checked summary row. Rows on TLDs without usable public RDAP are charged at the normal price: they still carry full DNS, email and TLS data. The run's status message lists those TLDs. not_in_dns rows are charged too, because the DNS and registry lookups were made and answered.

Worked examples:

• One domain from an AI agent: $0.01 + $0.003 = $0.013
• 100 domains, core mode: $0.01 + 100 × $0.003 = $0.31
• 1,000 domains, core mode: $0.01 + 1,000 × $0.003 = $3.01
• 1,000 domains, tech mode: $0.01 + 1,000 × $0.004 = $4.01 at most. Homepages that block the request are billed at $0.003.
• 10,000 domains, core mode: $30.01

Set a maximum charge per run and the actor stops cleanly at that limit. It never pushes a row it can't bill, free rows don't count against the limit, and the run still ends as SUCCEEDED. A free not_checked row then says how many domains were left and why. If the limit doesn't even cover actor-start plus one report ($0.013), nothing is checked or charged and that row says so. In tech mode, rows in flight are budgeted at the tech price until they are charged. A row that falls back to the core price frees its difference for later domains. If Apify migrates or restarts the run, it continues where it stopped and does not charge a delivered domain or actor-start a second time. Apify's platform usage (compute) is billed separately and is small.

Speed and limits

Local measurements on 2026-09-24, 131 well-known domains across 16 TLDs (including .de, .jp, .edu and .tw):

• Core mode: 37 s, peak memory 113 MB. When most domains share one TLD (e.g. .com), expect about 3–4 domains per second, because each registry's RDAP server is limited to about 3 requests per second with at most 2 in flight. That is on purpose: RDAP is a shared public service. Mixed TLDs run faster.
• Tech mode: 57 s (about 2.3 domains per second), peak memory 124 MB. It makes one homepage GET per domain, with a 1.5 MB cap on the decompressed body and 35 s per homepage.
• 10,000 domains in tech mode (the largest allowed input) against a simulated instant network with a 350 KB homepage for every domain: 265 s at 77 MB peak. Nearly all of that time is HTML fingerprinting, about 9 ms per 350 KB page on a desktop CPU. Memory stays flat because rows are pushed in small batches. A real run is limited by the upstream servers, not by this.

Each part of a domain's check has its own time limit: DNS and email 60 s, RDAP 40 s, TLS 30 s, homepage 35 s. A registry that keeps rate-limiting (HTTP 429) is retried, honouring Retry-After, until its 40 s are used up. A slow homepage is cut off at its limit. Either way the row is still delivered, as partial with rdap_error or with http_error, and keeps the DNS, email and TLS data. Compressed homepages and MTA-STS files are decompressed with a size cap, so a hostile "zip bomb" server can't exhaust memory. The run stops scheduling new domains before the run timeout and cuts off anything still in flight in time to save it. Short timeouts still produce rows: a 30 s run timeout, as an agent might set, checks a few domains. For very large lists, raise the timeout or split the list.

FAQ

Is this WHOIS? It uses RDAP, the structured JSON protocol that replaced WHOIS for generic TLDs. Registry servers are found through the official IANA bootstrap file.

Which TLDs have registration data? All generic TLDs listed in the IANA bootstrap: .com, .net, .org, .info, .biz, .gov, .app, .dev, .xyz and the other new gTLDs. On 2026-09-24 these country-code TLDs also had it: .ac .ad .ai .ar .as .au .bm .br .ca .cc .cm .cr .cv .cx .cz .ec .fi .fj .fm .fo .fr .gd .gs .gy .hn .ht .id .in .io .is .ke .kg .kr .ky .lb .ly .me .mg .ml .ms .mu .na .nf .ng .nl .no .pg .pl .pm .pn .pw .re .rw .sd .sg .sh .si .sn .sr .ss .tf .th .to .tv .tz .ua .uk .us .uz .vg .vi .wf .ye .yt .zm. .io, .me, .ac, .sh and .us use the registries' own public RDAP servers, which aren't yet listed in the bootstrap. Every other ccTLD has no usable public RDAP. That includes .de, .eu, .co (Colombia), .es, .it, .ch, .at, .be, .dk, .se, .pt, .ie, .nz, .jp, .cn, .ru, .mx, .so, .tr and .za, plus the sponsored .edu and .mil. .tw is listed in the IANA bootstrap, but on 2026-09-24 TWNIC's server answered every query with HTTP 426 and an empty body. The actor asks it once per run and then reports the refusal on every .tw row. Those rows still carry full DNS, email and TLS data and are marked partial, with the reason in rdap_error. A name on one of these TLDs that doesn't exist in DNS is marked not_in_dns ("probably unregistered"), because the registry can't confirm it. If your list is mostly EU or .co domains, run a few first and check whether the DNS/email/TLS data is what you need.

Does it return registrant names, e-mails or phone numbers? No. Only the registrar, dates, status codes and DNSSEC are extracted. Registrant contact data is mostly redacted anyway, and this actor never collects personal data.

How are subdomains handled? blog.example.co.uk is checked as given for DNS, email and TLS. Registration data is looked up for the registered domain example.co.uk, using the Public Suffix List. If a subdomain has no DMARC record, the organizational domain's record is used, as the DMARC standard (RFC 7489) specifies. The policy that applies is then that record's subdomain policy sp= (or p= when there is no sp=), and the grade uses it. dmarc_source says which record applied. A subdomain that doesn't exist in DNS is marked not_in_dns.

Why is mx_provider "Other" or "Self-hosted"? The MX hosts didn't match a known provider. "Self-hosted" means they sit under the domain itself. The raw mx hosts are always included.

Why wasn't some tool detected? Tech detection reads the homepage HTML and response headers without running JavaScript. Tags loaded later through a tag manager can be missed. Sites behind bot protection may answer 403; you then get header and DNS clues only, billed at the core price. The fingerprints are a hand-maintained set of about 320 technologies, plus 57 mail providers and 47 DNS providers. No GPL-licensed fingerprint database is used.

Can a detection be wrong? An HTML detection means the vendor's marker appears somewhere in the page. A page that embeds another vendor's snippet, such as a widget or a script loaded only under some condition, can show that vendor even though the site doesn't run on it. Markers are chosen to limit this. For example, Shopify is detected from theme and store-asset paths, not from any mention of cdn.shopify.com. The evidence field shows exactly what matched, so every detection can be checked.

Why does txt show "verification" entries as technologies? google-site-verification=, MS=ms…, stripe-verification= and similar tokens show that the domain owner verified the domain with that service. That is a strong signal the service is in use. The evidence field always shows where each detection came from.

Can I use the registration data for cold outreach? Registries publish RDAP under terms that forbid using it for unsolicited commercial messages and for high-volume abuse of their systems. This actor rate-limits itself per registry and returns no contact data. You are responsible for how you use the results.

Use with AI agents / MCP

This actor is built to be called as a tool by AI agents through the Apify MCP server:

• Lenient input: agents can send URLs, e-mail addresses, mixed-case domains or {"url": ...} objects, and use aliases (domain, urls, tech, limit) that also accept plain strings. Bad values get a free explanatory row instead of a failed run.
• Small, flat, stable output: one row per domain, with the same keys every time and self-describing field names. Nothing is nested except the tech list of {name, category, evidence}.
• Clear cost: $0.013 for a single-domain check, $0.003 for each additional domain ($0.004 in tech mode).
• Called with no input at all ({} or an empty domains list), the actor checks apify.com as an example for $0.013 and the row's note says so. If the input has data only under field names the actor doesn't recognise, nothing is charged: a free row names those fields instead.
• Short timeouts and budgets are safe: a 30 s run timeout still checks a few domains. When the maximum charge or the timeout cuts a run short, a free not_checked row explains it, so an agent that reads only the dataset still learns why.

Example agent call:

{ "domains": ["acme.com"], "techStack": true }

Typical prompts include "Is acme.com's email protected against spoofing?", "When does this domain expire and who is the registrar?", "Which of these 200 domains use Microsoft 365?" and "What CMS and analytics does this site run?"

Data sources

Data	Source
RDAP server lookup	IANA RDAP bootstrap, loaded once per run
Registration data	each registry's own RDAP server (e.g. rdap.verisign.com, rdap.publicinterestregistry.org, rdap.nominet.uk)
Registered-domain split and TLD list	Public Suffix List, ICANN section, loaded once per run (with a built-in fallback); unknown TLDs are confirmed against the DNS root
DNS	the system resolver, with 1.1.1.1 / 8.8.8.8 as fallback
MTA-STS policy	https://mta-sts.<domain>/.well-known/mta-sts.txt (RFC 8461), fetched only when the _mta-sts TXT record exists
TLS certificate	a direct TLS handshake to port 443
Tech stack	one GET of the domain's homepage (no cookies kept)

All requests identify themselves with the User-Agent bigdavidson-apify-actor/domain-intel-bulk (+https://apify.com/bigdavidson).

Unofficial: not affiliated with IANA, ICANN, any domain registry or registrar, or any vendor whose technology is detected. All names are trademarks of their owners.

Changelog

• 0.1 (2026-09-24): first release. RDAP (IANA bootstrap plus the .io/.me/.ac/.sh/.us registry servers), DNS (A/AAAA/MX/NS/TXT/CAA), mail and DNS provider inference, email security grade (SPF with a recursive lookup count, DMARC with organizational fallback scored on the parent's sp= policy, MTA-STS policy, TLS-RPT, BIMI, common DKIM selectors), TLS certificate check, and an optional tech-stack mode. Each section has its own time limit, so slow registries or homepages produce partial rows instead of lost ones. not_in_dns status for names that don't exist in DNS when the registry can't confirm them as unregistered. A free not_checked row appears when the maximum charge or the timeout cuts a run short. Decompression is size-capped. Runs resume without double charges after a platform migration.