How to provision Microsoft 365 inboxes for cold email

Provisioning a Microsoft 365 inbox for cold email is not creating a user. Creating the user takes ten seconds. Everything that decides whether the mailbox can send happens before and after it, and most of it is DNS.

This is the full sequence, in order, with the failure each step prevents. It is the same order our provisioning engine runs, because the order is not arbitrary: several steps cannot succeed until an earlier one has.

Before you start

You need three things: a tenant with an active licence, a domain you control, and somewhere to host the DNS. The tenant needs a free licence seat for every mailbox plus one for the service account.

If the tenant is newly created, check its age. Microsoft refuses outbound mail from tenants under roughly two weeks old with a 5.7.708 error, and no amount of correct provisioning changes that.

Step 1: create the DNS zone

Create the zone before you point the domain at it. The order matters: if you set nameservers at the registrar first and create the zone afterwards, the zone is assigned a different nameserver pair and the domain never activates.

The zone gives you a nameserver pair. That pair goes at the registrar, and nothing else can proceed until the delegation resolves publicly.

Step 2: point the nameservers

At the registrar, replace the existing nameservers with the pair from the zone. Propagation takes anywhere from minutes to a few hours depending on the TLD, and there is no way to hurry it.

Verify with a public resolver rather than trusting the registrar panel. What matters is what the internet resolves, not what the control panel claims to have saved.

Step 3: add the domain to Microsoft

In the tenant admin centre, add the domain. Microsoft issues a TXT record to prove you control it. Write that record into the zone and verify.

Verification fails silently if the delegation from step two has not resolved yet, which is the most common reason this step appears broken when nothing is wrong.

Step 4: write the mail records

Three records, and all three matter. MX so mail can arrive, SPF so receiving servers know Microsoft is allowed to send for you, and later DMARC to tell them what to do when a check fails.

The full syntax and the traps in each are covered in the SPF, DKIM and DMARC setup guide. The one worth repeating here: a domain can only have one SPF record, and adding a second silently invalidates both.

Step 5: enable DKIM

DKIM needs two CNAMEs pointing at Microsoft selectors, and then enabling inside Exchange. The records must exist before enabling, or the enable call fails.

This is the step that most often stalls in an automated pipeline, because enabling DKIM through the Exchange admin API requires a permission that is easy to miss when the tenant is first set up. If DKIM will not enable, check the app permissions before checking the records.

Step 6: create the service account

One licensed account that the mailboxes send as. This account holds the licence; the sending mailboxes are granted SendAs rights on it, which is what lets a hundred addresses send without a hundred licences.

Step 7: create the mailboxes

Now the part everyone thinks is the whole job. Each mailbox needs a display name that reads like a person, an address derived from that name, and its own password.

Avoid numbered addresses. A mailbox called john.doe2@ is the clearest possible signal that a domain is a sending farm, and it costs nothing to generate a different name instead.

Step 8: grant SendAs

Each mailbox is granted SendAs on the service account. Without this the mailbox authenticates correctly and is refused at MAIL FROM, which produces a confusing failure: the credentials work and the send does not.

Step 9: enable SMTP AUTH

SMTP AUTH is disabled by default on new tenants, and Security Defaults blocks it outright. Turn Security Defaults off, then enable SMTP AUTH per mailbox or tenant-wide.

A mailbox with Security Defaults still on returns a 535 authentication error on every attempt, whatever the password. If every mailbox on a new tenant fails to authenticate, this is why.

Step 10: prove it works

Do not hand over mailboxes that have never sent. Send a real message from a sample of them and read the outcome from message trace, which reports acceptance rather than guesswork.

What you are checking is that the mail authenticated and was accepted. Placement is a separate question that warm-up answers over the following weeks, and it cannot be judged on day one.

Step 11: warm up

Fourteen days minimum before any campaign, then three sends per mailbox per day. A new domain lands in spam at first regardless of how correct the authentication is, because the issue is reputation rather than configuration.

One caution on warm-up tools: the reply budget is usually a separate setting from the daily send cap. We measured one sequencer configured for five sends a day actually producing about ten messages per mailbox, because its reply target was set to eight and replies are sends too. Judge volume by what leaves the mailbox, not by the dashboard.

How long it takes

By hand, a domain of a hundred mailboxes is most of a working day, and the DNS waits mean it cannot be done in one sitting. Automated, the same work runs unattended: a day or so when you provision it yourself, and 24 to 48 hours when it is ordered as a finished batch, with the waiting happening in the background either way.

The difference is not skill. It is that twelve sequential steps with two propagation delays is exactly the shape of task a person is bad at and a queue is good at. If you are provisioning more than a handful of domains, the provisioning is the part to automate, not the buying.