Set up Microsoft 365 for a domain hosted on cPanel

Microsoft 365 uses several DNS records to verify the domain, receive email in Exchange Online and configure Outlook automatically. The values depend on your Microsoft account, so copy the ones shown in the admin centre and do not reuse those from another domain.

Before you change the records

1. Check which provider serves the domain's authoritative DNS. If it uses our DNS servers and is hosted with us, you will edit the zone from cPanel's Zone Editor; if it uses Cloudflare or another provider, make the changes there.
2. Create the users and licences you need in Microsoft 365.
3. Note down the existing mailboxes and decide whether their messages will be kept.
4. Save the current MX, TXT, CNAME and SRV records before changing them.

Changing email does not mean moving the website. Keep the website's A and CNAME records if it is to stay hosted at Hostsuar.

Verify the domain in Microsoft 365

From the Microsoft 365 admin centre, add the custom domain. Microsoft will usually ask for a TXT record to prove ownership.

Open Zone Editor, manage the domain's zone and create the TXT record with the exact name and value shown by Microsoft. When Microsoft writes @, it means the root domain; cPanel may show it as the full domain name.

Adding only the verification TXT record does not change where email is received. Complete that validation before the cutover and review any later suggestion that also changes MX records.

Add the Microsoft records

The Microsoft wizard will list the records needed for the services you have. They may include:

• MX to deliver email to Exchange Online.
• TXT for SPF and verifications.
• CNAME records such as autodiscover and those requested by other Microsoft services.
• The two specific DKIM CNAME records Microsoft generates for the domain. After publishing them, enable DKIM from the Microsoft 365 portal.
• SRV for certain communication features.

Edit an existing record when it has the same name and purpose instead of creating another, conflicting one. In particular, a domain must have a single SPF record: if one already exists, add the authorisation given by Microsoft to that same TXT record, without publishing a second v=spf1.

If the website hosted at Hostsuar sends forms or automatic messages with the same domain, the single SPF record may also need to keep the web server's authorisation. Replacing it with Microsoft's value without combining both sources can harm that email.

Microsoft maintains the current list of records and the process for external DNS providers.

Switch where email is received

Changing the MX records is the moment new messages start going to Microsoft 365:

1. Confirm the destination mailboxes exist and can sign in.
2. Replace the old MX records with the value given by Microsoft.
3. In cPanel, open Email Routing and select Remote Mail Exchanger. Automatic detection only looks at the local cPanel zone, does not do a public DNS lookup and does not re-evaluate itself after later changes.
4. Check the records publicly and send test messages to and from external providers.
5. Keep the old mailboxes during the checking period and copy their messages before deleting them.

At cutover, leave only the MX records intended for Microsoft, unless you have deliberately designed a coexistence setup. Keeping one with a lower priority does not create a safe fallback: if Exchange Online does not respond, some senders may deliver messages there that would be cut off from the new mailbox. Messages already with the previous provider stay there until you migrate or download them.

Autodiscover still points to cPanel

If Outlook keeps showing the hosting's configuration even though autodiscover points to Microsoft, see the Autodiscover conflict between cPanel and Microsoft 365. Some accounts need cPanel's local response turned off so that Outlook looks up the external record.

Final check

Review the MX records, the SPF TXT record, the Autodiscover and DKIM CNAME records, the SRV records and email routing. Confirm DKIM is signing messages and, once you have listed every legitimate source, publish DMARC initially with p=none to observe alignment before applying a stricter policy. Test receiving, sending, Autodiscover and existing devices. Propagation can mean that for a few hours different senders see different versions of the zone, so do not remove the old service until you have confirmed the change is complete.

Forms and applications that stay on the hosting

Also test a message from the website to an account on your own domain. Sending from Outlook working does not prove the form uses the right route. Check the actual SMTP server, the sender and its alignment; use the visitor's address as Reply-To, not as the From of a domain you do not control.

To prepare several records without losing the existing ones you can use the DNS assistant. Then check the validation in Microsoft and the result of a real message.