vlad/autoreg-skills-max
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f58eafeb48979991591e8b4c53ff7b2c015091a7
autoreg-skills-max/skills/ai-provider-autoreg/references/new-api-email-whitelist-bypass.md

1.4 KiB
Raw Blame History

New-API Email Whitelist & Alias Restriction

Many new-api panels combine tight email domain whitelists with anti-alias restrictions. Before building a farm script, always pre-flight probe ONE email to check acceptance.

Pre-Flight Probe

curl -s "https://TARGET/api/verification?email=TEST@DOMAIN&turnstile=test"

The error message reveals the block type:

  • "email domain name whitelist" / "域名白名单" → domain not in allowed list
  • "email address alias restriction" / "别名限制" / "特殊符号" → gmail +alias or dots blocked
  • "Turnstile 校验失败" → email ACCEPTED, just need real turnstile token

Known Whitelisted Domains (default new-api)

  • gmail.com
  • outlook.com / hotmail.com
  • qq.com
  • 163.com

Known Blocked

  • voidash.bond — domain whitelist
  • t-online.de — domain whitelist
  • mail.tm — domain whitelist
  • Gmail +alias — alias restriction
  • Gmail dot.alias — alias restriction (dots count as special symbols)

Fallback Strategy

When alias restriction is active, only the canonical inbox works: user@gmail.com, user@outlook.com. This limits registration to 1 per inbox. For scale, you need:

  • Own email domain added to the panel's whitelist (admin-side config EmailDomainWhitelist)
  • Fresh canonical inboxes (outlook signup can be automated)
  • Accept the 1-account ceiling if no further scaling path exists