Introduction
This guide explains how to connect your custom domain to Google Workspace or Microsoft 365 while keeping your website live and your email flow stable. It is designed for businesses that want a clean migration with minimal downtime and no disruption to DNS, hosting, or existing mail services.
Why this process matters
When you change email providers, the most common risk is updating the wrong DNS records or removing records that your website still needs. A careful migration protects your website, preserves mail delivery, and helps avoid lost messages, broken aliases, or authentication issues.
Prerequisites
Before you begin, make sure you have access to the following:
- Your domain registrar or DNS provider
- The Google Workspace or Microsoft 365 admin console
- Current DNS records for your domain
- Access to your existing email provider, if you are migrating
- A low-traffic window for making DNS changes
Step-by-step instructions
Step 1: Verify your domain in the new workspace
Start by adding your domain in the Google Workspace or Microsoft 365 admin console and completing domain verification. Use the verification method provided by the platform, usually a TXT record or CNAME record. This confirms that you control the domain before mail services are activated.
Step 2: Review your existing DNS records
Before changing anything, export or document your current DNS zone. Pay special attention to website records such as A, AAAA, CNAME, and any CDN or hosting records. Do not remove or edit these unless your website migration specifically requires it.
Step 3: Lower DNS TTL in advance
If you are migrating from another email provider, lower the TTL on your mail-related DNS records ahead of the switch. A shorter TTL helps DNS changes propagate faster during the cutover window.
Step 4: Add the required email DNS records
Update only the records needed for email routing and authentication. Keep website records unchanged.
| Record type | Purpose | What to do |
|---|---|---|
| MX | Routes incoming mail to Google Workspace or Microsoft 365 | Replace old mail server MX records with the values provided by the new platform |
| SPF | Authorizes the platform to send mail on behalf of your domain | Update the SPF record to include the new mail service and remove outdated senders if needed |
| DKIM | Adds cryptographic signing for outgoing mail | Generate and publish the DKIM record from the admin console |
| DMARC | Defines how receiving servers should handle unauthenticated mail | Publish or update a DMARC policy that matches your mail flow strategy |
Step 5: Keep website records unchanged
Do not modify your A, CNAME, CDN, or hosting records unless you are also moving the website. Email changes should be isolated from web hosting changes so your site remains accessible during the migration.
Step 6: Test mail flow before full cutover
Send test messages from internal and external accounts and confirm that mail is delivered correctly in both directions. Check spam folders, authentication results, and reply behavior. If possible, test aliases, groups, and shared mailboxes as well.
Step 7: Decommission the old mail service only after validation
Once you confirm that all users can sign in and mail flow is stable, you can safely retire the old provider. Keep the old service active long enough to catch any delayed messages and verify that no important aliases or mailboxes were missed.
Tips and best practices
- Make DNS changes during a low-traffic period
- Document every DNS change before and after the cutover
- Use separate test accounts to verify sending and receiving
- Check that aliases, groups, and shared mailboxes are recreated correctly
- Monitor mail authentication results after the switch
Common issues to watch for
- Website goes offline after DNS changes because A or CNAME records were altered
- Mail is rejected because SPF still references the old provider
- Outgoing mail lands in spam because DKIM or DMARC is missing or incorrect
- Users cannot sign in because accounts were not fully provisioned in the new workspace
- Aliases or shared mailboxes were not recreated during migration
Next steps
After the migration, monitor delivery reports, authentication status, and user access for at least [Insert time period]. If you are planning a larger platform move, such as a website migration, CRM setup, or cloud hosting change, handle each project separately to reduce risk.
Additional information
If you need help with DNS, Google Workspace, Microsoft 365, SPF, DKIM, DMARC, or a full email migration, [Insert support contact method] for implementation support. For complex setups involving multiple domains, bulk email infrastructure, or self-hosted systems, professional configuration is recommended.
Disclaimer
This guide is for general informational purposes only. DNS and email migrations can vary based on your registrar, hosting provider, and mail platform. Always verify changes in a test environment where possible and consult a qualified technical specialist if you are unsure about any step.
Comments
0 comments
Please sign in to leave a comment.