Managed Apple Accounts in reserved domains and TestFlight

Do managed Apple accounts in reserved domains work for TestFlight builds

No. Apple says Managed Apple Accounts created in reserved domains can’t be used to test TestFlight builds, whether the tester is in an internal group or an external group. If a tester is on a reserved-domain account, that account is not usable for build testing in TestFlight.

The part people get wrong is the domain detail. A Managed Apple Account is not automatically the problem. Apple’s rule is narrower: the account must not be created in a reserved domain. Apple Business Manager creates a reserved domain automatically for an organization, and that domain is fixed to the organization’s setup. Apple’s TestFlight help points to that exact case as blocked.

Reserved domains are different from custom domains. Apple Support says a reserved domain is created automatically for any Apple Business organization, while a custom domain is one you verify and manage yourself. That distinction matters because the TestFlight restriction is tied to the reserved domain account type, not to every managed account in general.

Apple’s TestFlight documentation repeats the same restriction in more than one place. The external tester guide says managed accounts in reserved domains can’t be used to test builds. The internal tester guide says the same thing. The overview page also says Managed Apple Accounts created in reserved domains can’t be used to test builds, which removes the guesswork about whether the rule only applies to one testing path.

A practical example makes this easier to check. If your company set up Apple Business Manager using a website like example.com, Apple may create a reserved domain such as example.appleaccount.com. A Managed Apple Account created on that reserved domain cannot join TestFlight as a tester, even if the person has access to the organization and even if the build is otherwise approved for testing.

The inconvenient part is that the fix is not inside TestFlight. You do not work around this by changing the group, approving the build again, or resending the invitation. The tester account itself has to be eligible. If the person needs to test, use a non-reserved personal Apple Account or another tester account that is not created in the reserved domain.

For teams that need to collect feedback from internal staff, this is a common setup mistake. A company may assume every employee account in Apple Business Manager is fair game for testing. Apple does not say that. It says internal testers can be App Store Connect users, but the reserved-domain Managed Apple Account is still excluded from testing builds.

For external testing, the limit is separate from the account restriction. Apple allows up to 10,000 external testers, but that number does not help if the invited account is a Managed Apple Account created in a reserved domain. The invitation can still fail at the account eligibility layer even when the build and group setup are correct.

If you are trying to set up a clean testing path, check the account type first, then check the domain source, then confirm the tester is invited through the right TestFlight group. That order saves time because the reserved-domain rule is a hard blocker, not a warning.

DevConnect can help you organize real testers for your own app with reciprocity, and its own product page explains that joining, finding testers, testing someone else’s app, posting a job, applying to one, and using the closed test tracker cost nothing. For the Apple side, the rule stays simple: reserved-domain Managed Apple Accounts do not work for TestFlight builds.

If you want a quick internal checklist, ask three questions before sending an invite: is the account managed, is the domain reserved, and is the person supposed to test a build rather than just access App Store Connect If the answer to the first two is yes, TestFlight build testing is blocked.