WHOIS Lookup & DNS Checker – Domain Age, SPF, DMARC, SSL avatar

WHOIS Lookup & DNS Checker – Domain Age, SPF, DMARC, SSL

Pricing

from $2.50 / 1,000 domains

Go to Apify Store
WHOIS Lookup & DNS Checker – Domain Age, SPF, DMARC, SSL

WHOIS Lookup & DNS Checker – Domain Age, SPF, DMARC, SSL

Bulk WHOIS lookup via official RDAP plus DNS checker: domain age, expiry, registrar, nameservers, DNS records, SSL expiry and an email security grade A-F (SPF, DMARC, DKIM) with plain-English issues. Never WHOIS contact data.

Pricing

from $2.50 / 1,000 domains

Rating

0.0

(0)

Developer

Rowfeed

Rowfeed

Maintained by Community

Actor stats

0

Bookmarked

1

Total users

1

Monthly active users

5 days ago

Last modified

Features

Limited permissions

Share

Check how old a domain is, whether it is registered, when it expires, who the registrar is, how its DNS and SSL are set up, and how well its email is protected against spoofing (SPF, DMARC, DKIM, graded A to F) - straight from the official RDAP registries, DNS-over-HTTPS, and a direct TLS handshake. Built for scripts, dashboards, portfolio monitors and AI agents that need a clean, typed answer, not a scraped WHOIS text blob.

No WHOIS contact data, ever. Only the registrar - a company - comes out of this Actor.

What you get

  • Domain age - domain_age_years (e.g. 19.1) from the registration date, for bulk domain age checks.
  • Registration status and expiry - is_registered, expires_at, days_until_expiry (negative once a domain has lapsed), created_at, updated_at, EPP statuses, and which registry RDAP server actually answered (rdap_server).
  • Registrar, nameservers, DNSSEC - the registrar company name and IANA Registrar ID, the domain's nameservers, and whether DNSSEC is signed.
  • DNS and mail posture - A/MX/NS/TXT records over Cloudflare DNS-over-HTTPS, the mail provider inferred from MX hostnames (Google Workspace, Microsoft 365, Proofpoint, ...), and whether SPF and DMARC are present. Optionally, live TLS certificate issuer and expiry.

Email security check: SPF, DMARC and DKIM, graded A to F

With DNS lookups on (the default), every registered domain gets a mail_auth block at no extra cost (example: nrk.no, 05.11.2026). Use it as a bulk DMARC checker, SPF checker or DKIM checker for client audits, deliverability work, sales prospecting or a security review.

"mail_auth": {
"grade": "C",
"issues": ["DMARC policy is p=none: spoofed mail is only reported, not blocked"],
"spf_record": "v=spf1 mx a ip4:160.67.135.178 ... include:spf.protection.outlook.com include:_spf.google.com -all",
"spf_all": "-all",
"spf_lookup_terms": 7,
"dmarc_record": "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@nrk.no; ...",
"dmarc_policy": "none",
"dmarc_subdomain_policy": null,
"dmarc_pct": 100,
"dmarc_reports": true,
"dkim_selector": "google"
}
GradeDMARCSPF
Ap=quarantine or p=reject on 100 % of mail, with reports (rua)good
Benforced, but no reports, pct below 100, or SPF weak or missingany
Cp=none (spoofing is reported, not blocked)good
Dp=none with weak or missing SPF, or DMARC missing/duplicated with good SPF
Fmissing or duplicatedweak or missing

Good SPF = exactly one record that ends in -all or ~all (or hands over with redirect=) and has at most 10 lookup terms. Weak SPF = +all, ?all, no all, or too many lookups. Several SPF records count as missing. A DMARC record without a valid p= counts as p=none, as the DMARC standard says. If a DNS lookup fails, mail_auth is null (not graded) rather than a wrong grade.

issues lists each problem found, in plain English. Measured 05.11.2026: microsoft.com and github.com get A, nrk.no gets C (p=none), and a domain with neither record gets F.

DKIM keys are published under a "selector" that cannot be listed, so the Actor tries the selectors of the mail service it detects (Google Workspace, Microsoft 365) or two common defaults. dkim_selector shows the one found. null means none of those was found, which does not prove that DKIM is missing, so DKIM never lowers the grade. spf_lookup_terms counts the lookups in the top-level SPF record only. Nested includes add more.

Why RDAP instead of WHOIS

RDAP is the IETF's structured, machine-readable replacement for WHOIS, served directly by the registries (rdap.org resolves and redirects to the authoritative server for each TLD). WHOIS scrapers parse inconsistent free text and, along the way, usually pick up registrant/admin/tech contact details. This Actor never fetches or forwards those fields: the fetch layer's registrar extractor only ever reads the entity whose role is "registrar", and only ever takes its company name and IANA ID from that entity - never a registrant, admin or tech contact, never an email or phone number of a named individual, and never the registrar's own nested abuse-contact sub-entity. That is deliberate: privacy by design, and the reason this tool is cheaper and cleaner to build a product on top of than a service that resells WHOIS contacts.

Example output row

