Email Intelligence for Signup, Fraud, and Abuse Prevention
StopReg is an email intelligence API designed to help applications identify disposable, temporary,
relay, alias, role-based, public email, edu, isp and private email addresses before they enter your
system.
Use StopReg to evaluate email addresses and domains in real time, enforce your signup policies, and
reduce unwanted registrations, trial abuse, and low-quality user data.
The API returns structured classification and mail infrastructure data, allowing you to decide exactly
how your application should handle each address.
What You Can Detect
StopReg goes beyond basic email syntax validation. Depending on the address and domain, the API can
identify:
Disposable and temporary emails used for short-lived registrations
Relay addresses that forward messages through another service
Email aliases and sub-addressing patterns
Role-based addresses such as admin@ and support@
Public email providers such as Gmail, Outlook, and Yahoo
ISP email addresses associated with internet service providers
Educational (EDU) email addresses associated with educational institutions
Private and custom domains
Mail server and MX information
Email provider and infrastructure information
Domain and email classification signals
Policy-based allow, warn, or block decisions
Built for Real-Time Validation
StopReg is designed for applications that need to make an email decision during a signup, checkout,
free-trial registration, newsletter subscription, or other form submission.
A simple API request returns structured JSON that your application can use to determine whether an
address should be accepted, flagged, or blocked.
Flexible Enforcement
StopReg does not force you to use a single blocking rule. You can build your own flexible enforcement
policy around the classification data returned by the API.
For example, you can block disposable addresses while continuing to accept relay, private, public, ISP,
EDU, and role-based addresses. You can also combine multiple signals when your application requires
stricter validation, such as blocking disposable, relay, and alias addresses while requiring the domain
to have valid MX records.
This allows you to define validation rules based on your application's specific requirements rather than
applying the same policy to every email address.
Simple Integration
StopReg uses a REST API over HTTPS and supports API-token authentication. You can integrate it into
virtually any backend or application stack using standard HTTP requests.
Official libraries and examples are available for popular development environments, including Node.js
and Laravel, with additional examples for JavaScript, Python, PHP, and cURL.
Get Started
Start validating email addresses with StopReg in just a few steps:
Create your account: Sign up for a StopReg account and access your API dashboard.
Get your API token: Generate an API token from your dashboard and keep it securely
stored on your server.
Choose an API endpoint: Use the Email Validation API to analyze individual email
addresses or the Domain Validation API when you only need to evaluate a domain.
Send your request: Include your API token and the email address or domain you want to
validate. StopReg returns a structured JSON response containing the available classification and
validation signals.
Apply your enforcement policy: Use the returned results to determine whether to
allow, warn, or block an address based on your application's requirements.
Example Use Case
For a signup form, you can validate an email address before creating the account. Your application can
then use StopReg's response to identify disposable, temporary, relay, alias, role-based, ISP, EDU,
public, or other email classifications and apply your own validation rules.
Key Features
Real-time Validation: Instant email checking with millisecond response times
Extensive DEA Coverage: Detect disposable emails using our large and constantly
growing domain database
Privacy-Focused: We don't store full email addresses - only check the domain part
Easy Integration: Simple REST API that works with any programming language
Whitelisting Support: Whitelist trusted domains to ensure legitimate users are never
blocked
Blacklisting Support: Blacklist unwanted domains to prevent fake signups and
low-quality registrations
Role, Alias & Relay Detection: Identify role-based, alias, and relay email addresses
for cleaner user data
Free, ISP & EDU Detection: Identify free, ISP, and educational email providers for
better email classification
Domain Abuse Shield: Automatically detect custom or relay domains used for repeated
or abusive submissions
Enforcement Policies: Choose whether to allow, warn, or block domains based on their
classification
The sections below cover authentication, endpoints, response fields, SDKs, code examples, validation
configurations, best practices, and troubleshooting.
API Authentication
StopReg uses API token-based authentication. Your API token is
unique to your account and should be kept secure. Never share
your API token publicly or commit it to version control
systems.
Navigate to the API section or locate the API token on
your Dashboard home
Copy your API token (you can regenerate it at any time if
needed)
Using Your API Token
We recommend using the x-api-token header for all requests. This keeps your token out of
URL logs and follows industry standards.
Headers:x-api-token: YOUR_API_TOKEN
Security Best Practices
Keep it Secret: Treat your API token like a
password - never expose it in client-side code
Use Environment Variables: Store your API
token in environment variables, not in your source code
Regenerate if Compromised: If you suspect
your token has been exposed, regenerate it immediately from
your dashboard
Server-Side Only: Always make API calls
from your server-side code, never from the browser
Rate Limits
Rate limits depend on your subscription plan. Free trial accounts are limited to 20 requests per minute,
while paid plans allow up to 5 requests per second.
API Endpoints
StopReg provides a simple REST API endpoint for email
validation. All endpoints use HTTPS and return JSON responses.
Email Verification
Endpoint:
GET https://api.stopreg.com/api/v1/verify/email/{email}
Domain Verification
Endpoint:
GET https://api.stopreg.com/api/v1/verify/domain/{domain}
Path Parameters
{email} (string, required for /email): The
email address to validate.
{domain} (string, required for /domain): The
domain name to validate (e.g., example.com).
Request Examples
Email Verification
GET https://api.stopreg.com/api/v1/verify/email/[email protected]Headers:x-api-token: YOUR_API_TOKEN
Domain Verification
GET https://api.stopreg.com/api/v1/verify/domain/example.com
Headers:x-api-token: YOUR_API_TOKEN
Response Format
The API returns a JSON response with the following structure (shown here for authenticated requests):
The API response is structured into several nested objects. Below is a detailed technical reference for
each field in the payload.
Top-Level Fields
Field
Type
Description
status
Integer
The HTTP status code. Indicates the overall success or failure of the request.
message
String
A short string indicating the result state of the API operation.
description
String
A human-readable summary of the verification result or the specific reason for an error.
data
Object
The container for all verification intelligence. Details are broken down in the sections
below.
Domain & Registry Analytics (data.domain)
Field
Type
Description
root
String
The root domain extracted from your input (e.g., google.com).
is_subdomain
Boolean
true if the input contained a subdomain prefix (e.g.,
mail.google.com); false if the input was already a root domain.
email_provider
String | Null
The identified email provider for this domain if a match is found in either the Email Domains
table or MX Matching table. Returns null if no provider match is found or provider
is "Unknown" (e.g., "Google", "Mailinator", "Zoho").
Input Intelligence (data.input)
Field
Type
Description
email
String
Authenticated requests only. The original email address provided in your
request. Use this to map the response back to your local records.
domain
String
The domain extracted from the email or provided directly. Present in all responses.
normalized
String
Authenticated requests only. The standardized version of your input. This
value is lowercased, trimmed, and stripped of sub-addressing (e.g., user+tag@ becomes
user@).
suggestion
String | Null
If a common typo is detected (e.g., gnail.com), this provides the corrected domain
(gmail.com). Returns null if no correction is needed.
Infrastructure Analytics (data.mail_server)
Field
Type
Description
mx_found
Boolean
true if valid Mail Exchange (MX) records were found for the domain. If
false, the email is likely undeliverable.
mx_records
Array
An ordered array of MX records resolved from the domain's DNS settings, sorted by priority
(lowest number = highest precedence). Each entry contains:
hostname: The mail exchange hostname (e.g.,
"aspmx.l.google.com").
priority: The DNS priority value — lower numbers receive mail first.
mx_provider
Array
Multi-Provider Intelligence. A prioritized list of all infrastructure
providers detected behind the email (e.g., Zoho + Namecheap). Contains:
slug: Identifier (e.g., "zoho corporation").
service_type:mailbox, hosting,
relay, or disposable.
grade: Professionalism tier (e.g., professional).
Strategic Classification (data.classification)
Field
Type
Description
is_disposable
Boolean
High Risk:true if the domain belongs to a temporary, throwaway,
or 10-minute email provider. Disposable email addresses can be associated with increased signup
abuse and fraud risk.
is_relay
Boolean
Low Risk:true if the provider is a forwarding or relay service,
such as iCloud Hide My Email. Relay addresses are commonly used by privacy-conscious users.
is_private
Boolean
Neutral:true if the email domain is a private or custom domain
owned and managed by an individual, business, organization, or institution. It is not associated
with a major public email provider.
is_public
Boolean
Neutral:true for common free consumer email providers such as
Gmail, Outlook, and Yahoo. These addresses are commonly used for personal and B2C registrations.
is_isp
Boolean
Neutral:true if the email domain is associated with an internet
service provider (ISP), such as an ISP-provided email service.
is_edu
Boolean
Neutral:true if the email domain is associated with an
educational institution, such as a university, college, or school.
is_role_based
Boolean
Caution:true for addresses intended for groups or departments,
such as admin@ or support@. These addresses may not represent an individual user
and may be unsuitable for personal account registrations.
is_alias
Boolean
High Risk:true if an email alias or sub-addressing pattern is
detected, such as [email protected]. Aliases can allow multiple addresses to point to
the same mailbox and may be used to bypass registration limits or create multiple accounts.
Enforcement & Policy (data.policy)
Field
Type
Description
action
String
Policy: Enforcement action based on your configured policies. One of:
"allow", "warn", or "block". Determined by the domain's
classification and your configured enforcement policy. Requires API token authentication.
reason_code
String
Code: Machine-readable reason for the action. Examples:
"IS_DISPOSABLE", "IS_RELAY", "IS_ALIAS",
"IS_ROLE_BASED", "UNKNOWN". Useful for logging and analytics.
reason
String
Message: Human-readable explanation of why the action was taken, such as
"This email uses a disposable domain provider."
risk
String
Risk Level: Risk assessment for the email or domain. One of:
"low", "medium", or "high". Reflects the risk level
determined by the detected email and domain characteristics.
List Match (data.list_match)
Field
Type
Description
blocklisted
Boolean | String
List Match:true if the domain is on your configured blocklist,
false otherwise. For unauthenticated requests, returns a string prompt message.
Useful for enforcing custom domain policies.
block_source
String | Null
Source: Indicates the source of the blocklist entry, such as
"user" (manually added), "system" (StopReg system list), or
null if not blocklisted. Helps track where blocking decisions originated.
allowlisted
Boolean | String
List Match:true if the domain is on your configured allowlist,
false otherwise. For unauthenticated requests, returns a string prompt message.
Allowlisted domains bypass policy restrictions.
Note: The policy object is only fully populated for authenticated requests
(with a valid x-api-token header). Anonymous requests receive a simplified response with a
default message.
Error Responses
If an error occurs, the API returns a JSON response with standardized error codes:
{
"status": 401,
"message": "error",
"description": "The provided API token is invalid.",
"data": {
"error": "invalid_token"
}
}
HTTP Status Codes
200 OK: Request successful
400 Bad Request: Invalid parameters (e.g., invalid_email,
invalid_domain)
429 Too Many Requests: Rate limit exceeded (rate_limited) or quota
exhausted (token_exhausted)
500 Internal Server Error: Unexpected server error
Official Libraries
We provide official SDKs for popular programming languages and frameworks.
For a detailed comparison and quick-start guide for all available libraries, visit our
Official Libraries Hub.
Node.js SDK (NPM)
Our Node.js SDK is designed for high-performance and zero-dependency security. It includes full
TypeScript support and robust error handling.
When integrating StopReg into your registration or signup
forms, validate the email address before allowing the user to
complete registration. If data.classification.is_disposable is
true, show an error message asking the user to
use a valid email address.
Best Practices & Troubleshooting
Follow these best practices to ensure optimal performance and
reliability when using the StopReg API.
Best Practices
Validate on Server-Side: Always perform
email validation on your server, never in client-side
JavaScript. This protects your API token and ensures
security.
Handle Errors Gracefully: Implement proper
error handling for network failures, rate limits, and API
errors. Provide user-friendly error messages.
Use Whitelisting: Whitelist trusted
corporate domains to prevent false positives and ensure
legitimate users are never blocked.
Monitor Rate Limits: Keep track of your API
usage to avoid hitting rate limits. Upgrade your plan if
needed.
Validate Email Format First: Check basic
email format before calling the API to save unnecessary
requests.
Common Use Cases
Registration Forms: Validate emails during
user signup to prevent fake accounts
Checkout Processes: Block disposable emails
during e-commerce checkout
Free Trial Signups: Prevent abuse of free
trial offers
Support Ticket Systems: Verify contact
emails for support requests
Troubleshooting
API Returns Error
Verify your API token is correct and active
Check that the email parameter is properly URL-encoded
Ensure you're using the correct endpoint URL
Slow Response Times
Check your network connection
Verify you're using HTTPS (not HTTP)
Consider implementing request timeouts and retries
Domain Management
Form Abuse Shield is a premium feature that automatically detects suspicious activity
from private and relay email domains and helps prevent repeated registrations from abusive domains.
It works alongside email validation to provide an additional layer of protection against form abuse,
spam registrations, and fraudulent activity.
What Is Form Abuse Shield?
Form Abuse Shield monitors registration activity from private and relay domains. When a domain reaches
your configured registration threshold within the selected time window, StopReg can automatically notify
you or block further registrations from that domain.
When the threshold is reached, the system can:
Notify Mode: Automatically send you an email alert with the domain details and
threshold information.
Block Mode: Automatically block the domain from making further registrations.
Key Features
Automatic Detection: Monitors multiple registrations from the same private or relay
domain.
Configurable Threshold: Set the number of requests from a private or relay domain
before an action is triggered, from 2 to 50 requests.
Flexible Time Window: Choose a monitoring period of 1, 3, or 7 days.
Two Action Modes: Choose Notify for email alerts or Block for automatic blocking.
Dashboard Control: Manage, review, and adjust your Form Abuse Shield settings at
any time.
How Form Abuse Shield Works
Step 1: Enable and Configure
Navigate to Manage Domains and configure your Form Abuse Shield settings.
Detection Rule: Set the registration threshold, such as blocking after 5 requests.
Time Window: Choose your monitoring period: 1, 3, or 7 days.
Action: Select Notify for alerts or Block for automatic blocking.
Take No Action: The system will not monitor or take action on domain registrations,
regardless of the configured threshold.
Step 2: Monitoring Begins
Once configured, Form Abuse Shield continuously monitors incoming registration activity.
Automatic Counting: Counts requests from private or relay domains for each domain
within your specified time window.
Tracks Registration Activity: Monitors the number of registrations associated with
each domain.
Compares Against Threshold: Compares registration activity with your configured
threshold.
Step 3: Automatic Action Is Triggered
When a domain reaches your configured threshold:
Notify Mode: Sends you an email alert containing the domain details and threshold
information.
Block Mode: Automatically adds the domain to your blocklist and rejects further
registrations from that domain.
Notify Mode vs. Block Mode
Feature
Notify Mode
Block Mode
Action
Sends an email alert
Automatically blocks the domain
Email Alert
You receive a notification
No notification will be sent
Registration
Domain remains allowed
Further registrations from the domain are rejected
Use Case
Review suspicious domains before taking action
Automatically block repeated registrations
Flexibility
You can review and adjust your settings before blocking
You can manually unblock the domain if needed
Manual Allowlist Protection
Critical Protection: Domains that you manually add to your allowlist are protected from
automatic blocking by Form Abuse Shield, regardless of:
How many requests the domain receives
Whether you switch from Notify to Block mode
How high or low your threshold is configured
This ensures that manually allowlisted domains remain trusted and are never automatically blocked by
Form Abuse Shield.
Manual Blocklist Protection
Similarly, domains that you manually add to your blocklist remain blocked and cannot be unblocked by
Form Abuse Shield's automatic processes.
Configuration Examples
Balanced Setup
Threshold: 5 requests
Time Window: 3 days
Action: Notify
Result: Helps identify suspicious registration activity while allowing you to
review domains before blocking them.
FAQ
Q: Can I manually allowlist a domain to prevent auto-blocking?
A: Yes! Manually allowlisted domains are permanently protected and will never be auto-blocked,
regardless of Form Abuse Shield settings.
Q: What happens if I switch from Notify to Block mode?
A: Domains previously in Notify mode will be auto-blocked if they continue to receive requests and reach
your threshold. However, manually allowlisted domains will remain protected.
Q: Can I unblock an automatically blocked domain?
A: Yes, you can manually remove it from your blocklist at any time from the dashboard.
Q: Is Form Abuse Shield available on all plans?
A: Form Abuse Shield is a premium feature available on the Scale plan and above.
Support
If you have questions about Form Abuse Shield or need help configuring it, contact our support team at
[email protected] or visit the Manage
Domains page to get started.