---
title: "Block Disposable Email Signups in Free Trials | Emvero"
description: "Use disposable-domain signals and email confirmation in a free-trial signup. See when to reject, review or allow an address without treating every risk as abuse."
url: https://emvero.io/guides/saas-trial-abuse/
language: en
updated: 2026-10-09
---

Guides

# How to handle disposable email signups in a free trial

Use the disposable-domain reason code to choose when to ask for another address, require confirmation or review a trial. A risky status alone cannot make that decision.

## What to do with each answer

The same four verdicts every time. The instruction changes with the situation, because what a mistake costs changes with it.

| Verdict | What to do here |
| --- | --- |
| Deliverable | Allow the signup, then confirm the address before releasing the trial benefit. A deliverable result says the address can receive mail; it does not identify the person. |
| Risky | Read `reason_codes`. If `DISPOSABLE_DOMAIN` appears, apply your trial policy. A role address or catch-all domain alone is not evidence of abuse; ask for confirmation when you need control of the mailbox. |
| Undeliverable | Ask the person to correct the address before granting the trial. An invalid address or absent domain cannot receive the confirmation link; explain the fix where the person can still make it. |
| Unknown | Let the signup continue provisionally and send confirmation. The check could not settle delivery, so do not treat it as proof of fraud or as a confirmed contact. Recheck later if the decision still matters. |

## Use the domain signal for the question it answers

A disposable-mail signal says the address uses a domain associated with a temporary-mail provider. The public [disposable email checker](https://emvero.io/disposable-email-checker/) lets you inspect that classification. It does not tell you how long one mailbox will last or whether its owner intends to misuse a trial. The [definition of disposable email](https://emvero.io/glossary/disposable-email/) explains why a temporary address can still receive a confirmation message.

In a full verification, `checks.disposable` and `DISPOSABLE_DOMAIN` carry this fact. Emvero can mark an otherwise deliverable address `risky`, but it does not automatically return `reject` for that reason. `ROLE_ACCOUNT` describes an address such as `support@`; `ACCEPT_ALL_DOMAIN` describes a server that accepts arbitrary recipients. Neither code says the person is abusing a trial. Branch on the actual reasons and the rest of the evidence, not on the risky label by itself.

## Pick a policy before the form goes live

- **Reject listed domains** if your trial requires a lasting contact address. State that requirement plainly and let someone enter another address.
- **Require email confirmation** before releasing a trial benefit if an active inbox is enough for the first step. A disposable mailbox may pass this gate, so it is not a one-person-one-trial control.
- **Allow and review** if false rejection would cost more than a provisional trial. Keep the disposable flag for a separate abuse decision.

These are rules for your service, not automatic Emvero actions. Apply the same baseline confirmation step to ordinary addresses if later contact or account recovery depends on email. Confirmation shows current control of a mailbox; it does not establish identity, uniqueness or future reachability.

## Put the decision on your server

Call the verification API from your backend and read `status`, `action`, `reason_codes` and `checks` together. If the first response is `pending`, wait for the final result before applying a terminal-status rule. Use a definite failure such as `DNS_NXDOMAIN` to request a corrected address. For `unknown`, continue provisionally and rely on confirmation rather than guessing why the destination did not answer.

Limit claims of a trial benefit with controls owned by your application, such as eligibility and rate rules. Email evidence can help you decide which signups need friction, but cannot prevent all repeat accounts or automated abuse. The [email verification API page](https://emvero.io/email-verification-api/) shows the response fields; the [signup-form guide](https://emvero.io/guides/signup-form-validation/) covers general inline handling.

## Reason codes that decide something here

The API uses these identifiers to explain a check. The notes identify values that the current verification policy or probe does not return.

|  |  |
| --- | --- |
| `DISPOSABLE_DOMAIN` | Disposable address provider |
| `ROLE_ACCOUNT` | Address uses a role name |
| `ACCEPT_ALL_DOMAIN` | Domain accepts every recipient |
| `DNS_NXDOMAIN` | Domain does not exist |

## Terms worth knowing first

### Disposable email address

An address at a temporary-mail provider. The domain signal concerns durability and policy, rather than proving delivery failure.

### Role account

An address for a team or function, such as support@. It can receive mail; its suitability depends on the purpose.

### Catch-all domain

A mail server accepts arbitrary recipients, so acceptance alone cannot establish whether a particular mailbox exists.

[All guides](https://emvero.io/guides/)

## Try it on an address you already know.

The free checker returns the whole result - every stage, every reason code, nothing held back.

See an example check

Start for free