One real row from a default run (github.com, 2026-09-23; the TXT array is trimmed here for readability - the real dataset row has all of them):

{
"domain": "github.com",
"tld": "com",
"is_registered": true,
"registrar_name": "MarkMonitor Inc.",
"registrar_iana_id": "292",
"statuses": ["client delete prohibited", "client transfer prohibited", "client update prohibited"],
"created_at": "2007-10-09T18:20:50Z",
"updated_at": "2026-09-07T09:22:52Z",
"expires_at": "2028-10-09T18:20:50Z",
"days_until_expiry": 747,
"domain_age_years": 19.1,
"nameservers": [
"DNS1.P08.NSONE.NET", "DNS2.P08.NSONE.NET", "DNS3.P08.NSONE.NET", "DNS4.P08.NSONE.NET",
"NS-1283.AWSDNS-32.ORG", "NS-1707.AWSDNS-21.CO.UK", "NS-421.AWSDNS-52.COM", "NS-520.AWSDNS-01.NET"
],
"dnssec": false,
"rdap_server": "rdap.verisign.com",
"dns": {
"A": ["140.82.121.4"],
"MX": ["0 github-com.mail.protection.outlook.com."],
"NS": ["dns1.p08.nsone.net.", "dns2.p08.nsone.net.", "..."],
"TXT": ["\"google-site-verification=...\"", "\"v=spf1 ip4:192.30.252.0/22 ... ~all\"", "..."]
},
"mail_provider": "Microsoft 365",
"spf_present": true,
"dmarc_present": true,
"checked_at": "2026-09-23T11:35:20+00:00"
}

An unregistered domain gives a clean, non-error row instead of a crash or a false positive:

{
"domain": "zzz-not-a-real-domain-98765.com",
"tld": "com",
"is_registered": false,
"registrar_name": null,
"rdap_server": "rdap.verisign.com",
"...": "every other RDAP field is null/empty, no `error` field"
}

is_registered: false is a normal, common answer, not an error - it means the registry itself said the domain does not exist. If instead an RDAP server is unreachable or times out, you get a genuinely different row: {"domain": ..., "error": "network", "errorMessage": "..."}. The two are never conflated, so a downstream buyer can trust is_registered: false as ground truth.

Three answers, never two

Some top-level domains publish no RDAP service at all - .mil and a handful of others. For those, nobody can tell you whether a domain is registered, so this Actor says exactly that instead of guessing. .io, .sh and .ac are a special case: IANA's RDAP list leaves them out, so most tools report them as unknown or, worse, as free - but their registry does answer RDAP, and this Actor asks it directly, so you get the real registrar, expiry date and nameservers. Every row carries one of three answers:

rdap_statusis_registeredWhat it means
registeredtrueThe registry returned the domain record
not_registeredfalseThe registry said the domain does not exist
no_rdap_servicenullThe TLD publishes no RDAP service, so registration is unknown

DNS records, mail provider, SPF, DMARC and the TLS certificate are still returned in the no_rdap_service case, because those come from other sources and are just as real.

This matters more than it sounds: a tool that trusts the IANA list either says every .io domain is unknown or tells you a live, paid-for .io domain is free. Check any .io domain here and compare.

You can download the dataset in various formats such as JSON, CSV, or Excel from the Apify Console, or pull it through the API/integrations.

Input

  • Domains (domains) - bare domains or full URLs (github.com, https://github.com/x); the scheme, path, query and port are stripped automatically. Default: github.com, apify.com, example.org.
  • Max domains (maxDomains) - cap on rows checked, 1-1000. Default 100.
  • Include DNS lookups (includeDns) - resolve the record types below plus a dedicated _dmarc.<domain> TXT lookup (plus a few DKIM selector lookups when the domain has MX records), and add mail_provider, spf_present, dmarc_present and the graded mail_auth block. Free, part of the domain event. Default on.
  • DNS record types (dnsTypes) - which record types to resolve. Default A, MX, NS, TXT.
  • Include TLS certificate check (includeTls) - open a TLS connection to port 443 and read the certificate's issuer and expiry. One extra tls-check event per successful check. Default off.

The default input runs with zero edits and returns three real, valuable rows.

Pricing

Pay-per-event:

  • Actor start - $0.001, once per run.
  • Domain - $0.0025 per domain row (registration, expiry, registrar, DNS, SPF/DMARC/DKIM grade).
  • TLS check - $0.001, only when includeTls is on and a certificate was actually read.

$2.50 per 1,000 domains checked - no charge for domains that turn out to be unregistered failing silently, and no charge for a WHOIS-contacts add-on you didn't ask for, because there isn't one.

Reliability and rate limits

Requests stay under ~5/second overall. 429s and 5xx/network errors retry with exponential backoff (429 honours Retry-After); 401/403 and other unexpected responses are reported once, not retried. Every failure is counted by category (network, rate_limit, blocked, other) in the run's STATS key-value record, separately from not_found/unregistered-domain counts, so you can tell input problems (typo'd domains) apart from source outages at a glance.

More SEO tools from Rowfeed

⌂ 换网址