Burner email infrastructure for multi-account ops
Burner email infrastructure for multi-account ops
Most operators starting out use Gmail dot tricks or plus addressing, and they work until they don’t. platforms that matter, whether it’s Amazon, Meta, or any major exchange, have gotten good at clustering accounts by email pattern. [email protected] and [email protected] are trivially linked. even different Gmail addresses tied to the same recovery phone get flagged. if you’re running more than a handful of accounts and want them to stay separate, you need actual infrastructure.
this guide is for operators who are already past the “throw a new Gmail at it” phase. it covers building a real burner email stack: custom domains, catch-all routing, alias layers, and a master inbox that keeps things manageable. the outcome is a system where you can spin up a fresh, non-obviously-linked email address in under thirty seconds, receive mail cleanly, and scale to hundreds of addresses without losing your mind.
i’ve run this setup for two years across airdrop farming, platform arbitrage, and affiliate testing. the concepts apply anywhere you need clean email separation.
what you need
domains - 2-10 aged or new domains per operational cluster (Namecheap, Cloudflare Registrar, or Porkbun, roughly $8-12/year each) - domains should be spread across registrars to avoid one-point clustering
email routing layer - Cloudflare Email Routing , free, handles catch-all forwarding - alternative: ImprovMX free tier (10 aliases per domain) or paid at $9/month
alias management - SimpleLogin , open source, free tier (15 aliases) or premium at $30/year - AnonAddy , open source, free tier (unlimited aliases with bandwidth limits) or Lite at $12/year
master inbox - any clean Gmail or Proton account you don’t use for anything else - Proton Mail ($4/month) preferred for operators who want encrypted storage
tools - a working understanding of DNS records (MX, TXT) - optional: Python 3.x or curl for API-driven alias creation - optional: a password manager (Bitwarden, 1Password) to track alias-to-account mappings
estimated monthly cost at 50 accounts: $8-20 depending on domain count and alias service tier.
step by step
step 1: register your domains with separation in mind
buy domains across at least two registrars. if all your burner domains sit in one Namecheap account, that’s a correlation point. use different payment methods per registrar. domain names themselves don’t need to be clever, but avoid anything that looks like burner-email-123.com. generic brandable names or obscure TLDs (.io, .co, .org) blend in better.
expected output: 2-5 domains registered, sitting in separate registrar accounts or at minimum separate namespaces.
if it breaks: if you can’t afford multiple registrars upfront, at minimum use different emails to register each domain. that’s a weaker separation but better than nothing.
step 2: add your domain to Cloudflare and configure Email Routing
if the domain isn’t already on Cloudflare, add it as a zone (free plan is fine). once the domain is active in Cloudflare, go to Email > Email Routing in the dashboard and enable it.
Cloudflare will give you MX records to add. for a domain like example.com they look like:
MX route1.mx.cloudflare.net priority 59
MX route2.mx.cloudflare.net priority 26
MX route3.mx.cloudflare.net priority 29
add these to your DNS. Cloudflare usually does this automatically if you’re using their nameservers.
expected output: Email Routing shows “enabled” in the Cloudflare dashboard, DNS propagated within 5 minutes typically.
if it breaks: if propagation takes longer than 30 minutes, check that your nameservers are pointing to Cloudflare’s (ns1.[cloudflare](https://www.cloudflare.com/).com, ns2.[cloudflare](https://www.cloudflare.com/).com) and not the registrar’s defaults.
step 3: set up catch-all routing
in Cloudflare Email Routing, go to Routing Rules and add a catch-all rule. set it to forward all unmatched addresses to your master inbox.
this is the key move. with catch-all enabled, [email protected] will land in your inbox. you don’t pre-create signup1@ or user22@, you just use whatever address you need at the moment and the mail arrives.
expected output: send a test from an external address to [email protected]. it should arrive in your master inbox within a minute.
if it breaks: check that the destination address (your master inbox) has been verified in Cloudflare. they require a verification click before routing activates.
step 4: layer SimpleLogin or AnonAddy on top (optional but recommended)
catch-all on a custom domain is fine for basic ops. the problem is that when you enter [email protected] on a platform, that platform sees your actual domain. if the domain gets flagged or burned, every account using it is exposed.
the cleaner architecture puts an alias service in front. SimpleLogin and AnonAddy let you generate [email protected] or [email protected] addresses that forward to your custom domain catch-all, which then hits your master inbox. two hops instead of one.
for SimpleLogin, connect your custom domain under Settings > Custom Domains, verify the DNS records they provide, then generate aliases either from the web UI or via their API:
curl -X POST https://app.simplelogin.io/api/alias/random/new \
-H "Authentication: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"hostname": "signup.platform.com"}'
this returns a fresh alias you can use for that specific signup.
expected output: alias generated, test email forwarded through the alias chain to your master inbox.
if it breaks: the most common issue is the custom domain DNS not fully propagating. SimpleLogin’s dashboard shows verification status per record, MX, SPF, DKIM, and DMARC. all four need to be green before inbound mail routes correctly.
step 5: set up your master inbox and folder structure
your master inbox will receive mail for hundreds of addresses. without structure it becomes unusable fast. create filters or labels by domain:
domain: example1.com, color onedomain: example2.com, color twoplatform: amazon, if you want to slice by platform
in Gmail, use the to: filter criterion. to:*@example1.com catches everything hitting that domain.
i also keep a simple CSV or a Bitwarden note that maps alias to account: [email protected] -> Amazon account #7, created 2026-03-14. without this, mail arrives and you have no idea which account it belongs to.
expected output: filters active, test emails correctly sorted on arrival.
if it breaks: Gmail filters on to: for forwarded mail sometimes need the original recipient header to be preserved. both Cloudflare and SimpleLogin pass the X-Forwarded-To header but the filtering behavior can vary. if filters don’t catch it, filter on the X-Forwarded-To value using a Gmail add-on like Mailheader Checker to confirm what’s landing.
step 6: set up outbound sending capability
for most account ops you only need inbound, receiving verification codes and notifications. but some platforms require a reply from the same address, or you need to initiate contact.
SimpleLogin supports sending from aliases on paid plans. for Cloudflare catch-all domains, outbound requires a separate SMTP setup. the cheapest path is Mailchannels (free tier available via Cloudflare Workers, check current docs) or a transactional sender like Postmark ($1.50 per 1000 emails) configured with your domain’s SPF and DKIM records.
for low-volume outbound, just reply from your master inbox to the alias address. the reply-to chain works in most cases.
expected output: test reply from alias lands in an external inbox, showing the alias address as sender.
if it breaks: SPF or DKIM misconfiguration causes rejection or spam landing. use MXToolbox to check your domain’s authentication records before sending at scale.
step 7: automate alias provisioning with a simple script
once you’re spinning up accounts regularly, doing this manually gets tedious. here’s a minimal Python script using the AnonAddy API to create a new alias on demand:
import requests
import secrets
API_KEY = "your_anonaddy_api_key"
BASE_URL = "https://app.anonaddy.com/api/v1"
def create_alias(description=""):
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
"X-Requested-With": "XMLHttpRequest"
}
payload = {
"domain": "anonaddy.me",
"description": description,
"format": "random_words"
}
r = requests.post(f"{BASE_URL}/aliases", json=payload, headers=headers)
r.raise_for_status()
return r.json()["data"]["email"]
if __name__ == "__main__":
alias = create_alias(description="platform signup 2026-05-19")
print(f"new alias: {alias}")
run this before each account creation. pipe the output directly into your account creation script or browser automation.
expected output: fresh alias printed to terminal, visible in AnonAddy dashboard.
if it breaks: AnonAddy rate-limits alias creation on the free tier. if you hit limits, add a time.sleep(2) between calls or upgrade to Lite ($12/year) for higher limits. the AnonAddy API docs cover all available endpoints and rate limit headers.
step 8: verify deliverability before going live
before using any new domain at scale, send a test to a Mail Tester address from your setup. aim for 8/10 or higher. check that SPF, DKIM, and DMARC all pass. a domain with a bad score will land in spam or get soft-rejected on signups.
also confirm that your domains aren’t on any major blocklists using MXToolbox’s blacklist checker. fresh domains are usually clean, but batch-registered domains occasionally share IP history with previous owners.
expected output: Mail Tester score 8+ for sending domain, all blacklist checks clean.
if it breaks: DMARC failures usually mean the DMARC record is missing or misconfigured. minimum viable DMARC: v=DMARC1; p=none; rua=mailto:[email protected]. see RFC 7489 for the full spec.
common pitfalls
reusing the same domain across different clusters. one burned domain exposes every account that used it. keep clusters isolated with dedicated domains. if you’re doing airdrop farming, the community at airdropfarming.org/blog/ documents which platforms check domain reputation specifically.
not mapping aliases to accounts. this seems like overhead until you need to recover an account and can’t remember which email you used. spend five minutes keeping a log. a simple spreadsheet works.
forwarding everything to a Gmail primary account. Google links activity across accounts. use a dedicated catch-all inbox that has no connection to your personal identity.
skipping DMARC. platforms increasingly check DMARC on signup emails. a domain with no DMARC record is a signal. add even a monitor-only policy.
using short-lived or public temp mail services. Mailinator, Guerrilla Mail, and similar services are on every platform’s blocklist by now. they’re fine for throwaway tests but not for account creation you intend to keep. always use your own domain or a reputable alias service.
scaling this
10 accounts: a single domain with Cloudflare catch-all and a SimpleLogin free tier handles this comfortably. manual alias creation is fine.
100 accounts: you need 3-5 domains minimum for cluster separation. automate alias provisioning via API. upgrade SimpleLogin or AnonAddy to paid tiers. set up proper inbox filters or consider using a dedicated inbox per cluster (Proton Mail Plus at $4/month supports multiple addresses per account).
1000 accounts: domain sprawl becomes a management problem. standardize on a domain naming convention and keep a domain registry spreadsheet. consider running a self-hosted AnonAddy instance (the self-hosting docs cover the full stack) to remove alias limits entirely. at this scale you’ll also want to rotate domains regularly, treating them as consumables with a 3-6 month lifespan before retiring. pair this with the proxy infrastructure covered in setting up residential proxies for multi-account ops to keep your full identity surface isolated.
where to go next
- antidetect browser setup for beginners, covering fingerprint isolation to complement your email infrastructure
- multi-account payment methods that don’t link, next logical piece after email separation
- back to the full tutorial index for the complete operator stack
Written by Xavier Fok
disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.