How to Collect Your Microsoft 365 DNS Records and Send Them to Us

If you have bought Microsoft 365 (formerly Office 365) and your domain's DNS is managed by Cynet, we can publish the records Microsoft needs on your behalf. To do that we need the exact values Microsoft generated for your domain — the MX and DKIM values in particular are unique to your tenant, so we cannot look them up ourselves.

This guide shows you where each record lives and gives you a template to paste into a support ticket.

Note: Microsoft splits these records across two separate portals. The verification, MX, Autodiscover, and SPF records are in the Microsoft 365 admin centre. The DKIM records are not — they live in the Microsoft Defender portal, on a screen most people never find. Step 5 covers it.

Before You Start: Check Who Controls Your DNS

We can only edit DNS for domains that point at Cynet's nameservers. Check yours first.

1. Go to whatsmydns.net.
2. Enter your domain and set the record type to NS.
3. Click Search.

On the Microsoft side you need to be a Domain Name Administrator. Microsoft is explicit that ordinary users and customised administrator roles cannot add or change domains, because the change affects the whole tenant. If the screens below are missing or greyed out, you are signed in with an account that lacks the privilege.

Choose the "Manual" path, not Domain Connect

Microsoft's domain wizard offers two routes: Domain Connect, where Microsoft writes the records into your DNS automatically, and Manual, where it shows you the values to publish yourself.

Domain Connect only works with a short list of providers — GoDaddy, IONOS, Cloudflare, Aruba, EuroDNS, WordPress.com, Plesk, and GoDaddy's resellers. Cynet is not on that list, so if your DNS is with us, choose Manual whenever the wizard asks. Picking Domain Connect and then hunting for a Cynet option in the list is the most common way to get stuck at the first screen.

The Records Microsoft 365 Asks For

A normal mail-only setup needs the first five. The rest depend on which Microsoft services you use.

Warning: Set every record's TTL to 3600 (1 hour). Exchange Online does not support TTL values of 6 hours or more, and we have seen mail routing behave unpredictably when a longer TTL is left in place. We use 3600 by default; you do not need to send it to us.

Step 1: Find Your Domain Verification Record

This is the record Microsoft uses to confirm you own the domain. It does nothing else, and it is the first thing the wizard asks for.

1. Sign in to the Microsoft 365 admin centre.
2. In the left navigation, select ... Show all, then expand Settings.
3. Under Settings, select Domains.
4. Select + Add domain, enter your domain name, and select Use this domain.
5. On the Verify you own your domain page, choose Add a TXT record to the domain's DNS records, then select Continue.
6. Microsoft displays the TXT record. Copy the whole Value.

MS=ms94827361

Copy it including the MS=ms prefix. Without that prefix the record is meaningless.

Note: Do not click Verify in the admin centre yet. That button tells Microsoft to go and check DNS, and it will fail until we have published the record. Send us the value first, wait for us to confirm it is live, then come back and click it.

If the TXT option is unavailable

The wizard offers two alternatives. Adding an MX record for verification is offered but is risky mid-migration — a verification MX record sitting alongside your live one can divert mail — so avoid it unless we have agreed to it. Uploading a text file to your website is the safer fallback: Microsoft gives you a file such as ms39978200.txt to place in your site's top-level folder. If you take that route you can upload it yourself with File Manager or FTP, and no DNS record is needed for verification at all.

Step 2: Find Your MX Record

MX records control where incoming mail is delivered. This is the record that actually moves your email to Microsoft.

1. In the admin centre, go to Settings → Domains and select your domain.
2. Select DNS records, then Manage DNS.
3. When the How do you want to connect your domain? wizard appears, select Continue, then choose the Manual option.
4. Make sure Exchange and Exchange Online Protection is ticked.
5. Expand MX Records and copy the Points to address value.

On priority: lower numbers win, so 0 is the strongest. Microsoft's own pages variously suggest 0 or 1; either is fine as long as it is lower than any other MX record on the domain. Send us whatever number the wizard displays.

Warning: Every other MX record must be removed. Leaving your old mail host's MX record alongside Microsoft's is the most common cause of mail arriving in two places, or vanishing entirely. We handle this removal for you, but we need to know it is intended — see Decide These Things First.

