Open sign-up is useful. It is also an open door. If anyone can join your site, you will collect junk accounts, and sometimes worse.<\/p>\n
Most site owners want a middle ground. They want staff, students or clients to sign up on their own. They do not want the rest of the world doing the same. The quickest way to draw that line is the email address. If it ends in your own domain, let it through. If it does not, stop it there.<\/p>\n
This guide shows four ways to do that in 2026. One is built into WordPress. One needs a short snippet of code. One covers a WooCommerce store. One skips sign-up forms altogether.<\/p>\n
Spam is the first reason, and the most common one. Bots scan the web for sites with open sign-up and create accounts in bulk. Those accounts swell your user table. Some are used later to post links or probe for weak spots.<\/p>\n
Control is the second reason. A staff portal, an intranet or a client area should only hold one group of people. An email domain is a quick proof of membership. If the address ends in your company domain, that person has already passed your own email checks.<\/p>\n
Schools and colleges use the same trick. A student area can accept the school domain and turn away everything else, with nobody approving each person by hand.<\/p>\n
Gated content is the third reason. If you sell seats to one business, you do not want a free webmail address signing up and passing the login around.<\/p>\n
There is a quieter reason too. Fewer junk users mean a smaller user table, faster admin screens and cleaner reports. You also send fewer sign-up emails that bounce or land in a spam folder, which helps the mail you do want to send.<\/p>\n
Start with what is already in front of you. Go to Settings \u2192 General<\/strong> in your admin menu. You will find a line called Membership<\/strong> with a single checkbox: Anyone can register<\/em>. Just under it sits New User Default Role<\/strong>.<\/p>\n If that box is clear, your site has no public sign-up form. People can still be added by an admin. If it is ticked, anyone who finds the sign-up link can make an account in seconds.<\/p>\n The default role matters just as much as the checkbox. Subscriber is the safe pick. It lets a person log in and do very little else. Never leave the default on Editor or Administrator. Our guide to WordPress user roles and permissions<\/a> breaks down what each one can touch.<\/p>\n Here is the gap. On a single-site install, WordPress gives you no box where you type a list of allowed domains. The checkbox is all or nothing. You take everyone, or you take no one.<\/p>\n Multisite is the exception, and we cover it next. On a single site you need a snippet or a plugin to fill the gap. If you also plan to move people off the stock form, see how to build a custom login page<\/a> first, so both pages behave the same way.<\/p>\n If your site sits inside a WordPress Multisite network<\/a>, the work is already done for you. This is the one place where core WordPress hands you a domain list with no code at all.<\/p>\n Log in as a Super Admin. Go to My Sites \u2192 Network Admin \u2192 Settings<\/strong>. Scroll down to the Registration Settings<\/strong> block.<\/p>\n Find the field named Limited Email Registrations<\/strong>. Only addresses from the domains you list here may sign up. Type one domain per line, and leave out the @ sign.<\/p>\n Right below it sits Banned Email Domains<\/strong>. That field does the opposite job. It blocks the domains you list and waves everything else through. Use one field or the other, never both.<\/p>\n Scroll to the bottom and press Save Changes<\/strong>. The rule takes effect at once.<\/p>\n Two things to watch. The match is exact, so if your team also uses a mail subdomain, add that line too. And the field only guards the network sign-up form. A separate form on one site in the network is not covered.<\/p>\n One last check. Higher up the same page, Allow new registrations<\/strong> must be set to let user accounts be registered. If it is switched off, the domain field has nothing to act on.<\/p>\n Most sites are not on Multisite. For those, a few lines of code do the job.<\/p>\n Back up the site first.<\/strong> Better still, try this on a copy before you touch the live site. Our walkthroughs on backing up a WordPress site<\/a> and setting up a staging site<\/a> cover both. One typo in site code can take the whole site down.<\/p>\n Where you keep the code matters as much as the code itself. A child theme<\/a> functions file works, but the rule dies the day you switch themes. A small site-specific plugin keeps it alive whatever theme you run. Our comparison of functions.php against a custom plugin<\/a> explains why.<\/p>\n WordPress runs a check on the sign-up form every time it is sent. The filter is named registration errors. You hook into that check, read the address, and hand back an error when the domain is wrong.<\/p>\n Take the address the visitor typed, keep the part after the @ sign, and lower-case it. Compare that against a list of allowed domains held at the top of the snippet. If there is no match, add an error, and WordPress refuses to create the account.<\/p>\n Keep the allowed list at the top so it is easy to edit later. Then reload the sign-up page and try a free webmail address. Your message should appear in red at the top of the form.<\/p>\n WooCommerce does not use the standard WordPress sign-up form. It runs its own, on the My Account page. The snippet above will never see it. If your store has a trade or wholesale area, you need a second rule.<\/p>\n First check whether that form is even switched on. Go to WooCommerce \u2192 Settings \u2192 Accounts & Privacy<\/strong> and look for the option that lets customers create an account on the My Account page. If it is clear, you have nothing to guard here.<\/p>\n If it is ticked, WooCommerce runs its own check when the form is sent, under a filter named woocommerce registration errors. Hook into that one the same way, and keep the code in the same place as your first snippet. Back up before you save, exactly as you did above.<\/p>\n The store version works on the same logic. It reads the address from the My Account form, checks the domain against your list, and returns an error when it does not match.<\/p>\n Then test it. Log out, open the My Account page, and try a free address. The error should show above the form.<\/p>\n Keep guest checkout in mind. A shopper can still buy without an account while guest checkout is on. This rule only decides who gets a saved account, not who can place an order.<\/p>\n Sometimes the cleanest rule is no public form at all. If you only expect a handful of new users a month, this beats any snippet, and there is nothing to maintain.<\/p>\n Go to Settings \u2192 General<\/strong> and clear the Anyone can register<\/em> box. Save the page. The sign-up form is gone, and anyone who tries the direct link is sent back to the login screen.<\/p>\n Now add people yourself. Go to Users \u2192 Add New User<\/strong>. Fill in the username and email, choose the role, and tick the box that sends the new user a notification. WordPress emails them a link so they can set their own password.<\/p>\n This suits small teams, client portals and course sites with fixed intakes. It also wipes out a whole class of spam, because a bot has no form to submit.<\/p>\n The cost is your time. Twenty new users a week by hand gets tiring fast. If that is your volume, go back to Method 2 and let the code do it.<\/p>\n One warning. If those invite emails never turn up, you have a mail problem rather than a sign-up problem. Our guide to WordPress not sending email<\/a> covers the usual causes.<\/p>\n Never trust a rule you have not tried to break. The test takes two minutes.<\/p>\n Open a private or incognito window. That logs you out without ending your real session, so there is no way to shut yourself out part way through.<\/p>\n Go to your sign-up page. On most sites that is your own domain with the standard WordPress login path and the register action on the end. Enter a username and a free webmail address, then send the form. You should see your own error message, and no account should be created.<\/p>\n Now do it again with an address on an allowed domain. This time it should go through. Check that inbox for the set-password email.<\/p>\n Head back to your admin and open Users \u2192 All Users<\/strong>. The allowed account should be sitting there. The blocked one should be nowhere. If the blocked one did appear, your snippet is not running, so check that the plugin holding it is active.<\/p>\n Try the other doors as well. Test the My Account form on a store, the lost password form, and any front-end form a plugin has added. Each one is its own path, and each needs its own check.<\/p>\n A handful of small things trip up most setups. Run through this list once before you call the job done.<\/p>\n Case and stray spaces.<\/strong> Addresses arrive in every shape, often with a capital letter or a space on the end. Lower-case the domain before you compare it, and trim the input as well.<\/p>\n Subdomains.<\/strong> A plain domain and a mail subdomain are two different strings. An exact match will reject the second one. List every variant your people really use.<\/p>\n Plus addressing.<\/strong> Some staff use an address with a plus tag in it. That is fine. The part after the @ sign does not change, so the rule still lets it through.<\/p>\n Shutting yourself out.<\/strong> The rule only runs on the public form. Accounts you create under Users \u2192 Add New User are not checked. Even so, keep a second admin account you can reach.<\/p>\n Guarding one door only.<\/strong> A snippet on the core form does nothing for a store form, a membership form or a form built by a page plugin. Each one needs its own rule.<\/p>\n Silent failure.<\/strong> If your error never shows, the hook may not be loading. Check that the plugin holding the code is active, and look for a PHP error in your debug log.<\/p>\n A vague message.<\/strong> Tell people what to do next. A line asking them to use their work email address beats a bare “Invalid email”, and it cuts your support load.<\/p>\n A domain rule is one layer. It works best with a few more around it, because most attacks on a WordPress site arrive through the login screen rather than the sign-up form.<\/p>\n Keep the default role at Subscriber, and review roles now and then so nobody quietly holds more power than the job needs.<\/p>\n Lock down the login page itself. Our guide on securing the WordPress login page<\/a> is a good start. Cap failed attempts so a known address cannot be guessed at over and over, which our walkthrough on limiting login attempts<\/a> covers. Then turn on two-step login for admin accounts<\/a>.<\/p>\n Watch your other forms too. Contact and comment forms stay a favourite spam route even when sign-up is shut, so it is worth learning how to block contact form spam<\/a>.<\/p>\n Finally, review your user list once a month and clear out accounts that never did a thing.<\/p>\nMethod 1: Use the Built-In Domain List on Multisite<\/h2>\n
Method 2: Add a Short Code Snippet on a Single Site<\/h2>\n
Method 3: Cover the WooCommerce Sign-Up Form Too<\/h2>\n
Method 4: Turn Off Open Sign-Ups and Add People by Hand<\/h2>\n
How to Test Your New Rule<\/h2>\n
Mistakes That Catch People Out<\/h2>\n
Keep Your Sign-Ups Clean and Safe<\/h2>\n