Skip to content
Blog / Announcing Email policies: Block free, aliased, and disposable emails at signup
4 min

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.

Announcing Email policies: Block free, aliased, and disposable emails at signup

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.

Email policies card in the Appwrite Console

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.

import { Client, Project } from 'node-appwrite';

const client = new Client()
    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
    .setProject('<PROJECT_ID>')
    .setKey('<YOUR_API_KEY>');

const project = new Project(client);

await project.updateDenyFreeEmailPolicy({ enabled: true });
await project.updateDenyAliasedEmailPolicy({ enabled: true });
await project.updateDenyDisposableEmailPolicy({ enabled: true });

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.

Resources

Frequently asked questions

  • Do email policies affect users who signed up before the policy was enabled?

    No. Email policies only run at sign-up and on email updates. Existing users can still log in with their current address even if that address would no longer pass the policy.

  • What scope does an API key need to update email policies?

    The API key needs the policies.write scope. Reading the current policy state requires policies.read.

  • Does the aliased emails policy cover providers other than Gmail?

    Yes. The policy blocks subaddresses, tags, and provider-specific variations across providers, not just Gmail. Anything that maps to the same underlying inbox via well-known alias syntax is rejected.

  • Can I enable just one of the three email policies instead of all of them?

    Yes. Each policy is an independent toggle. You can enable any combination of deny free, deny aliased, and deny disposable from the Console or by calling only the methods you need.

  • How do I fight spam users?

    Email policies are the first line of defense. Enable deny disposable emails to block temporary inboxes like Mailinator, deny aliased emails to stop one user from spinning up dozens of accounts from a single Gmail with subaddresses, and deny free emails on B2B products that should only accept corporate addresses.

  • Which email providers does Appwrite block?

    The lists are powered by our open-source utopia-php/emails database, which currently tracks over 72,000 disposable domains and 4,000 free email providers. The data is continuously refreshed from six upstream community sources, with a manual override layer on top for edge cases the upstream lists miss.

  • Can I add a missing email provider to the blocklist?

    Yes. The utopia-php/emails repository is open source and accepts contributions. Open a PR against the manual list in the data directory and the next import picks it up.

Start building with Appwrite today