Step 3: Find Your Autodiscover Record

Autodiscover is what lets Outlook set itself up from an email address and password alone, with no manual server settings. Microsoft calls it optional; in practice, skipping it means every user configures Outlook by hand.

On the same Add DNS records page, expand CNAME Records. The value is the same for every Microsoft 365 customer worldwide:

Step 4: Work Out Your SPF Record

SPF is a TXT record listing which servers may send email using your domain. If your domain sends only through Microsoft 365, the record is exactly this:

v=spf1 include:spf.protection.outlook.com -all

Most Cynet customers are not in that simple position. If your website also sends mail — a WordPress contact form, an order confirmation, a booking notification — those messages leave from our web server, not from Microsoft. Both senders must appear in one record.

A domain may have only one SPF record. Two records is not "extra coverage": it is a permanent error that makes SPF fail entirely. So the two get merged into one, like this:

v=spf1 include:spf.protection.outlook.com ip4:203.0.113.5 -all

You do not have to build this yourself. Tell us in the ticket whether your website sends email, and we will merge your existing record with Microsoft's and publish the combined result.

Warning: Microsoft's default ending is -all, a hard fail, which is stricter than the ~all that Google Workspace uses. With -all in place, any sender you forget to list does not go to spam — it is rejected outright. This is exactly how a WordPress contact form stops working the day a domain moves to Microsoft 365. Tell us every service that sends mail as your domain before we publish.

• Everything after -all is ignored, so a merged record always ends with -all and nothing follows it.
• SPF allows a maximum of 10 DNS lookups. Each include: costs at least one. If you use Microsoft plus a newsletter tool plus a CRM plus a helpdesk, you can quietly exceed the limit and SPF starts failing for everyone. We check this before publishing, and name each sender by IP address instead of include: where we can.

Step 5: Generate Your DKIM CNAME Records

DKIM adds a cryptographic signature to your outgoing mail. Unlike Google, Microsoft does not put this in the main admin centre — it is in the Defender portal, and the flow is genuinely counter-intuitive.

Microsoft 365 publishes DKIM as two CNAME records rather than one long TXT record. Two keys exist so Microsoft can rotate them without an outage: one selector is active, the other waits to take over. Both must be published or rotation breaks later.

1. Go to the Defender portal at security.microsoft.com/authentication.
2. Select the DKIM tab. Your domain should be listed with a Status of NoDKIMKeys and its toggle Disabled.
3. Try to slide the toggle from Disabled to Enabled. It will not work.
4. A Client error dialog appears. This is expected — it is how Microsoft generates the keys. Select OK.
5. The domain's status is now CnameMissing. Click anywhere on the domain's row (not the checkbox, not the toggle) to open the details flyout.
6. In the flyout, find the Publish CNAMEs section and select Copy, or note both values. These are what we need.

Note: Deliberately triggering an error to make the records appear is not a bug on your side. Microsoft's own documentation describes this exact sequence. If the flyout shows no Publish CNAMEs section, you skipped step 3.

Two different value formats

The target values come in one of two shapes, and which one you get depends on when your domain was added to Microsoft 365. Do not convert between them, and do not copy a format from an older guide — Microsoft states plainly that the old and new formats cannot coexist for the same selector.

Domains added from May 2025 onwards use the newer format, which ends in dkim.mail.microsoft:

selector1-yourdomain-com._domainkey.yourtenant.n-v1.dkim.mail.microsoft

That single letter before -v1 (often n or r) is assigned by Microsoft's internal routing and is not configurable. There is no way to work it out from your domain name, so copy the value rather than retyping it.

Domains added before that keep the original format, which ends in onmicrosoft.com:

selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Whichever your portal shows is the correct one for your tenant. Send it to us exactly as displayed.

Warning: Do not enable the DKIM toggle yet. Publish the CNAMEs first, then return to the flyout and switch Sign messages for this domain with DKIM signatures on. We will tell you when the records are live. This step is easy to forget, and a DKIM record that is published but never switched on does nothing at all.

If you cannot find the values in the portal

An administrator with Exchange Online PowerShell access can read both values directly:

Get-DkimSigningConfig -Identity yourdomain.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Send us the Selector1CNAME and Selector2CNAME values from the output.

