ISP email domains: why comcast.net is not a company

comcast.net is the domain Comcast gives its residential internet customers for email, so an address on it tells you who sells that person broadband, not who employs them. The same goes for att.net, btinternet.com, orange.fr, bigpond.com and dozens more. Treat ISP domains as personal addresses, exactly like Gmail, and never send them through company enrichment, because the enrichment will succeed and return the ISP itself.

That last part is the whole problem. Webmail domains fail loudly. ISP domains fail quietly.

How ISP domains poison a company pipeline

Most "is this a business email?" checks are a blocklist of free webmail providers followed by an assumption: anything not on the list is a company. ISP domains slip through, because nobody thinks of them as webmail.

Follow a single address through a typical inbound pipeline:

1. pat.walsh@comcast.net requests a demo.
2. Your form checks a free-provider list. comcast.net isn't on it, so the lead is tagged "business".
3. Enrichment resolves comcast.net to Comcast: a large, public telecom and media company.
4. Routing sends the lead to the enterprise team because of the company's size.
5. Your CRM attaches Pat to the "Comcast" account, alongside every other residential customer who ever filled in a form.

Every step did its job. The result is still wrong, and expensive: an enterprise rep's time spent on someone who may be a hobbyist, and an account record that blends hundreds of unrelated people. If you run teammate detection ("three signups from the same domain, offer a team plan"), ISP domains will also generate fake teams out of neighbours who share a provider.

Webmail domains don't cause this because enriching gmail.com returns Google, and everyone already knows to exclude it. ISP domains look like plausible corporate domains to anyone who isn't in that country.

Which domains count

There's no canonical list. ISPs merge, rebrand and outsource their mail, and the old domains keep working long after. pingutil ships about 60 consumer ISP mail domains in the ISP category. Grouped by market, the list currently includes:

A few things stand out once you look at it as a list:

• Many are legacy brands. sbcglobal.net, pacbell.net, bellsouth.net and ameritech.net are names from telephone companies that were merged into AT&T years ago. wanadoo.co.uk and club-internet.fr are similar. People keep these addresses for a long time because changing your email is a chore.
• Some ISPs no longer run their own mail. Verizon's email policy says plainly: "We no longer offer verizon.net email service". Customers who wanted to keep their address migrated it to AOL Mail by December 2017. Cox announced in late 2023 that it was moving cox.net mailboxes to Yahoo Mail. The domains still receive mail, but the "ISP" in "ISP email" is now a historical fact about the account.
• A few overlap with company websites. telstra.com, sky.com and frontier.com are also the corporate web domains for those companies. On a pure domain lookup you can't tell a consumer mailbox from an employee. The list treats them as ISP on the assumption that a signup from one of them is a customer rather than an employee. That's a judgment call, and pingutil returns the ISP category with medium rather than high confidence partly for this reason.

Germany and Italy are mostly absent from this table for a reason: their big consumer mail providers (t-online.de, gmx.de, web.de, libero.it) behave like webmail and are classified as free email providers instead. Whether a domain lands in "ISP" or "free" is less important than making sure it lands in one of them.

How to treat an ISP address

Same as webmail for anything to do with companies, with one small difference.

The difference is the last row. btinternet.com suggests the UK and bigpond.com suggests Australia, because those accounts typically started with a broadband subscription in that country. It's a weak hint (people move, and the address moves with them), but it's more than Gmail gives you. Don't use it for anything stricter than a default timezone or currency guess.

On the fraud side, ISP addresses are boring in a good way. They aren't disposable addresses, and nothing about the domain suggests abuse, so they shouldn't be penalized. If you're excluding them from a "work email only" signup, do it for product reasons, and read whether your B2B signup should require a work email first.

A small business on an ISP address is still a business

Some sole traders and very small businesses do use their broadband provider's address as their business contact. Nothing in the domain can tell you that. If your form also asks for a company name, use that as the company signal for ISP and webmail addresses instead of the domain, and enrich from the company name only if your tooling supports it.

Implementing the check

Match on the registrable domain, not the full host. Subdomains exist (mail.comcast.net) and you want them to collapse to the same entry. Use a Public Suffix List library so that bigpond.net.au stays bigpond.net.au instead of becoming net.au.

// npm install tldts
import { parse } from 'tldts';

const ISP = new Set([
  'comcast.net', 'xfinity.com', 'verizon.net', 'att.net', 'sbcglobal.net',
  'bellsouth.net', 'cox.net', 'charter.net', 'rr.com', 'earthlink.net',
  'btinternet.com', 'talktalk.net', 'virginmedia.com', 'sky.com',
  'orange.fr', 'sfr.fr', 'bigpond.com', 'optusnet.com.au', 'rogers.com',
  'sympatico.ca', 'shaw.ca', 'telus.net',
  // ...extend with the full table above
]);

export function isIspEmail(email) {
  const host = email.slice(email.lastIndexOf('@') + 1).toLowerCase();
  const { domain } = parse(host);
  return domain !== null && ISP.has(domain);
}

isIspEmail('pat.walsh@comcast.net');   // true
isIspEmail('pat@mail.comcast.net');    // true
isIspEmail('pat@acme.com');            // false

Order matters if you combine lists. Check disposable first, then free webmail, then ISP, and only then assume "company". That's the order pingutil uses, and an ISP domain comes back with category: "isp" and company: null, so no enrichment is attempted:

curl -X POST https://pingutil.com/v1/lookup \
  -H "Authorization: Bearer $PINGUTIL_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "input": "pat.walsh@comcast.net", "skip_enrichment": true }'
# "category": "isp", "company": null, "verdict": { "is_spam": false, ... }

Cleaning up the damage you already have

If ISP domains have been treated as companies in your CRM for a while, you probably have a few large, fake "accounts" made of unrelated residential customers. Find them by grouping contacts by email domain and checking the biggest groups against the table above. Detach those contacts from the account, clear any enriched firmographics that were copied onto them, and re-run routing. The same exercise usually turns up webmail and university domains that were grouped the same way; CRM data hygiene by email domain walks through the full cleanup.

Then add the ISP check to the start of your pipeline, before enrichment, so the next comcast.net lead goes to the right queue on the first try.