Free vs business email addresses
A free email address is one at a provider that gives anyone a personal mailbox, such as Gmail, Outlook.com or Yahoo; a business address sits on the company's own domain. B2B teams ask for work email because the domain tells them which company a lead belongs to. Blocking free addresses outright, though, also turns away freelancers, sole traders and small firms that run their business from a personal mailbox, and it invites people to invent a work address instead. In most forms it works better to accept both, ask for the company separately, and use a free-provider flag to route leads rather than reject them.
What counts as a free provider
Our glossary defines a free email provider as a service that gives anyone a personal mailbox at no cost. In practice, lists of such domains reach well beyond the big three. HubSpot's list of domains it blocks when a form refuses free providers includes, for example:
- the large webmail services:
gmail.com,outlook.com,hotmail.com,yahoo.com,aol.com,icloud.com; - privacy-focused and regional providers:
proton.me,gmx.de; - mailboxes from internet service providers:
comcast.net.
Two cases cause confusion:
- Company mail hosted by a big provider. A company that runs its mail on Google Workspace or Microsoft 365 uses its own domain, so
jane@company.exampleis a business address even though Google or Microsoft hosts the mailbox. What decides it is the domain, not the mail server behind it. - Personal mailboxes that are not free. Paid personal services and custom domains such as a family name are personal too, but they rarely appear on free-provider lists. No list is complete, and lists change as providers appear and disappear.
Why B2B teams ask for work email
The reasons are practical:
- Company matching. A work domain links the lead to an account in the CRM, to a sales territory and to the colleagues who already signed up. A
gmail.comdomain is shared by unrelated people all over the world and links to nothing. - Routing. Sales teams want demo requests from companies they can sell to, and the domain is the quickest signal of which company that is.
- Fewer throwaway sign-ups. A trial that asks for a work address gets fewer one-off accounts. Note that disposable addresses are a separate problem from free ones: a disposable inbox is meant to be thrown away, a Gmail account usually is not.
Why blocking free addresses loses real buyers
Forms that refuse free providers are common enough that HubSpot offers it as a switch: with Block free email providers turned on, a visitor with a blocked domain is asked to enter a different address before the form submits. Before you turn on such a switch, think about who meets it:
- Sole traders, freelancers and consultants who never set up a company domain, or who use their personal mailbox for everything.
- Founders of new companies that do not have a domain or mail setup yet.
- People at large companies who research a product from home, or who do not want sales calls at work yet.
- Buyers in sectors where staff do not get a company mailbox for every role.
Some of these leave. Others type an address that passes the rule but is not theirs, or not real. That is worse than a Gmail address: a made-up name at a real company domain bounces later, or, on a domain that accepts mail for every address, cannot be confirmed at all. You trade a lead you could have reached for one you cannot.
Better options than a hard block
- Ask for the company in its own field. A company name or website field gives sales the account without restricting the email address. Keep it optional where you can.
- Use a soft prompt. When someone enters a free address, show a short note such as "Using a work address helps us connect you with your team," and still accept the submission.
- Route instead of rejecting. Send free-address leads into a self-serve or nurture track, and leads on company domains to sales. Re-score a lead when the person later adds a company.
- Enrich business domains only. Looking up a company from its domain works for business addresses; for free ones, ask the person instead. Enrichment that adds data about a person comes with duties (see privacy and consent). Never append email addresses to records from another source: M3AAWG calls email appending abusive.
- Require a work domain only where the product needs it, for example to put colleagues into one team workspace. A newsletter or a whitepaper download rarely needs it.
Company domains: role and catch-all addresses
A business domain does not make an address safe to mail. Two things are common on company domains:
- Role addresses such as
sales@orinfo@belong to a team, not a person. They carry therole_accountflag, and a working one can come backvalidwith the reasonrole_accountand the actionsend_with_caution. They are fine for replying to an inquiry and less suited to marketing (role-based addresses). - Catch-all domains accept mail for every address, so no check can confirm that a particular mailbox exists. The status is
catch_allwith the actionsend_with_caution. A made-up name at such a domain looks the same as a real one (catch-all emails).
Only a confirmation email proves that a person controls the address, whatever the domain (double opt-in). And consent to marketing depends on how you collected the address, not on whether it is personal or business (bought email lists).
Our free-provider flag
Every result of the validation API has a field free_email, which the API reference describes as true when the domain is a free consumer mailbox service. Bulk results carry it as the column ev_free_email. An excerpt of a result for a Gmail address that accepts mail:
{
"status": "valid",
"reason": "accepted",
"action": "send",
"free_email": true,
"role_account": false
}The flag is a description, not a verdict: whether to send still follows the action field. For a malformed address the flags are null, and an unknown result can carry fields the check learned before it stopped, so rely on status and reason there. In a form, read the flag after the deliverability decision from the sign-up form recipe and use it for routing or a soft prompt.
Privacy and consent
- Both kinds are personal data. Under the GDPR, personal data is any information about an identified or identifiable person (Article 4). A work address with someone's name in it identifies them as much as a personal one.
- Ask for what you need. Data minimisation (Article 5(1)(c)) asks that data be adequate, relevant and limited to what is necessary for your purpose. Each required field on a form should have a reason.
- Tell people about enrichment. When you obtain personal data from a source other than the person, Article 14 requires you to inform them within a reasonable period, at the latest within one month, or at your first message to them if sooner, and to name the source.
- Say why you prefer a work address. If you prompt for one, explain the benefit to the person in a few words rather than implying their address is not good enough.
This is general information, not legal advice; the rules that apply depend on where you and your leads are.
Questions
Should I block Gmail addresses on a demo request form?
Usually not. Accept them, ask for the company in a separate field, and route the lead by what you learn. Block only when your product truly needs a company domain, and say why.
Is a Google Workspace address a free email address?
No. It uses the company's own domain, so it is a business address, even though Google hosts the mailbox.
Does a business domain mean the address exists?
No. The mailbox can be missing, a role address or on a catch-all domain. Check it, and confirm it with an email when it matters.
Try it
Enter an address in the free email checker to see its status and flags, or add the check to your form with the email verification API.
Related
Related guides
- Role-based email addresses
- Catch-all emails explained
- Disposable email addresses explained
- Double opt-in (confirmed opt-in)
- Why bought email lists fail
- All guides
Sources
- HubSpot: Block form submissions from specific email domains or free email providers: how the block works and what visitors see.
- HubSpot: Domains blocked from form submissions: examples of domains on a free-provider list.
- M3AAWG: Sender Best Common Practices, version 4.0 (August 2026): section 4.4 on email append.
- GDPR Article 4 (gdpr-info.eu): definition of personal data.
- GDPR Article 5 (gdpr-info.eu): data minimisation.
- GDPR Article 14 (gdpr-info.eu): informing people about data from other sources, and its time limits.
How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.