20 July, 2026
Caution
These abuse patterns are already widely known in fraud communities. This article exists to help builders close the gap, not widen it.
If you're new to tech or are a junior, read the following Jargon Decoder before continuing.Key Terms
Disposable Email: A temporary, short-lived email address used specifically to bypass registration walls and avoid marketing lists.Plus-Addressing: An email provider feature allowing users to append "+string" to their username, creating infinite unique aliases that route to one single inbox.Base Email Address: The true, canonical identity of a user after stripping away all dots, plus-tags, and alternative domain aliases.Domain Reputation: A score assigned to your sending domain by email providers; mailing to fake or unengaged accounts tanks this score, sending your actual product emails directly to spam.
The Napkin Math Formula:
Calculate the monthly financial bleed caused by fake accounts consuming free-tier resources and CRM seats.
Monthly Bleed = (Total Signups * Fraud Percentage) * (Free Tier Infra Cost + CRM/Marketing Seat Cost)Example:
A B2C AI startup gets 20,000 signups per month. 25 percent are abusers using evasion tactics. The app costs $0.80 in API compute per free user, and the CRM charges $0.15 per contact.
Abuser Volume = 20,000 * 0.25 = 5,000 fake users Cost Per Fake User = $0.80 + $0.15 = $0.95 Monthly Bleed = 5,000 * $0.95 = $4,750 per monthFinancial Impact: This architecture failure bleeds $57,000 annually. That is an entire engineering hire or several months of runway burned on users who inherently have a zero percent chance of converting to paid.
The math above exposes the reality of unchecked growth. You cannot optimize your Customer Acquisition Cost (CAC) if your denominator is polluted with synthetic users. When you allow evasion tactics through your front door, you are subsidizing your own abuse.
Most founders prefer growth over restriction. Given the choice, you would rather boast 100,000 total users with 50,000 active on a free tier than 1,000 users with only 100 on a free tier. High volume looks good in pitch decks.
But this mindset ignores unit economics. When you open your signup gate to everyone, you invite users who have no intention of buying. They want to consume your server compute, drain your AI tokens, and test your infrastructure. They obscure their identity to bypass your limits. You pay the server bill. They extract the value.
To fix this, you must identify these accounts at the very moment they attempt to sign up.
Standard product architecture assumes an email address equals a unique human. Abusers know this. They exploit basic email protocols to bypass your limits.
The most common tactic is the disposable email. Users search for temporary inboxes to register for your product. They use your free tier, and when the trial expires, they generate a new temporary email and start over. Most founders attempt to block these with simple checking tools. But the disposable email market moves too fast. Providers spin up new domains daily. Autheona tracks over 150,000 of these domains using active network agents, but static lists from legacy providers miss the new ones entirely.
Worse, temporary emails have real, functioning inboxes. If your security strategy relies on sending a verification code or a magic link, the abuser will simply open the temporary inbox, click the link, and enter your application. You just paid to verify a ghost.
Then comes plus-addressing. If a user owns john@gmail.com, they can register for your app using john+trial1@gmail.com, john+trial2@gmail.com, and so on. Your database sees unique users. The user gets infinite free trials routed to a single inbox.
Note
Plus addressing is also used by internal teams for testing purposes, so please keep that in mind when adding conditions related to it.
Google introduces another layer of complexity with dot-variations. For personal Gmail accounts, Google ignores dots. The addresses johnsmith@gmail.com, john.smith@gmail.com, and j.o.h.n.s.m.i.t.h@gmail.com all route to the same person. Abusers use this to create hundreds of accounts from one identity. This trick works reliably for personal Gmail, though it does not apply to Google Workspace accounts unless an admin explicitly configures it. Furthermore, Google treats @gmail.com and @googlemail.com as the exact same destination.
Finally, automated scripts generate high-entropy, random character strings to create accounts in bulk. These fraud patterns exist to overwhelm your systems, scrape your data, or consume your API limits.
High Entropy Examples:
8f3d91c7b2a4@example.com
xq7m4k9z2w8p@example.net
v91pq8mz3xk7@example.org
a2n9x7q4vk8m@example.com
If you do not trust the user at the signup gate, you pay the invisible tax. This tax hits your profit and loss statement in three distinct ways.
First, infrastructure costs scale against zero revenue. You provision database rows, allocate storage, and reserve AI API credits for these accounts. A small percentage of malicious users will consume a massive, disproportionate share of your resources.
Second, real users suffer. When abusers consume your server capacity, your infrastructure slows down. Genuine, high-value users experience rate limits, timeouts, and degraded service. You degrade your core product to serve people who will never pay you.
Third, your marketing pipeline rots. You push these fake emails into your CRM. You pay seat limits for dead contacts. When you send marketing campaigns, the emails bounce or sit in unmonitored inboxes. Email providers notice this lack of engagement. Your domain reputation crashes. Eventually, when you send a password reset to a paying customer, it lands in their spam folder.
Consider the worst-case scenario: an automated botnet targets your generative AI product. Your application offers 500 free image generations per signup to drive product-led growth.
A malicious actor writes a Python script using the Gmail dot-trick and plus-addressing. They generate 10,000 accounts routing back to a single master inbox. Overnight, they command your infrastructure to generate 5 million images. Your cloud provider auto-scales to handle the load. You wake up to a $15,000 API bill from your foundational model provider. The abusers extract the images for their own commercial use. Your legitimate users are locked out because you hit your monthly API quota. You cannot undo the billing damage. Implementing real-time velocity tracking on the base email address acts as a direct insurance policy against this exact catastrophic event.
If you realize you have a problem, your first instinct is to buy a standard email verification tool. This is a mistake.
Legacy email verification services were built for marketing teams. They exist to clean bulk email lists before a newsletter blast. When you query a legacy tool, it performs an SMTP handshake. It asks the receiving server, "Does this inbox exist?"
The legacy tool will tell you john+abcd@gmail.com is a valid, deliverable inbox. It will tell you a disposable email address is valid. It completely misses the fraud. It does not check intent. It does not evaluate evasion tactics.
Autheona is built for the signup gate. It does not just check if an email can receive messages. It normalizes the data. It strips the plus-tags, removes the dots, and resolves the domain. It looks at the signup velocity of the underlying base email address. It returns structured risk intelligence so your backend can make an immediate, automated decision before the user ever touches your database.
You do not have to blindly block every suspicious user. If you identify a disposable email, you can prompt the user in the UI and politely ask them to continue with a corporate or real email address. If they provide one, you have an opportunity to convert them into a legitimate customer. If they are a bot, you can simply drop the connection. If they are just testing your product, you can either encourage them to register with their real email or isolate them to a lower-tier AI model to reduce costs.
Tip
Think twice before blocking. A polite request for a real email address can filter out bots while giving genuine users a path to become customers.
You control this logic through a simple policy engine in the Autheona dashboard's JSON5-based policy editor. You set the rules for domain blocks, role-based filtering, and velocity.
The integration requires a single API call from your backend at the moment of registration.
curl -X POST "https://api.autheona.com/v1/intelligence" \
-H "Content-Type: application/json" \
-H "x-api-key: <access-token>" \
-d '{
"email_address": "<email-address>"
}'
The JSON response tells your application exactly what evasion tactics are present. You write a simple IF statement in your code. Real users pass through immediately. Abusers get stopped at the gate. Your runway is protected.
Check your database right now for plus-signs and dot-variations in your most active free-tier accounts.
You can sign up for Autheona today and instantly see how much database pollution your application is currently accepting. The API is free to test, requires no credit card, and integrates in less than ten minutes.