Step 6: Teams and Intune Records (Only If You Need Them)

Most small businesses moving email to Microsoft 365 do not need these. Skip this step unless one applies.

Teams external federation. Needed only if you chat or call with people in other organisations' Teams tenants. Internal Teams use works without any DNS record. It is a single SRV record — modern Teams-only tenants do not need the four sip and lyncdiscover records that older Skype for Business guides list:

Step 7: Decide on DMARC (Later, Not Now)

DMARC tells receiving mail servers what to do with messages that fail SPF and DKIM. Gmail and Yahoo both enforce sender requirements that make it worth having.

It is a TXT record on the host _dmarc. The safe starting value is:

v=DMARC1; p=none; rua=mailto:[email protected]

p=none means "monitor only, change nothing" — it is the correct place to start. Do not begin at p=quarantine or p=reject, which instruct other providers to bin mail that fails.

Do not publish DMARC at the same time as everything else. Let SPF and DKIM authenticate cleanly for a few days first, then raise a follow-up ticket and we will add it. Publishing DMARC on day one, before DKIM has been switched on in the Defender portal, is a reliable way to turn a small misconfiguration into bounced mail.

Note: The address in rua= receives the daily reports, and there can be a lot of them. Point it at a mailbox you have set aside for the purpose, not your own day-to-day inbox.

Decide These Things First

These are decisions only you can make, and getting them wrong is what causes lost mail. Answer all four in your ticket.

1. What happens to your existing Cynet mailboxes? Once MX points at Microsoft, mail stops being delivered to your cPanel mailboxes. Tell us whether to leave them in place as an archive or remove them.

2. Have you moved your old mail across? Messages already sitting in a cPanel mailbox do not travel to Microsoft by themselves. If you need them, migrate them into Exchange Online, or download them in your mail client, before the cutover. Ask us if you want help with this.

3. Have you created the mailboxes in Microsoft first? Microsoft's own instruction is to add users and set up mailboxes before changing the MX record. Every address that currently receives mail — including info@, sales@, and any forwarders — needs an equivalent user or shared mailbox in Microsoft 365 before the switch. Mail for an address Exchange Online does not know about will bounce.

4. When should we make the change? Incoming mail moves over as the MX change propagates, so there is a window where messages may land on either side. Outside business hours is usually the least disruptive.

Send Us This

Open a ticket at manage.cynet.com.my with the subject "Microsoft 365 DNS setup", and paste this template with your values filled in:

Domain:
Microsoft 365 admin email:
Nameservers currently: (Cynet / other - which)
Does your website also send email (contact form, WooCommerce, etc.)?
Other services that send as your domain (Mailchimp, CRM, helpdesk):
Existing cPanel mailboxes: keep as archive / remove
Old mail already migrated to Microsoft?  Yes / No
Mailboxes already created in Microsoft 365?  Yes / No
Teams external federation needed?  Yes / No
Intune / device enrolment needed?  Yes / No
Preferred cutover time:

--- RECORDS FROM MICROSOFT ---

VERIFICATION (TXT)
  Host:  @
  Value: MS=ms

MX
  Host:     @
  Priority:
  Value:    .mail.protection.outlook.com

AUTODISCOVER (CNAME)
  Host:  autodiscover
  Value: autodiscover.outlook.com

SPF (TXT)
  Host:  @
  Value: v=spf1 include:spf.protection.outlook.com -all

DKIM (CNAME) - from the Defender portal, not the admin centre
  Host:  selector1._domainkey
  Value:
  Host:  selector2._domainkey
  Value:

DMARC (TXT) - optional, add later
  Host:  _dmarc
  Value: v=DMARC1; p=none; rua=mailto:

Anything you cannot find, leave blank and say so. A partial ticket that says what is missing is far more useful than a guessed value.

Worked Example

Here is what a completed ticket looks like for a fictional domain, solarmora.com.my:

