Some events aren't meant for a list of specific people. They're meant for specific organizations. A customer summit should be full of customers, not competitors doing research. A partner enablement day is for people at your partner firms. An internal training should only take registrations from your own company. Inviting each person by name doesn't scale, and leaving registration fully open lets anyone with the link sign up. Restricting event registration by email domain sits in between: you decide which organizations can register (or which can't) based on the part of the email address after the @, and Sunfish Events checks it before anyone gets through.

What it means to restrict event registration by email domain

Every email address has two parts: the person (Jane) and the domain (acme.com). A domain rule ignores the person and looks only at the domain. That makes it a different tool from an invite list.

An invite list answers "is this exact person allowed?" You need every address in advance. A domain rule answers "is this person from an organization we want here?" You only need the organizations.

In Sunfish Events, domain rules are set per event, and each event uses one mode:

• Allow list. Only email addresses from the domains you enter can register. Everyone else is stopped.

• Block list. Email addresses from the domains you enter can't register. Everyone else can.

You pick one or the other for an event, not both at once. That keeps the rule easy to reason about: either you're naming who gets in, or you're naming who stays out.

Allow list or block list: which one fits your event

The right mode depends on which group is smaller and easier to name.

A useful way to decide: think about what happens if you forget a domain. With an allow list, forgetting one means a real attendee hits a wall. With a block list, forgetting one means someone you didn't want registers. Pick the mode where your mistakes are cheaper for this particular event.

How the domain check works in Sunfish

Here's what happens, step by step, once you've set a rule on an event.

You enter the domains. You type each domain into the event's setting. There's no preset list built in, so you decide exactly which domains count. That's deliberate control, and it also means the list is only as good as what you put in it (more on that below).

You choose whose email is checked. A setting lets you decide whether Sunfish checks only the purchaser's email, or every attendee's email in the order. This matters for group registrations. If one person at a partner firm registers a team of five, checking only the purchaser means their colleagues can be entered with any address. Checking every attendee means each person in the order has to pass the rule. If you run group orders, read how group registration works and decide which behavior you need before you open registration.

The check runs as they type. The registrant doesn't fill out the whole form only to be rejected at the end. The email is checked as it's entered, so someone with an address that doesn't pass finds out right away.

They see a message. Sunfish shows a default message when an address doesn't pass. You can replace it with your own wording for that event.

Matching is by exact domain. The rule compares the domain exactly as you entered it. If you allow acme.com, an address at acme.com passes. If a company uses more than one domain (a regional domain, a subsidiary, an old domain from before a rebrand), add each one you want covered.

Writing the message people see when they're stopped

The default message works, but the right wording depends on why the event is restricted. A blunt "not allowed" reads differently to a customer using the wrong email than to a competitor. Tailoring the message saves your team from answering the same question by email.

Two tips for wording. First, tell people what to do next, not just that they're blocked. Most people who get stopped by an allow list are legitimate attendees using a personal address. Second, keep it neutral. You don't need to explain who you're excluding or why.

Common setups, with the domains to enter

Business emails only for a B2B event

Plenty of B2B event teams want registrants to use work emails. It makes attendee lists more useful for follow-up, keeps sponsor lead lists cleaner, and discourages throwaway sign-ups. Use a block list and enter the personal email providers you want to exclude. Because there's no preset and matching is exact, list each domain yourself. A reasonable starting set:

• gmail.com

• googlemail.com

• yahoo.com

• hotmail.com

• outlook.com

• live.com

• icloud.com

• aol.com

• proton.me

Look at registrations from past events to see which personal domains your audience actually uses, and add those. Before turning this on, consider who you might shut out. Independent consultants, freelancers, retirees, and people at very small businesses often use personal email for work. If they're part of your audience, a block list on free email can cost you real attendees. You may be better off leaving the event open and handling it another way.

A customer-only summit

Use an allow list with the domains of your customer accounts. If you already maintain an account list in your CRM, export the company domains and enter them. Remember that larger customers may use several domains, so ask your account team which ones their contacts actually register with.

Keeping competitors out of a public event

Use a block list with your competitors' domains. This is one of the cleanest uses of the feature, because the list is usually short and changes rarely. It won't stop a determined person from using a personal address, which brings us to the limits.

Internal-only events

Use an allow list with your company's domain or domains. For an internal training or all-hands, this is often simpler than building and maintaining an invite list of every employee, especially when people join between when you set up the event and when it happens.

What a domain rule can't do

Being clear about limits helps you choose the right tool.

It doesn't verify the person owns the address. Sunfish checks the email address that's entered. It doesn't send a confirmation link to prove the registrant controls that inbox. Someone could type an address at an allowed domain that isn't theirs. For many events this is a minor concern, since anyone who types an address that isn't theirs won't be the one receiving the emails sent to it. But if the event is sensitive enough that identity really matters, a domain rule shouldn't be your only control.

It doesn't stop people with personal emails from getting through a block list. If you block a competitor's domain, a competitor using a Gmail address can still register. Pairing that block list with a block on free providers closes much of that gap, with the audience tradeoff described above.

It works at the organization level, not the person level. An allow list for acme.com lets in everyone at Acme. If only certain people at Acme should attend, you need a list of individuals. Sunfish's member-only registration access levels and the invite-only registration guide cover how to gate registration to specific named people.

It only knows the domains you give it. Since you enter every domain yourself, an incomplete list behaves exactly as written. Build it carefully, and revisit it before each event if you reuse the same setup.

Domain rules vs. invite lists

Both control who can register, but they solve different problems.

Pick the domain rule when "anyone from these companies" is the right answer. Pick an invite list when "these specific people" is the right answer.

A setup checklist before you open registration

The test step is the one people skip. Try an address from an allowed domain and one from a blocked or unlisted domain before you send the link out. It takes two minutes and catches typos in the domain list.

FAQ

Can I use an allow list and a block list on the same event?
No. Each event uses one mode. Choose an allow list when you're naming the organizations that can register, or a block list when you're naming the ones that can't.

Does the rule check everyone in a group registration?
You decide. A setting lets you check only the purchaser's email or every attendee's email in the order.

Does Sunfish confirm that the registrant owns the email address?
No. The rule checks the address as it's entered. It doesn't send a verification link first.

Key takeaways and next step

Restricting event registration by email domain lets you control access at the organization level without building a list of every individual. In Sunfish Events, you set the rule per event, choose either an allow list or a block list, and type in the exact domains that apply. You decide whether only the purchaser or every attendee is checked, registrants see the result as they type, and you can rewrite the message they get. It's the right fit for customer summits, partner days, internal events, and B2B events that want work emails, as long as you account for its limits: it matches exact domains, it only knows what you enter, and it doesn't verify inbox ownership.

If you're also sending registration data from those events into your CRM or other tools, see how the Sunfish Events Zapier integration works. And if you'd like to see domain rules on your own event, try Sunfish Events or book a demo and we'll walk through the setup with you.