Decide before the account exists
Call /v1/email in the handler that creates the account, sends the invite, or issues the key. You get a decision, the flags that drove it, and the domain facts behind them, in the same request.
A decision your handler can act on
The answer comes back in the request, with enough evidence to explain it to your user or your team.
In the handler
Call the check before you write the account, start the trial, or mint the key. The timeout and the fallback are yours; if a DNS lookup doesn't finish, the verdict says evidence: partial instead of guessing.
Reasons you can show
Flags such as DISPOSABLE_DOMAIN, DOMAIN_TYPO_SUSPECTED with a did_you_mean, ZERO_DAY_DOMAIN, or ROLE_BASED_ACCOUNT tell you why, so you can ask the user to fix a typo instead of rejecting them.
Invites and keys too
The same call works wherever an address turns into access, including team invites and API-key creation, not only the signup form.
A recommendation with the reasons behind it
Use the score and supporting signals to decide what your application should do next. Risk scores and recommendations do not prove mailbox ownership, human identity, or successful delivery.
Fewer detected concerns in the evaluated signals. Use mailbox ownership verification when your workflow requires it.
Review the reasons and choose an appropriate check, such as confirmation by email. An unusual address is not itself proof of abuse.
Significant concerns such as malformed syntax or disposable-domain signals. Your application owns the final decision and any appeal path.
Recommendations describe observed risk signals. Choose the next action for your workflow; an allow result does not confirm mailbox ownership or successful delivery.
Practical questions
Does EmailScore replace every anti-abuse control?
No. Email and domain facts are one source of evidence. Combine them with your application's other signals, and confirm mailbox ownership when your workflow requires it.
Can a genuine user have an unusual email address?
Yes. Treat unusual patterns as context rather than identity proof. Give uncertain users a confirmation step instead of a rejection.
What if the API is slow or down?
Set a timeout in your handler and pick the fallback, usually challenge rather than deny, so a network problem never blocks a real user. Measure end-to-end time from your own servers.
See the evidence before choosing a policy
Run a check, read the flags and facts, then decide what your handler does with each decision.