Skip to content
pingutil

What is domain intelligence? A practical definition

· 6 min read · Company enrichment

Domain intelligence is the set of facts you can derive about a domain name: what kind of domain it is (company, webmail, disposable, university, government), whether it actually works (DNS, mail, website), who registered it and when, whether it has a bad reputation, and which organisation sits behind it. In practice it is a pipeline of cheap checks that turns an opaque string like acme-logistics.de into something your code can make a decision on. The term is used by both security teams and go-to-market teams, and they mean slightly different things by it.

This post breaks domain intelligence into layers, says where each layer's data comes from, and points out where each one fails. If you only remember one thing: order the layers by cost and stop as soon as you have enough to decide.

Two audiences, one input

Security and fraud teams use "domain intelligence" to mean registration history, passive DNS, hosting changes and blocklist hits. The question is "is this domain part of an attack?".

Product, growth and RevOps teams use it to mean classification and firmographics. The question is "is this a real business, and which one?".

Both start from the same string and many of the same lookups. The difference is the last mile: a threat analyst wants to know a domain was registered three days ago on a bulk registrar; a sales team wants to know it belongs to a 200-person logistics company in Hamburg. This post leans toward the second group, but the early layers apply to both.

The six layers

Layer Question it answers Typical source Cost How it fails
1. Normalization Which domain is this, really? Public Suffix List, IDN conversion Microseconds, local Stale suffix list, odd input
2. Classification What kind of domain is it? Curated lists, TLD rules Microseconds, local New disposable domains not yet listed
3. Infrastructure Does it resolve, receive mail, serve a site? DNS (MX, A/AAAA) One network round trip, cacheable Catch-all mail, parked domains
4. Registration Who registered it, and when? RDAP (formerly WHOIS) One request per lookup, rate-limited Privacy redaction, ccTLD gaps
5. Reputation Has it been seen doing bad things? Abuse feeds, commercial scoring Usually paid Coverage gaps, false positives on shared infra
6. Ownership Which company is this, and what do they do? Commercial databases, LLMs, public web Slowest, most expensive Wrong company, stale facts

1. Normalization

Everything downstream is keyed on the domain, so get the key right. Lowercase it, convert internationalized names to punycode, strip www., and reduce subdomains to the registrable domain using the Public Suffix List. mail.stripe.com is stripe.com. foo.co.uk is a registrable domain; co.uk is not. The full reasoning is in eTLD+1 explained.

Skip this step and your cache hit rate drops, your blocklist misses sub.mailinator.com, and two contacts from the same company look unrelated.

2. Classification

Is this a company domain, or something else? Most of the value here comes from boring lists:

  • Free webmail providers (gmail.com, outlook.com, yahoo.co.jp, and on the order of a hundred more).
  • Disposable inbox services. The community-maintained disposable domain list is several thousand entries and grows every week.
  • Consumer ISP mail domains like comcast.net or btinternet.com, which look like companies but aren't.
  • Rule-based categories: .edu, .ac.uk, .gov, .gouv.fr and friends.

Lists are fast and explainable. Their weakness is freshness: a disposable service that launched last Tuesday is not on anyone's list yet. That is what the next layers are for.

3. Infrastructure

DNS tells you whether the domain is real and set up for email. An NXDOMAIN response means the domain doesn't exist. No MX record (and no A record to fall back on) means it can't receive mail. No A or AAAA record on the apex or www means there is no website, which is unusual for a real business.

You can query DNS from anywhere that speaks HTTPS. Cloudflare's resolver has a JSON interface:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=stripe.com&type=MX'

"Status": 0 means the name resolved; "Status": 3 is NXDOMAIN. The Answer array holds the MX hosts. More detail, including the A-record fallback rule from RFC 5321, is in checking MX records.

Infrastructure checks have a known blind spot: a domain that resolves and has MX records can still be a throwaway. Disposable services run perfectly valid mail servers.

4. Registration

Registration data answers "who owns this and how old is it?". Domain age is one of the more useful fraud signals, because abuse domains tend to be young.

