Apple gives you a number and no names. By the end of this article you have the names, or as close to them as anyone can get, you have warned those people before Apple did, and you have a live roster running through the thirty day window so your service desk knows who still has not acted. Then, and only then, you press the button.
The worked estate is CatSnackJack, a hundred and forty seats on Microsoft 365 Business Premium with a verified catsnackjack.com domain in Apple Business, from [AB 2.1]. The domain details show ninety-one unmanaged Apple accounts. Nobody in IT knows whose they are. That is the normal starting position and it is the problem this sheet solves.
Prerequisites. A verified domain in Apple Business, and an Apple Business role with permissions to manage domains. On the Microsoft side, the Exchange Administrator role, which is the least-privilege role that reaches message trace; do not use Global Administrator for this. For the optional deeper sweep in step 4 you need Microsoft 365 E3 or better and membership of the eDiscovery Manager role group. A shared mailbox you can Bcc to for step 7. Sign-off from whoever owns internal communications, because step 5 sends mail to the whole company. And in a works council or European jurisdiction, a conversation with whoever governs mailbox monitoring before step 7, because copying user mail to a shared mailbox is not a purely technical decision.
Timing. This is not a single sitting. Step 2 must be started at least twenty-four hours before you want its output. Step 3 covers ninety days of mail and the wide report can take hours to build. Budget a week from step 1 to step 8, and pick a start date for step 8 that is not immediately before a holiday, because the thirty day clock does not pause and your day twenty-seven reminder should not land while your service desk is closed.
Naming convention. Two artefacts persist beyond this build and both want predictable names. The Bcc target mailbox is [email protected], named for the job rather than for Apple, so its purpose survives the person who created it. The mail flow rule is Apple Capture Roster 2026, with the year in it, because you will create another one the next time you capture a domain and you do not want to wonder which is live.
Step 1. Lock the domain
Do this first and do it today, before any of the discovery work. Locking is silent, it notifies nobody, and it stops new personal Apple accounts being created on your domain while you spend a week finding the existing ones. Discovering on day six that your population grew during the discovery is avoidable and irritating.
In Apple Business, go to Settings, then Domains, and lock the domain.
Expected result: only Managed Apple Accounts can now be created using the verified domain. Apple’s wording is that unmanaged personal Apple Accounts cannot be created on this domain, and existing Apple Accounts created before enabling the lock remain in place unless Domain Capture is initiated. No user is notified.
Verification gate, and this one is genuinely one way. A locked domain cannot be unlocked. The only route out is to remove the domain entirely, and removing a domain removes the Managed Apple Accounts on it. So before you lock, confirm you actually intend this domain to be an organisational identity namespace rather than, say, a marketing domain that happens to be verified. For CatSnackJack that is trivially true of catsnackjack.com. It would not be true of a campaign domain.
Step 2. Take Apple’s own list, and read its limits
Start this now because of a refresh rule that catches people out. In Apple Business go to Settings, then Domains, select Manage next to your domain, and under Account Names List select Get Started. Wait for Apple to build the list, then select Download for a comma-separated values file. Note the Last Updated value.
The refresh rule. Apple states that this list updates every twenty-four hours, and that before you start domain capture the list updates only after you initiate a new download twenty-four hours after the last request. A second request on the same day returns you the same data. If somebody requested this list last week and you download it today without re-requesting, you are working from last week.
Expected result: a CSV of account names, and a number that is smaller than the unmanaged account total shown in the domain details view. Both of those are correct. Apple states the list “may be lower than the total count of unmanaged Apple Accounts, as it only includes users that have recently signed in to Apple web services such as the Apple Developer Program, the AppleCare Enterprise Portal, or the Apple Push Notification Certificate web portal.”
Reconcile the two numbers and write both down. The domain details view gives the total. The CSV gives the subset. The gap is your unknown population, and it is the single most useful number in this build because it sizes the communication problem before you create it. For CatSnackJack the total is ninety-one and the CSV has eleven rows, so eighty people are currently invisible. A practitioner writing up a capture in the Jamf community in January 2026 reported eighty-nine rows against more than four hundred accounts that actually migrated, so a gap of this proportion is normal rather than alarming. That figure is one organisation’s experience rather than a published rate, and it is the only external calibration I have found for it.
Failure mode: treating the CSV as the roster. It is not, it is a floor, and an organisation that communicates only to the eleven people on it will be blindsided by the eighty who are not.
Step 3. Find the rest in your own mail logs
This is the step that does the real work, and the insight behind it is simple. Apple has been emailing these people for years, about password resets, receipts, sign-in codes and security alerts, and every one of those messages passed through your mail platform. Apple will not tell you who holds an account on your domain. Your transport log already knows.
In the Exchange admin center, go to Mail flow, then Message trace, and select Start a trace.
| Setting | Value | Why |
|---|---|---|
| Senders | One row per address from Apple’s published list, starting with [email protected] | See the warning below. A wildcard will not do this job, and the single most important address is not on the domain you would guess. |
| Recipients | Leave empty | You want every recipient on the tenant. Constraining this is how you miss the shared mailbox nobody remembered. |
| Time range | Custom time range, the full 90 days | Ninety days is the entire retention. It is not configurable and it is not extendable, so take all of it. |
| Report type | Enhanced summary report | Caps at 100,000 results against the Extended report’s 1,000, and arrives as a CSV you can pivot in a spreadsheet. The on-screen Summary report cannot span more than 10 days. |
Select Next, then Prepare report, and collect it later from the Downloadable reports tab on the Message trace page.
The sender trap, and it is the thing that decides whether this step works. The obvious move is a wildcard, and Exchange does support one wildcard per value in the Senders field. But that wildcard is a literal address-suffix match, so *@apple.com finds only addresses whose domain is exactly apple.com. Apple’s account mail does not come from there. Password resets and security notifications come from [email protected], and the rest arrives from a spread of sibling and subdomains including [email protected], [email protected] and [email protected]. A wildcard on apple.com misses every one of them, returns a short and plausible list, and you would have no reason to doubt it.
Apple does publish a list of its most common sender addresses, on its own support discussions site, and that list is what to work from rather than a guess or a wildcard. Add one Senders row per address. If your organisation is old enough to have Apple correspondence from several eras, take the whole list rather than the two you recognise.
Note that the mail flow rule in step 7 does not have this problem, because Exchange’s sender-domain condition matches subdomains as well as the domain itself. That asymmetry is worth remembering when you compare the two results in step 9: a roster larger than your trace is partly missing mailboxes and partly this.
Expected result: a CSV whose recipient column, deduplicated, is your working list of addresses that have received mail from Apple in the last ninety days. For CatSnackJack that returns sixty-three distinct addresses, against eleven from Apple’s list and a total of ninety-one.
Failure modes worth knowing before you run it. Anything wider than ten days is delivered only as a downloadable file, prepared from archived data, and Microsoft warns it might take several hours before the report is available, so do not stand and watch it. The maximum downloadable file is 800 MB and a file above that cannot be opened in Excel. The last twenty-four hours of archived data is typically not available, which does not matter here. And Microsoft notes a five to ten minute gap between actual and reported delivery status, which is a freshness caveat on the status column rather than a delay before messages appear at all.
Read the results with two cautions. A hit does not prove the address is the primary name on an Apple account, because Apple also mails people who hold your address as a verified secondary on some other account, and those people need do nothing. And a miss does not prove absence, because someone with a dormant Apple account may simply not have heard from Apple in ninety days. This list is evidence, not a census, and the article you send in step 5 should be written for a population you have estimated rather than enumerated.
Step 4. Reach past ninety days, if you can
Optional, and worth it in an older estate. Message trace stops at ninety days because that is the retention. Mailbox contents do not, so a search across mailboxes reaches as far back as the mail still exists.
In the Microsoft Purview portal, open the eDiscovery solution, then Cases. Create or open a case, and on the Searches tab select Create a search. Add all mailboxes as the data source, and on the Query tab use the KeyQL editor with from:[email protected], then repeat for the other addresses on Apple’s published list.
Two constraints shape how you write that query. eDiscovery supports prefix wildcards only, so suffix and substring patterns are unavailable and you must name each sender explicitly, exactly as in step 3. And message headers are not indexed, so you cannot search on them. Where the organisation-wide source is available, turn on the option to include departed users, which reaches inactive mailboxes.
Expected result: additional addresses that had Apple correspondence older than ninety days. Treat these as weaker evidence than step 3, because an ancient receipt proves an account existed then and not that it exists now.
One stale instruction to ignore. If you find a guide telling you to run a Content Search from the compliance portal, it is out of date. Microsoft retired all classic eDiscovery experiences, including classic Content Search, on 31 August 2025, and the search capability now lives inside eDiscovery. This is the same class of error as following a pre-2026 Apple Business Manager guide, and it will cost you the same twenty minutes.
Step 5. Sweep the service dependencies before you touch anything else
Some of the accounts on your domain are not people. They are the Apple accounts your own infrastructure depends on, and capturing the domain underneath one of them is how you take your MDM offline.
The one that matters most is the Apple Push Notification service certificate that Intune uses. In the Intune admin center, open the Apple MDM push certificate blade and read the Apple ID that created it. That is a browser-only check and it takes a minute.
Verification gate, and give it lead time. If that Apple ID sits on the domain you are about to capture, stop and resolve it with Apple before continuing. A practitioner who has done this reports that Apple can move the push certificate to a Managed Apple Account without interrupting communication with your managed devices, and that the process runs up to ten business days. Ten business days is two weeks of your project, and finding this out in step 8 rather than step 5 is the difference between a delay and an incident.
Sweep the same way for Apple Developer Program membership, the AppleCare Enterprise Portal and any GSX access. These are exactly the accounts that appear on Apple’s own list in step 2, which is unsurprising once you know that list is built from sign-ins to Apple’s business web properties. Apple’s list is a poor roster of your employees and a decent roster of your service dependencies.
Your existing Apple Business administrator account is not affected by capture, because it is already a Managed Apple Account.
Step 6. Communicate before Apple does
The email Apple sends reads, to a non-technical person, like a phishing attempt: an unexpected message about their Apple account, from an address they do not recognise, telling them to act within thirty days or their account name changes. If yours is not the first message they receive on the subject, you have lost control of the narrative before you started.
Send to everyone, not to your step 3 list. Your list is incomplete by construction and a targeted mail guarantees that the people you missed treat Apple’s message as fraud.
Worked example. What CatSnackJack sends, five working days before capture, from the IT mailbox, subject line naming Apple explicitly so it is findable later:
That in the next week, anyone who has ever created an Apple account using their catsnackjack.com address will receive a genuine email from Apple. That it is not phishing. That it will offer two options, and that the company’s recommendation is to choose a new personal email address and keep the account personal, because transferring it to the company means handing over personal photos and purchases and losing the account on leaving. That there are thirty days and the deadline cannot be extended. That doing nothing means the Apple account keeps working under a renamed address and nothing is lost. That anyone unsure should contact the service desk rather than clicking anything. And a named person to ask.
Brief the service desk separately with the four questions they will actually get: is this real, what happens if I ignore it, will I lose my photos, and can I have longer. The answers are yes, your account is renamed and keeps working, no, and no.
Add a fifth answer, because the two-option story is not true for everyone. Apple documents a substantial class of accounts that cannot be transferred to an organisation at all and are offered only the rename: accounts using iCloud Mail, iCloud+, Family Sharing, Sign in with Apple, a Recovery Key, a Security Key, Advanced Data Protection, Apple Card or Apple Savings, accounts with a Legacy Contact, child accounts, and accounts with outstanding pre-orders. Apple also notes Find My is not available to Managed Accounts, and that AirTags and AirPods should be removed from an account before transfer. Anybody in that class who was told there were two choices and can only see one will call you. Since your recommendation is the rename anyway, the useful framing for the desk is that transfer is the exception and its unavailability is normal rather than a fault.
Two practical notes that save calls. Transferring an account requires signing out of all devices first, which Apple states plainly. And if Stolen Device Protection is on, Apple’s guidance is to turn it off using a device you are signed in on before updating the account email address, so the brief should tell people to expect that rather than treating it as an error.
Step 7. Stage the roster rule
Everything so far has been retrospective, inferring the population from history. This step is prospective and it gives you the actual answer, because Apple is about to mail exactly the people you have been trying to identify.
Create the shared mailbox [email protected]. Then in the Exchange admin center go to Mail flow, then Rules, select Add a rule and Create a new rule, name it Apple Capture Roster 2026, condition on the sender domain being apple.com, and for the action choose Add recipients, then to the Bcc box, and select the shared mailbox.
Expected result: from the moment the rule is live, every message Apple sends to anyone in your tenant is copied to one mailbox. When capture begins, that mailbox becomes a complete, delivery-accurate roster of who Apple actually notified, which is a thing neither Apple nor your ninety day trace could give you.
Turn the rule on. It is created switched off. Microsoft defaults every new mail flow rule to Off on creation, and you enable it by selecting the rule on the Rules page and switching it on from the details panel. This is the single easiest way to complete this entire build sheet and capture nothing at all, because the rule sits there looking correct while Apple’s day one wave goes past it.
Verification gate, and it has two parts because there are two ways this fails. First confirm the rule shows as enabled rather than merely created. Then allow for propagation, because Microsoft states a new or copied rule can take thirty minutes or more to apply. Create and enable this rule at least an hour before step 8, then prove it by sending a test message from an external address into the tenant and confirming the copy lands in the shared mailbox. A rule that was disabled, or still propagating, when Apple sent its day one wave gives you a partial roster and nothing to tell you it is partial.
The operational payoff. Compare the recipients on day one against day twenty-seven. Anyone who received the day one notification and not the day twenty-seven reminder has acted. Anyone on both has not, and is your call list with three days to go. That comparison is the single most useful thing this build sheet produces and I have not seen it published anywhere.
Two honest cautions. The rule only sees mail to mailboxes that still exist, so it inherits the same blind spot as everything else. And copying user mail to a shared mailbox has privacy implications that vary by jurisdiction and by works council agreement. Scope it to the sender domain, not to keywords, keep it for the duration of the capture and delete it afterwards, and have the conversation with whoever owns that policy before you create it rather than after somebody notices.
Step 8. Capture the domain
In Apple Business go to Settings, then Domains, and select Get Started with Domain Capture, then Start Domain Capture. Apple then presents three things to review: the number of Managed Apple Accounts currently used by this domain, verification that the domain is locked, and the start of the thirty day period.
Note the order, because it is not the order you want. Apple’s review screen arrives after Start Domain Capture rather than before it, so it is a confirmation of what you have set in motion rather than a gate in front of it. That is precisely why the gate below sits in this article and not in the product. Do not treat Apple’s three review items as your pre-flight check. They are the receipt.
Verification gate, run it before you select Get Started with Domain Capture, because this is the irreversible one. Apple’s own warning is that turning on Domain Capture cannot be undone and that sending notifications impacts all users with unmanaged Apple Accounts across the domain you capture. Before you begin, confirm every one of the following: the domain is locked from step 1, the reconciliation numbers from step 2 are written down, the communication from step 6 went out and the service desk has the brief, the push certificate question from step 5 is resolved rather than pending, and the roster rule from step 7 is enabled and proven with a test message rather than merely created. Any one of those unticked is a reason to come back tomorrow. The thirty days start the moment you click, and there is no pause.
Expected result: notifications go out. Apple mails the account address and all reachable addresses added to the account, and users on iOS 18, iPadOS 18, macOS 15.1, visionOS 2 or later also get an on-device notification. The schedule is day one, day twenty-one and day twenty-seven, with a fourth message after a primary address actually changes. So users get three pushes inside the window, not four reminders, and your quiet period is days two to twenty.
Failure mode there is no recovering from: capture cannot be cancelled, and federation cannot be disconnected while the account transfer process is incomplete. You are committed for thirty days.
Step 9. The end-to-end test
Within an hour of step 8, open [email protected] and count the distinct recipients of Apple mail received since you pressed the button.
Expected output: a number in the same territory as the unmanaged account total from step 2, and materially larger than the CSV row count. For CatSnackJack, roughly ninety against a total of ninety-one and a CSV of eleven. That single observation proves four things at once: capture actually started, the roster rule is working and was live in time, Apple’s account count was approximately honest, and your step 3 trace missed people, which tells you how much slack to leave in the communication plan.
If the mailbox is empty, the rule was not live. Check its creation time against the capture time, and fall back to a message trace on Apple’s sender addresses for the last day, which will still catch the day one wave because trace is retrospective. You lose the clean day one baseline and you do not lose the window.
Then set two calendar reminders, for day twenty-one and day twenty-seven, to re-count the roster mailbox and produce the difference list.
What you cannot fix, stated plainly
None of the above reaches a former employee whose mailbox was deleted, who never added a personal secondary address to their Apple account, and whose devices are too old for the on-device notification. Apple mails an address that no longer accepts mail. Nobody sees it. On day thirty-one their Apple account is renamed.
Their account still works and they have lost nothing except a name, and recovery runs through iforgot.apple.com as consumer support rather than through you. But you should know this population exists, you should have a rough size for it from the step 2 reconciliation, and you should not tell your leadership that everyone was contacted. Sizing an irreducible gap is a defensible control. Claiming it away is not.
Completion checklist
The domain is locked. Apple’s account total and the Account Names List row count are both recorded, with the gap between them written down as the known unknown. The message trace list exists and is deduplicated. The push certificate question is resolved rather than outstanding. The all-staff communication went before Apple’s did and the service desk holds the four answers. The roster rule is live, proven with a test message, and has an owner and a deletion date. Capture is started, the day thirty date is in a calendar, and day twenty-one and day twenty-seven have reminders against them.
With the domain locked and captured, the identity work moves to the thing capture was a prerequisite for. The next article is federation with Microsoft Entra ID, which is where your people stop having an Apple credential at all.
Apple Business
‹ Previous: [AB 4] Managed Apple Accounts, and the Domain You Are About to Capture
Next: [AB 5] Federating Apple Business with Microsoft Entra ID ›
