Announcing Email policies: Block free, aliased, and disposable emails at signup_
Email policies let you restrict which email addresses can sign up for your Appwrite project. Block free providers, aliased addresses, and disposable inboxes from the Console or any server SDK.
Most teams discover the hard way that signups happen with whatever address a user feels like typing. Throwaway inboxes, plus-tagged aliases of a single Gmail, and ten-minute mail providers all create real accounts, count toward seat quotas, and eventually show up in your support queue with mail that never delivers.
Today, we are announcing Email policies for Appwrite Auth. You can now restrict which email addresses are accepted for user creation and email updates on a project, either from the Appwrite Console or programmatically through any server SDK.
What you can block
Email policies expose three independent toggles, each targeting a different category of address:
- Free email providers like Gmail, Yahoo, and Outlook, so trials and seats stay tied to a real organization
- Aliased addresses such as subaddresses, tags, and provider-specific variations of the same inbox, so one user cannot quietly create twenty accounts from one mailbox
- Disposable providers like Mailinator and other temporary inbox services, so abandoned accounts and undeliverable mail stop landing in your users table
Each policy is its own toggle. Enabling one does not enable the others, so a B2B product can require corporate addresses without also blocking disposable ones, and a consumer product can keep free providers open while shutting out throwaway inboxes.
The policies run at signup and on email updates. They do not affect session creation, so any user who signed up before a policy was enabled can still log in.
Backed by a curated provider database
Email policies do not ship with a hard-coded list of a few dozen well-known providers. They are powered by utopia-php/emails, an open-source database we maintain that currently tracks 72,906 disposable domains and 4,785 free email providers. The lists are continuously refreshed from six upstream community sources, on top of a manual override layer for edge cases that the upstream lists miss or get wrong.
The data lives in the open and accepts contributions, so if you spot a provider that should be blocked or unblocked you can open a PR against the manual list and the next import picks it up.
Configure from the Console
Open your project, navigate to Auth in the sidebar, and open the Security tab. The Email policies card has a toggle for each policy and an Update button that applies your changes immediately.
Configure from the SDK
Each policy has a dedicated method on the Project service. The body is always an enabled boolean.
The API key needs the policies.write scope.
Get started
Email policies are available now on Appwrite Cloud. Head to Auth > Security in the Console, or read the Email policies documentation for the full SDK reference and per-language examples.