The protocol changed recently. ICANN made RDAP the definitive source for gTLD registration data and sunset the WHOIS obligations on 28 January 2025. RDAP returns JSON (the format is defined in RFC 9083), which is much easier to parse than free-text WHOIS. The public bootstrap service at rdap.org will redirect you to the right registry:

curl -sL https://rdap.org/domain/stripe.com | jq '.events'

The events array includes the registration date. Two caveats. Registrant contact details are usually redacted, so "who" is often unanswerable. And country-code TLDs are not bound by ICANN's gTLD contracts, so coverage for .de, .io and similar varies by registry.

5. Reputation

Reputation is the record of what a domain has been seen doing: spam, phishing, mass signups. This data is mostly commercial, because collecting it requires traffic at scale. It catches things lists miss, and it also produces the most arguable false positives, particularly for domains on shared infrastructure.

Treat a reputation hit as a strong signal, not proof, and log which provider flagged what so you can explain a decision later.

6. Ownership

The last layer maps a domain to an organisation: name, industry, size, headquarters, funding, social profiles. This is what most people call company enrichment, and it is the expensive layer by a wide margin.

There are three ways to get it. A commercial database that someone keeps current. A language model that fills a schema from what it knows (or from a web search). Or your own scraping of the company's homepage and public profiles. Each has a different failure profile; we compare them in free company enrichment APIs, and the accuracy question gets its own post in how accurate LLM-based enrichment is.

The failure mode that matters most here is confidently wrong data. A missing employee count is harmless. An employee count belonging to a different company with a similar name gets a lead routed to the wrong rep.

Stop at the cheapest layer that decides

The layers are ordered by cost on purpose. A signup form screening for abuse rarely needs anything past layer 3. A lead router needs layer 6, but only for domains that survive layers 1 and 2: there is no point paying to enrich gmail.com.

A reasonable flow for a B2B signup:

  1. Normalize. Reject invalid input.
  2. Classify. Block disposable, tag free/ISP/edu/gov, pass company domains on.
  3. For company domains, check DNS. A domain that doesn't exist or can't receive mail is a hard stop.
  4. Enrich ownership asynchronously, after the user is in, and cache the result per registrable domain.

Registration and reputation slot in wherever your risk tolerance says. Fraud-heavy products put them before signup completes; most B2B tools can run them later.

What pingutil covers

pingutil is our free API that bundles several of these layers behind one call. It normalizes to the registrable domain, classifies against lists and TLD rules, optionally checks DNS over HTTPS, optionally consults a reputation provider, and for company domains fills a company profile using an LLM. It does not do RDAP or registration history, and it has no person-level data.

curl -X POST https://pingutil.com/v1/lookup \
  -H "Authorization: Bearer pk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "input": "jane@stripe.com", "check_dns": true }'

The response gives you category, domain_signals (domain_exists, can_receive_email, has_website), a verdict for spam screening, and a company object with a confidence score you should read before trusting the profile. The full field list is in the API reference.

A checklist for your own stack

  • Key every cache and every rule on the registrable domain, never the raw host.
  • Keep classification local and fast; refresh your lists on a schedule.
  • Run DNS checks for company domains only, and cache them for days, not minutes.
  • Use RDAP for domain age if fraud matters to you, and expect redacted contacts.
  • Treat reputation hits as evidence, with the source logged.
  • Enrich ownership last, asynchronously, and store the confidence alongside the data.

Questions people ask

Is domain intelligence the same as threat intelligence?
They overlap. Security teams use domain intelligence for threat hunting (registration history, passive DNS, hosting changes), while product and revenue teams use it to classify signups and identify companies. The raw inputs are similar; the questions asked of them are different.
Can I get domain intelligence from an email address?
Yes. Take the part after the @, reduce it to the registrable domain, and run the same checks you would run on a bare domain. The local part adds its own signals, such as role addresses or machine-generated strings.
Do I need WHOIS for domain intelligence?
Less than you might think. Most gTLD registration data is now served over RDAP rather than WHOIS, much of it is redacted for privacy, and for signup screening or lead enrichment DNS and classification usually tell you more.