How Many Email Accounts Can You Actually Create per Provider?

On MailMaker's side there is no cap at all

Start with the part that is fully under our control, because it is the simplest. MailMaker does not impose a per-account, per-day, or per-workspace quantity limit. A request is bounded by your credit balance and nothing else. If you hold 6,000 credits you can ask for 6,000 Gmail accounts in a single task, or 2,000 iCloud accounts at three credits each.

There is also no plan tier that unlocks a higher ceiling, because there is no ceiling to unlock. Buying a larger pack buys more accounts, not more permission. Everything else on this page is about the provider side, which behaves differently and is where the real variability lives.

• No per-day or per-workspace quantity cap
• Balance is the only limit we apply
• 6,000 credits: 6,000 Gmail or Yahoo accounts
• 6,000 credits: 2,000 iCloud accounts at three each

On the provider side, nobody publishes a number

Search results for this question are full of confident figures. Four per phone number, ten per device, unlimited with a business plan. None of those come from a provider's documentation, because no major provider commits to a public per-person ceiling. They describe prohibited behavior instead, which is a different kind of rule.

That vagueness is deliberate. A published number would be a target to engineer against. What providers actually operate is a risk model that reacts to how accounts are created, not a counter that stops at a round figure. Two people creating the same quantity can get entirely different outcomes.

What actually constrains a batch

The binding constraint is almost never a quota. It is the supply of distinct, plausible verification resources, and the consistency of the signals attached to each signup. When those run out or start repeating, completion rates drop regardless of how much budget is left.

This is why a batch of fifty can succeed on Monday and the same configuration can stall on Friday. Nothing about the quantity changed; something about the surrounding signals did. Treating the number as the variable leads teams to keep increasing it when they should be looking at what each request looks like from the provider's side.

• Availability of independent verification resources
• Consistency of network and device signals
• Creation rate rather than total volume
• Reputation history attached to the signup path
• How closely a batch resembles previous batches

The five providers differ in what they check, not in a quota

Gmail and Yahoo are the most permissive at signup and the most reactive afterward, which is part of why they sit at one credit on MailMaker. Outlook applies more checks during the flow itself. Proton is built around privacy, which paradoxically means it scrutinizes automated-looking signups closely. iCloud is the strictest and the slowest, which is why it costs three credits rather than one.

The credit rate is a reasonable proxy for difficulty. It is not a coincidence that the providers costing more are the ones where a large single batch is most likely to finish partially. If you need a mixed pool, front-load the cheaper providers while you validate the rest of your pipeline.

• Gmail: 1 credit, permissive signup, reactive enforcement
• Yahoo: 1 credit, similar profile to Gmail
• Outlook: 2 credits, more in-flow checking
• Proton: 2 credits, strict on automated patterns
• iCloud: 3 credits, strictest and slowest

Large is fine; unexplainable is not

Nothing here argues for small orders. Plenty of customers run four-figure batches in one task and that is exactly what the platform is built for. The distinction worth making is between a large batch you can explain and a large batch you cannot.

If a task finishes at 94 percent and you can say what the other 6 percent had in common, the size was fine. If you cannot, the useful next step is more visibility rather than less volume. Teams running the largest batches tend to be the ones who read their failure counts, not the ones who avoid big numbers.

• Run the size your workflow actually needs
• Read the failed count on every task, not just the successful one
• Investigate when completion rate shifts between similar batches
• Splitting into waves is a visibility tool, not a required limit

Why the pricing model matters more than a ceiling

Because the provider side is unpredictable, the number that protects you is not a quantity limit. It is the billing rule. MailMaker charges for accounts that complete, so a task that finishes partially costs you the successful portion and returns the reservation on the rest.

That is what makes a large request safe to attempt. If you were billed on requested volume, an unexpected provider change would land on your invoice and the rational response would be to keep every batch small. Charging on completion removes that pressure and puts the risk on the side that can actually do something about it.