Domain: solarmora.com.my
Microsoft 365 admin email: [email protected]
Nameservers currently: Cynet (ns1-ns4.cynethost.com)
Does your website also send email? Yes - WooCommerce order emails
Other services that send as your domain: Mailchimp
Existing cPanel mailboxes: keep as archive
Old mail already migrated to Microsoft? Yes
Mailboxes already created in Microsoft 365? Yes - info@, sales@, admin@
Teams external federation needed? No
Intune / device enrolment needed? No
Preferred cutover time: Saturday after 6pm

--- RECORDS FROM MICROSOFT ---

VERIFICATION (TXT)
  Host:  @
  Value: MS=ms94827361

MX
  Host:     @
  Priority: 0
  Value:    solarmora-com-my.mail.protection.outlook.com

AUTODISCOVER (CNAME)
  Host:  autodiscover
  Value: autodiscover.outlook.com

SPF (TXT)
  Host:  @
  Value: v=spf1 include:spf.protection.outlook.com -all

DKIM (CNAME)
  Host:  selector1._domainkey
  Value: selector1-solarmora-com-my._domainkey.solarmora.n-v1.dkim.mail.microsoft
  Host:  selector2._domainkey
  Value: selector2-solarmora-com-my._domainkey.solarmora.n-v1.dkim.mail.microsoft

Note that this customer's website sends mail and they use Mailchimp, so we would publish a merged SPF record naming Microsoft, our web server, and Mailchimp rather than the plain value they pasted.

What We Do After You Send It

Once we have your records:

1. Publish the records in your domain's DNS zone with a TTL of 3600.
2. Remove conflicting records — the old MX entries, the autodiscover record pointing at our mail server, and the SPF and DKIM records cPanel generated for our own mail. Leaving those alongside Microsoft's is what breaks authentication.
3. Merge SPF into a single record covering every service that sends as your domain, and check it stays inside the 10-lookup limit.
4. Switch mail routing — in cPanel, your domain is set to Local Mail Exchanger by default, meaning the server delivers mail for your domain to itself. We change it to Remote Mail Exchanger. Without this step, mail sent from your own website or from another account on the same server never reaches Microsoft, even though outside mail arrives correctly.
5. Confirm back to you when the records are live, so you can return to the admin centre and click Verify, and to the Defender portal to switch DKIM signing on.

What to Expect Afterwards

To see what is actually published at any point, look up your domain's MX, TXT, and CNAME records at whatsmydns.net.

Frequently Asked Questions

Can Cynet just log in to my Microsoft account and get the records?

No. We have no access to your Microsoft 365 tenant and would not ask for it. The MX and DKIM values are generated per tenant, so a Domain Name Administrator on your side has to copy them out.

Why are the DKIM records in a different portal from everything else?

Because DKIM belongs to Microsoft Defender for Office 365 rather than to the domain wizard. The admin centre's Add DNS records page can show DKIM CNAMEs under Advanced options during initial setup, but once the domain is already added, the Defender portal is where they live. If you have already finished the domain wizard, go straight to Step 5.

Will my website go down when we switch to Microsoft 365?

No. Only the mail-related records change. The A record that points your domain at your website, and your SSL certificate, are untouched.

Do I still need my Cynet hosting if email moves to Microsoft 365?

Yes, if your website is hosted with us. Microsoft 365 handles mail only. Your site, databases, and files stay where they are.

My contact form stopped sending after the switch. Why?

Almost certainly the SPF record. Microsoft's default -all rejects any sender not listed, and your website is a different sender from Exchange Online. Open a ticket and we will add our web server to your SPF record. See Step 4.

The Defender portal says CnameMissing. Did something fail?

Not necessarily. CnameMissing is the normal state between generating the keys and publishing them — it is what you should see right after the client error in Step 5. If it still says CnameMissing more than a few hours after we confirm the records are live, open a ticket and we will check what is actually resolving.

Can I keep some mailboxes on Cynet and move others to Microsoft 365?

Not for the same domain. MX records apply to the whole domain, so mail for that domain goes either to Microsoft or to us. A split is only possible using a subdomain, which needs separate records. Ask us if this is what you need.

What if I use a mail filtering service in front of Microsoft 365?

Then the MX record points at the filter, not at Microsoft, and the value in this guide is wrong for you. Tell us which service you use and send us its MX values instead. Related reading: Understanding DNS Records and Fix: Email to Gmail Blocked by DKIM or SPF Failure.