Email registration policy
Rakomi lets tenant owners tighten who can register an account using three orthogonal controls. All three default to off so existing behaviour does not change when you upgrade.
What you can configure
Section titled “What you can configure”- Block disposable email domains. When enabled, registrations from a maintained list of known disposable email providers return the same opaque success response as a real signup, but no user record is created. This is a silent block to avoid leaking which domains are rejected.
- Block email subaddresses. When enabled, addresses whose local‑part contains
+(for exampleuser+promo@example.com) are rejected the same way. Existing users whose email already contains+are unaffected — the check only runs on new registrations. - Per‑tenant custom allowlist and blocklist. A tenant can explicitly allow specific domains (entries here win over the disposable list) or block specific domains (always active, independent of the toggles).
The disposable list is refreshed from a maintained public source on a quarterly cadence and vendored into every release, so no third‑party service is called at registration time.
| Route | Purpose |
|---|---|
PATCH /v1/auth/dashboard/tenants/{slug}/settings/security | Flip the two toggles (block_disposable_emails, block_email_subaddresses). Owner role required. |
GET /v1/auth/dashboard/tenants/{slug}/settings/email-domains | Return the current allowlist + blocklist. Owner role required. |
PUT /v1/auth/dashboard/tenants/{slug}/settings/email-domains | Atomically replace both lists (max 100 entries per list). Owner role required. |
Domains in allow/block lists are stored lowercase and punycoded — internationalised names like münchen.de are kept as xn--mnchen-3ya.de.
What the caller sees on a block
Section titled “What the caller sees on a block”Blocked registrations receive the same HTTP 200 response with the same body as a successful signup. Nothing is written to the users table, no verification email is queued, and no user.created webhook fires. A structured audit event (auth.register.blocked_disposable, auth.register.blocked_subaddress, or auth.register.blocked_custom_blocklist) is written with a hashed domain and a decision reference — the full email is never logged.
Non‑goals
Section titled “Non‑goals”- Email address canonicalisation. Rakomi does not silently normalise Gmail dots or
+tags — that approach can enable account‑takeover. - MX‑record validation. The policy is based on vendored data plus per‑tenant lists; live DNS lookups are out of scope for this release.
- Regular‑expression or wildcard domains. Allow/block entries are exact domain matches.
This is one layer of abuse prevention. Combine it with rate‑limiting and (when available) CAPTCHA for a defence‑in‑depth setup.