Microsoft 365 has more moving parts during initial setup than most cloud email platforms. Beyond the standard MX records and SPF/DKIM/DMARC setup common to all business email platforms, Microsoft 365 requires an Autodiscover CNAME record for Outlook desktop clients, a tenant-specific MX record format and a two-CNAME DKIM implementation.
Getting all of these right from the start means your team's Outlook desktop client configures automatically, outbound emails land in inboxes rather than spam folders and your domain cannot be spoofed in phishing attacks. Skipping any one of them creates real problems.
This guide covers every configuration step for a correct Microsoft 365 setup, ordered by the sequence that matters.
Before You Begin
You will need:
- Admin access to your domain's DNS (at your registrar — GoDaddy, BigRock, Namecheap or your hosting provider's DNS panel)
- Your Microsoft 365 tenant name (the default
[yourname].onmicrosoft.comaddress assigned during signup) - A list of all users who need accounts
- Your existing email provider credentials (if you are migrating existing email)
- Your GST number if purchasing through an authorised Indian reseller
If you purchase Microsoft 365 through Cloudfy Systems, every step in this guide is handled by our team as part of the deployment.
Step 1 — Choose Your Plan and Sign Up
Microsoft 365 Business plans in India (approximate pricing):
| Plan | Price | Key inclusion |
|---|---|---|
| Business Basic | ₹125/user/month | Email + Teams + web Office |
| Business Standard | ₹660/user/month | Full desktop Office + Teams |
| Business Premium | ₹1,650/user/month | Standard + Intune + Defender |
For most Indian businesses, Business Standard is the recommended starting point — it includes full desktop Word, Excel, PowerPoint and Teams with recording.
During signup, you create your Microsoft 365 tenant. The tenant name (e.g., yourcompany.onmicrosoft.com) is permanent — choose it carefully. This tenant name appears in some internal Microsoft 365 URLs and in the DKIM CNAME records.
Step 2 — Add and Verify Your Domain
Microsoft 365 needs to verify that you own the domain before routing email to it.
In the Microsoft 365 Admin Centre (admin.microsoft.com):
- Go to Settings > Domains
- Click Add domain
- Enter your domain name (e.g., yourcompany.in)
- Microsoft provides a TXT record with a value like:
MS=msXXXXXXXX
Add this TXT record to your DNS:
- Host / Name: @ (root domain)
- Type: TXT
- Value: the MS= string from Microsoft
- TTL: 3600
After adding the record, click Verify in the admin centre. Propagation typically takes 5–30 minutes. Once verified, Microsoft confirms ownership and you can proceed to configure records.
Step 3 — Create User Accounts
With your domain verified, create accounts for every person in your organisation from the Admin Centre under Users > Active Users.
For each user:
- First name, last name
- Primary email address (name@yourcompany.com)
- Assign a Microsoft 365 licence (Business Basic, Standard or Premium)
- Set a temporary password (users change on first login)
For bulk user creation, export a CSV with columns: User Name, First Name, Last Name, Display Name, Job Title, Department, Office Number, Office Phone, Mobile Phone, Fax, Address, City, State or Province, ZIP or Postal Code, Country or Region. Import this from the Active Users screen.
Step 4 — Set Up Autodiscover (Critical for Outlook Desktop)
Autodiscover is a Microsoft-specific CNAME record that tells the Outlook desktop client where to find your Microsoft 365 configuration. Without it, every user who installs or opens Outlook on their desktop computer must manually enter server settings — a time-consuming process that often goes wrong.
Add this CNAME to your DNS:
- Host / Name:
autodiscover - Type: CNAME
- Value:
autodiscover.outlook.com - TTL: 3600
This is unique to Microsoft 365 — Google Workspace does not require this record. Set it up before your MX cutover so Outlook configures automatically from the first day users switch to Microsoft 365.
Step 5 — Configure MX Records
MX records route inbound email to Microsoft 365's servers. Microsoft 365 uses a tenant-specific MX record — not a generic shared server name like Google Workspace.
Find your Microsoft 365 MX record:
- In Admin Centre, go to Settings > Domains
- Click your domain name
- Under DNS records, find the MX record — it will look like:
[yourcompany-com].mail.protection.outlook.com
For a domain rksassociates.in, the MX value would be:
rksassociates-in.mail.protection.outlook.com
In your DNS panel:
- Delete all existing MX records
- Add the new record:
- Host: @ (root domain)
- Type: MX
- Priority: 0 (or 10)
- Value: your tenant-specific
.mail.protection.outlook.comaddress - TTL: 3600
If you are migrating from an existing provider: do not change MX records until the background migration is at least 90% complete. Changing MX records early splits email delivery between two systems.
Before MX cutover: reduce the TTL on your current MX records to 300 seconds (5 minutes) at least 48 hours beforehand. This ensures the change propagates globally within minutes once you make it.
Step 6 — Configure SPF Record
SPF (Sender Policy Framework) tells the world which mail servers are authorised to send email from your domain. For Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all
Add to DNS:
- Host: @ (root domain)
- Type: TXT
- Value:
v=spf1 include:spf.protection.outlook.com -all - TTL: 3600
If you have additional sending sources (a CRM, marketing platform or invoicing tool), include them in the same record:
v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all
Critical rule: A domain can only have one SPF TXT record. If an existing SPF record is present, modify it — do not add a second one. Two SPF records cause all outbound email to fail SPF validation.
The -all at the end means any server not listed in the SPF record should be treated as a hard fail — emails from unauthorised servers are rejected. This is stronger than the ~all (soft fail) used by Google Workspace's recommended SPF record. For Microsoft 365, -all is the standard recommendation.
Step 7 — Configure DKIM
Microsoft 365 uses two CNAME records for DKIM rather than the single TXT record used by Google Workspace. This is Microsoft's key rotation architecture — two selectors that can be rotated independently for security.
Generate DKIM Keys in Microsoft 365
- Go to security.microsoft.com
- Navigate to Email & Collaboration > Policies & Rules > Threat Policies
- Select DKIM from the list
- Click your domain
- Microsoft displays two CNAME records to publish (Selector 1 and Selector 2)
The CNAME records look like:
| Record | Host | Type | Value |
|---|---|---|---|
| Selector 1 | selector1._domainkey | CNAME | selector1-yourcompany-in._domainkey.yourtenantname.onmicrosoft.com |
| Selector 2 | selector2._domainkey | CNAME | selector2-yourcompany-in._domainkey.yourtenantname.onmicrosoft.com |
Copy the exact values from the Microsoft security portal — do not guess the format.
Publish DKIM CNAME Records in DNS
Add both records to your DNS panel exactly as shown. Do not modify the host names or values.
Wait 30–60 minutes for DNS propagation.
Enable DKIM Signing
Return to security.microsoft.com > DKIM, select your domain and click Enable. Microsoft verifies the CNAME records are present and begins signing every outbound email from your domain with the DKIM key.
Once DKIM is enabled, the portal shows DKIM signing: Enabled for your domain.
Step 8 — Configure DMARC
DMARC works with SPF and DKIM to tell receiving mail servers what to do with emails from your domain that fail authentication — and sends you aggregate reports for monitoring.
Starting DMARC record:
v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com
Replace postmaster@yourdomain.com with any mailbox in your Microsoft 365 account.
Add to DNS:
- Host:
_dmarc - Type: TXT
- Value: the DMARC string above
- TTL: 3600
Progression over time:
| Stage | Policy | What it does |
|---|---|---|
| Initial | p=none | Monitor only — receive reports, no enforcement |
| After 2–4 weeks | p=quarantine | Failing emails go to spam |
| After stable quarantine | p=reject | Failing emails blocked entirely |
p=reject is the strongest protection against domain spoofing. It prevents any server in the world from successfully sending phishing emails that appear to come from your domain. This is especially important for businesses whose domains are targeted by credential phishing attacks.
Step 9 — Verify All DNS Records
After publishing all DNS records, verify each one is correct before proceeding. Microsoft 365 Admin Centre shows DNS record health under Settings > Domains > [your domain].
Microsoft's domain health check shows:
- ✅ MX record: pointing to the correct tenant MX
- ✅ Autodiscover CNAME: pointing to autodiscover.outlook.com
- ✅ SPF TXT record: contains spf.protection.outlook.com
- ✅ DKIM: Selector 1 and Selector 2 CNAME records found and enabled
Any red indicators in this view require attention before your email setup is complete.
Step 10 — Configure Outlook Desktop Client
With DNS correctly configured, Outlook on Windows and Mac auto-configures via Autodiscover.
For new Outlook installations:
- Open Outlook
- Enter the user's Microsoft 365 email address
- Outlook detects the server settings via Autodiscover and prompts for the password
- Sign in — Outlook connects and syncs
For existing Outlook with a previous email account:
- Go to File > Add Account
- Enter the new Microsoft 365 email address
- Outlook prompts for credentials and configures automatically
If Autodiscover was not set up correctly before this step, Outlook may fail to auto-configure. Verify the Autodiscover CNAME is in place and propagated first.
Step 11 — Mobile Setup
Microsoft 365 works on every phone via the Outlook mobile app and the Microsoft Teams app.
Outlook Mobile Setup (iOS and Android):
- Download Outlook from the App Store or Play Store
- Tap Get Started > Add Account
- Enter the Microsoft 365 email address
- Enter the password — Outlook connects automatically
Microsoft Teams Mobile:
- Download Microsoft Teams from the App Store or Play Store
- Sign in with the Microsoft 365 credentials
- Teams connects to your organisation automatically
Step 12 — Microsoft 365 Admin Centre Overview
The Microsoft 365 Admin Centre at admin.microsoft.com is where you manage your environment. Key areas:
Users — Add, remove or suspend users. Assign licences. Reset passwords. Manage multi-factor authentication.
Groups — Create Microsoft 365 Groups (team workspaces), Distribution Groups (mailing lists) and Shared Mailboxes (team inboxes multiple people can access).
Billing — View subscriptions, add licences, update payment method. Invoice history for GST documentation.
Settings > Domains — Domain health check, DNS record status and domain management.
Security — Access to Microsoft Defender, multi-factor authentication policies, conditional access and compliance tools (Microsoft Purview on Business Premium).
Reports — Email activity, Teams usage, OneDrive storage, active user counts and security reports.
Common Setup Mistakes for Microsoft 365
Using a generic MX record instead of the tenant-specific one. Unlike Google Workspace which uses shared MX servers, Microsoft 365 requires your tenant-specific .mail.protection.outlook.com address. Using a generic Microsoft MX record will not work.
Not setting up Autodiscover before the cutover. Outlook desktop clients require Autodiscover. Setting it up after the MX change means users on existing Outlook installations need to manually reconfigure — avoidable with proper sequencing.
Publishing two SPF records. This breaks SPF authentication for all outbound email. Always check for an existing SPF record first.
Enabling DKIM before CNAME records propagate. If you click Enable in the DKIM portal before the CNAME records have propagated, the activation fails. Wait at least 30 minutes after publishing the CNAMEs.
Skipping DMARC. Without DMARC, your domain can be spoofed in phishing attacks. Even p=none with reporting gives you visibility into who is sending email claiming to be from your domain.
What Cloudfy Systems Handles for You
Every step in this guide is handled by Cloudfy Systems as part of every Microsoft 365 deployment in India:
- Tenant setup and domain verification
- User account creation and licence assignment
- Autodiscover CNAME configuration
- MX record setup (tenant-specific)
- SPF record configuration
- DKIM CNAME publishing and activation
- DMARC policy setup and monitoring
- Email migration from your existing provider
- Outlook desktop client configuration on staff computers
- Mobile setup for Outlook and Teams
- Admin Centre orientation for your admin user
- INR billing with GST invoice
Frequently Asked Questions
How is Microsoft 365 setup different from Google Workspace setup?
The key differences are: Microsoft 365 uses a tenant-specific MX record (not generic shared servers), requires an Autodiscover CNAME for Outlook desktop clients and uses two CNAME records for DKIM rather than a single TXT record. The overall process is similar in complexity — both require MX, SPF, DKIM and DMARC — but the specific record formats differ.
Do I need Autodiscover if my team only uses Outlook Web (browser)?
No. Autodiscover is specifically for the Outlook desktop application on Windows and Mac. If your team uses only Outlook on the web (outlook.office.com) or the Outlook mobile app, Autodiscover is not technically required — though it is good practice to set it up for any future desktop installations.
What is the Microsoft 365 tenant name and can I change it?
The tenant name is the .onmicrosoft.com domain assigned to your organisation during sign-up (e.g., yourcompany.onmicrosoft.com). It appears in internal URLs and in your DKIM CNAME records. It cannot be changed after creation, so choose it carefully during setup.
Can I set up Microsoft 365 on a domain currently used for a website?
Yes. Adding MX, Autodiscover and TXT records for Microsoft 365 has no effect on your website's A record or CNAME. Your website continues to work exactly as before on its existing hosting.
How long does DNS propagation take in India?
For most Indian registrars (GoDaddy, BigRock, Namecheap, Hostinger), DNS changes propagate within 5–30 minutes. In rare cases with older TTL values, propagation can take up to a few hours. Cloudfy Systems monitors propagation before proceeding to each subsequent configuration step.
What do I do if DKIM fails to enable in the Microsoft 365 portal?
The most common cause is that the CNAME records have not yet propagated when you click Enable. Wait another 30–60 minutes and try again. If DKIM still fails to enable after several hours, check that the CNAME records are published exactly as shown in the portal — a typo in the host name or value is the most common cause of persistent failure.
Cloudfy Systems is an authorised Microsoft 365 Partner in India. For businesses that want a correctly configured Microsoft 365 deployment without navigating DNS panels themselves, contact us at connect@cloudfysystems.com or call +91 97600 50555.