Migrating business email to Microsoft 365 is one of the most impactful infrastructure changes an Indian business can make. From day one, your team has Outlook on desktop, web and mobile, 50GB per mailbox, Microsoft Teams for video calls and the full Office suite — all in one subscription.
The migration process itself requires more configuration than most businesses expect. Microsoft 365 email delivery uses different DNS records from Google Workspace or standard IMAP-based email. Getting these right is critical to ensure email flows correctly, outbound messages are not flagged as spam and the Outlook desktop client connects automatically.
This guide explains exactly how Microsoft 365 email migration works in India, what gets migrated, the DNS configuration required and what Cloudfy Systems handles on your behalf.
What Gets Migrated to Microsoft 365
A complete email migration to Microsoft 365 moves the following:
- All emails across every folder — inbox, sent, drafts, archive, custom folders
- Email attachments
- Contacts and contact groups
- Calendar events, recurring appointments and meeting invites
What does not migrate automatically and needs to be reconfigured:
- Email rules and filters (recreated in Outlook)
- Shared mailboxes and distribution lists (configured in Microsoft 365 Admin)
- Custom email signatures (configured fresh in Outlook)
- Outlook add-ins and third-party integrations
The mailbox data — which is what your team cares about most — migrates completely, searchable in Outlook from day one.
Supported Source Platforms
Cloudfy Systems migrates businesses to Microsoft 365 from every major email platform used in India.
cPanel and Web Hosting Email
The most common source for Indian SMBs — email hosted on platforms like Hostinger, GoDaddy, BigRock or Bluehost through a cPanel or Plesk control panel. These use standard IMAP, which Microsoft 365's migration tools read directly via the Exchange Admin Centre.
Google Workspace (Gmail)
Migration from Google Workspace to Microsoft 365 is done via IMAP or using Microsoft's IMAP migration tool in the Exchange Admin Centre. Emails, contacts and calendar events all migrate. This is one of the most common migration paths Cloudfy Systems handles.
Zoho Mail
Zoho Mail provides IMAP access for migration. The process is the same as cPanel IMAP migration — straightforward with the right credentials.
Rediffmail and Yahoo Business Email
Both support IMAP access, allowing direct migration to Microsoft 365. Cloudfy Systems handles the credential configuration and batch extraction.
On-Premises Exchange Server
For businesses running their own Exchange Server (2010, 2013, 2016 or 2019), Microsoft provides a staged migration or cutover migration path directly from Exchange to Exchange Online. This is the cleanest migration method for Exchange-to-Exchange moves — calendar items, contacts and folder structures migrate with the highest fidelity. Cloudfy Systems handles both staged and cutover Exchange migrations.
Hosted Exchange (third-party)
Businesses on third-party hosted Exchange from providers like Rackspace, Intermedia or local Indian managed service providers migrate via the same Exchange-to-Exchange path or via IMAP.
How Microsoft 365 Email Migration Works — Step by Step
Step 1: Microsoft 365 Account Setup
Before migration begins, your Microsoft 365 tenant is created, your domain is added and user accounts are provisioned for every mailbox to be migrated.
At this stage, the domain's MX records are not changed. Email continues flowing to your existing provider. Your new Microsoft 365 mailboxes exist but receive no email yet — they are ready to receive migrated data.
Step 2: Autodiscover Configuration
Before configuring MX records, Cloudfy Systems sets up the Autodiscover CNAME record. This is a DNS entry that tells Outlook desktop clients where to find Microsoft 365's configuration servers.
The Autodiscover record is:
- Host:
autodiscover(subdomain of your domain) - Type: CNAME
- Value:
autodiscover.outlook.com
Without Autodiscover, every user has to manually enter their Exchange server settings when setting up Outlook on their desktop — a time-consuming, error-prone process for each computer. With Autodiscover, Outlook detects the settings automatically.
Step 3: Email Migration — Background Process
The migration of existing mailbox data runs entirely in the background using Microsoft 365's IMAP migration tool (Exchange Admin Centre > Migration > Add Migration Batch).
Each source mailbox is mapped to its corresponding Microsoft 365 account. The migration tool connects to the source email server using IMAP credentials and copies all emails, contacts and calendar data to the new Microsoft 365 mailboxes.
During this entire period, your current email continues to function normally. Staff send and receive email from their existing accounts. New emails arriving at the old server are picked up by the migration batch and synced to Microsoft 365 as well.
Migration takes 24–72 hours for most businesses, depending on mailbox count and total data volume.
Step 4: MX Record Cutover
Once migration is at least 90% complete and verified, the MX records are updated.
Microsoft 365 uses a unique MX record format tied to your specific tenant domain. The MX record for your domain will look like:
[yourdomain-com].mail.protection.outlook.com
For example, if your domain is rksassociates.in, your Microsoft 365 MX record is:
rksassociates-in.mail.protection.outlook.com
The exact MX record value is shown in your Microsoft 365 Admin Centre under Setup > Domains.
MX record settings:
- Priority: 0 (or 10 — any single MX record value works)
- Value: the
[tenant].mail.protection.outlook.comaddress from your admin centre
Before making this change, Cloudfy Systems reduces the TTL on existing MX records to 300 seconds (5 minutes). This ensures the new MX record propagates globally within minutes.
After cutover, all new email flows directly to Microsoft 365. The migration batch continues running post-cutover for another 24–48 hours to capture any emails that were in transit.
Step 5: SPF Record Configuration
After MX cutover, the SPF record is updated to authorise Microsoft 365's servers to send email from your domain.
Microsoft 365 SPF record:
v=spf1 include:spf.protection.outlook.com -all
This is added as a TXT record on your domain root (@).
If you have other legitimate sending sources — a CRM, invoicing platform or marketing tool — they need to be included in the SPF record as well. For example, if you also send through Mailchimp:
v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all
Important: A domain can only have one SPF record. If an existing SPF record is present from your previous provider, modify it — do not add a second one.
Step 6: DKIM Configuration
Microsoft 365 uses a two-CNAME approach for DKIM, which is different from Google Workspace's single TXT record method.
Step 1: Generate DKIM keys in Microsoft 365 Admin Centre:
- Go to security.microsoft.com > Email & Collaboration > Policies & Rules > Threat Policies > DKIM
- Select your domain
- Click Enable — Microsoft generates the DKIM key pair
Step 2: Publish two CNAME records in your DNS:
| Record | Host | Type | Value |
|---|---|---|---|
| Selector 1 | selector1._domainkey | CNAME | selector1-[domain]._domainkey.[tenant].onmicrosoft.com |
| Selector 2 | selector2._domainkey | CNAME | selector2-[domain]._domainkey.[tenant].onmicrosoft.com |
The exact values for your tenant are shown in the Microsoft 365 DKIM setup screen. Copy them exactly.
Step 3: After DNS propagation (30–60 minutes), return to the DKIM screen and enable signing. Microsoft verifies the CNAME records and begins cryptographically signing every outbound email from your domain.
Step 7: DMARC Configuration
DMARC builds on SPF and DKIM to tell receiving mail servers what to do with emails from your domain that fail authentication. It also sends you aggregate reports so you can monitor your domain's email health.
Starting DMARC policy for Microsoft 365:
v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com
Published as a TXT record on _dmarc.[yourdomain.com].
Start with p=none to monitor without enforcement. After reviewing reports for 2–4 weeks:
- Move to
p=quarantine— failing emails go to spam - Then
p=reject— failing emails are blocked entirely
p=reject is the gold standard. It prevents any server in the world from successfully spoofing emails from your domain — eliminating one of the most common phishing vectors used against Indian businesses.
Step 8: Post-Migration Verification
After DNS changes and DKIM enablement, Cloudfy Systems verifies:
- Inbound email is flowing to Microsoft 365
- Outbound email from Outlook is delivered without spam issues
- SPF record is passing authentication
- DKIM is signing outbound mail
- DMARC reports are being received and showing clean authentication
- All user mailboxes contain their complete historical email
- Outlook desktop client auto-configures via Autodiscover
- Mobile devices are set up correctly
Only after this full verification is the migration signed off.
Migration Timelines
| Business size | Expected timeline |
|---|---|
| Under 10 users | 2–3 business days |
| 10–30 users | 3–5 business days |
| 30–100 users | 5–10 business days |
| 100+ users | Phased plan, agreed individually |
Email functions normally throughout. No planned downtime.
Microsoft 365 vs Google Workspace Migration — Key Differences
If you are migrating from Google Workspace, there are a few differences worth noting compared to the reverse migration:
DKIM approach: Google Workspace uses a single TXT record. Microsoft 365 uses two CNAME records. The DNS setup is different but equally straightforward with the right guidance.
Autodiscover: Google Workspace is browser-only — no Autodiscover needed. Microsoft 365 requires Autodiscover for the Outlook desktop client to configure automatically.
MX record format: Google Workspace uses generic Google MX servers. Microsoft 365 uses a tenant-specific MX record unique to your organisation.
Calendar migration: Google Calendar and Outlook Calendar formats differ. Calendar events migrate through IMAP migration but complex recurring events may need manual verification.
Common Migration Mistakes
Not setting up Autodiscover before cutover. Users who already had Outlook on their computers before the migration may need to manually reconfigure Outlook if Autodiscover was not in place before the MX change. Set Autodiscover first.
Publishing two SPF records. A domain with two SPF records fails SPF validation for all outbound email. Always modify the existing record rather than adding a new one.
Not enabling DKIM before completing migration. Outbound emails from the new Microsoft 365 domain may land in spam at recipient servers if DKIM is not enabled early in the process.
Changing MX records before migration is near-complete. New email starts arriving in Microsoft 365 before old email is fully migrated, leaving users with split inboxes.
What Cloudfy Systems Handles for You
Cloudfy Systems is an authorised Microsoft 365 reseller in India. Every Microsoft 365 migration includes:
- Microsoft 365 tenant setup and domain configuration
- Autodiscover CNAME setup
- Background IMAP or Exchange mailbox migration
- Low-TTL preparation and MX cutover
- SPF record setup and verification
- DKIM CNAME publishing and activation
- DMARC configuration and monitoring setup
- Outlook desktop client configuration on staff computers
- Mobile device setup for Teams and email
- Post-migration sign-off verification
- INR billing with GST invoice
Migration is included as part of every Microsoft 365 deployment — no separate migration fee.
Frequently Asked Questions
Can I migrate from Google Workspace to Microsoft 365 without downtime?
Yes. The migration runs in the background while your Google Workspace email continues to function. The MX cutover takes minutes and is scheduled during off-peak hours. Most users experience no disruption.
What happens to emails sent to my old address after the MX cutover?
Once MX records point to Microsoft 365, all new email goes directly to Outlook. Emails in transit during the brief DNS propagation window are captured by the migration batch, which continues running post-cutover.
Will my Outlook desktop client work after migration?
Yes. With Autodiscover configured, the Outlook desktop client detects the new Microsoft 365 settings automatically. Most users will be prompted to confirm their account credentials — after which Outlook reconnects to Microsoft 365 without further manual setup.
Does all my historical email appear in Outlook after migration?
Yes. All migrated email is indexed and searchable in Outlook from the day of cutover. Outlook's search is significantly more powerful than most source platforms.
What if some mailboxes are very large?
Very large mailboxes (10GB+) take longer to migrate but the process is the same. Cloudfy Systems monitors migration progress per mailbox and ensures all data is transferred before scheduling the MX cutover.
Cloudfy Systems is an authorised Microsoft 365 Partner in India providing complete email migration for businesses across India. Contact us at connect@cloudfysystems.com or call +91 97600 50555 to discuss your migration.