Free email provider domains: the list that actually matters

The free email provider list that matters for most products is short: about a dozen provider families (Google, Microsoft, Yahoo, Apple, AOL, Proton, GMX and its sister brands, Yandex, Mail.ru, the big Chinese and Korean portals) and their regional variants, which comes to roughly a hundred domains. The 30,000-domain lists you find on GitHub answer a different question, because they merge webmail, disposable and ISP domains into one bucket. Use a short, curated webmail list, keep disposable and ISP domains in separate lists, and tune the regional part to where your users actually are.

The domains, grouped by provider

This is the core list pingutil uses for its free category (103 domains at the time of writing), grouped so you can see why each one is there. Copy it, then adjust for your audience.

A few entries need explaining.

• googlemail.com is still live. Its MX records point at the same gmail-smtp-in.l.google.com hosts as gmail.com. You'll see it on older accounts, so leave it in.
• Proton has a fourth domain. Proton's support page on addresses lists protonmail.ch as its original domain, still the default for accounts created before 2016, and says pm.me addresses are a paid-plan option. Our list above misses protonmail.ch; add it to yours.
• "Free" is the wrong word. Fastmail's pricing page offers a 30-day trial and no free plan, and HEY costs $99 a year. They're on the list anyway, because the list exists to separate personal mailboxes from company domains, and price has nothing to do with that.
• duck.com is a forwarding address. DuckDuckGo's service relays mail to the user's real inbox. Some disposable lists include it, which we think is a mistake: relays have real people behind them. More on that in why relay services are not disposable email.
• Some French and German domains blur into ISPs. t-online.de, free.fr and wanadoo.fr started as ISP mail. We keep them here because people use them as everyday personal addresses, while carrier mail domains like orange.fr and comcast.net sit in a separate ISP list.

Why the 30,000-domain lists are a different tool

Search for a "free email provider list" and you'll land on lists an order of magnitude bigger. Two examples:

• Kikobeats/free-email-domains had 33,308 entries when we downloaded it on 12 October 2026. Its own description says it covers "free and disposable email domains in a single list". It includes mailinator.com and yopmail.com (throwaway inboxes) and comcast.net (an ISP).
• HubSpot's "Block free email providers" form setting is backed by a list you can download as a CSV from its knowledge base. It includes ISP domains such as att.net and btinternet.com.

These are fine for one job: "accept only addresses that are probably corporate." If that's all you need, a merged list is simpler, and the bigger the better.

They're the wrong tool as soon as your logic needs to know why an address isn't corporate. You probably want to:

• block throwaway inboxes but accept Gmail,
• treat an ISP address as a consumer, but not as a fraud signal,
• route webmail leads to self-serve and company leads to sales.

A merged list can't do any of that. Keep three lists (webmail, disposable, ISP) and combine them in code when you want the merged answer. ISP domains have their own quirks, covered in why comcast.net is not a company, and the ISP domains page shows what pingutil currently treats as one.

The regional part is where your list should differ from ours

A list built in the US will under-cover your users in Poland or Korea. The fix is cheap: look at your own data. This query (Postgres) gives the domains your users actually sign up with:

SELECT lower(split_part(email, '@', 2)) AS domain,
       count(*)                          AS signups
FROM users
WHERE created_at > now() - interval '90 days'
GROUP BY 1
ORDER BY 2 DESC
LIMIT 300;

Go down the output and label every domain you don't recognise. A provider domain looks different from a company domain in your data: its users don't invite each other, don't share workspaces and sign up from all over the map. Forty signups from one company domain tend to cluster into a few teams.

Then check the mail hosts for the ones you're unsure about. Providers often run many domains on the same servers:

for d in engineer.com consultant.com usa.com myself.com email.com; do
  echo "$d -> $(dig +short MX "$d" | sort | head -1)"
done
# engineer.com -> 10 mx00.mail.com.
# consultant.com -> 10 mx00.mail.com.
# ...

The long tail you can't list

mail.com is the clearest example. Free users pick from a large catalogue of vanity domains that read like professions or places, and every one we checked (engineer.com, consultant.com, usa.com, myself.com, email.com) resolves its MX to mx00.mail.com and mx01.mail.com. None of them is on our list above, so pingutil currently categorizes them as company. We'd rather say that than pretend a static list covers everything.

You can't enumerate these catalogues reliably, and they change. Match on MX hosts instead: if the domain's mail goes to a consumer-only host such as mail.com's, gmx.net's or mail.icloud.com, treat it as personal regardless of the domain name. The TypeScript for that check is in how to tell a business email from a personal one in code. Don't extend the idea to Google or Microsoft hosts: their MX servers handle business customers on custom domains too.

Keeping the list honest

• Store it as data, not a hard-coded array in a validator, so ops can add a domain without a deploy.
• Re-run the signup query every quarter and label new high-volume domains.
• Log the reason whenever the list changes an outcome (blocked, routed, scored), so a wrong entry shows up in reviews.
• Version it. When someone asks why a lead was routed to self-serve in March, you want to know what the list said in March.

If you'd rather not maintain it, pingutil returns category: "free" for these domains, with ISP and disposable domains in their own categories; the current webmail set is on the free email providers page. Whether to reject any of these addresses is a separate, mostly commercial decision, which we cover in should your B2B signup form require a work email.