Domains & DNS

DNS Records for Google Workspace and Microsoft 365 Email

The exact DNS records to add for Google Workspace or Microsoft 365 email - MX, SPF, DKIM, autodiscover - while keeping iWebVault for web hosting.

5 min read

A common setup: hosting your website with iWebVault but email with Google Workspace or Microsoft 365. Done right, your domain points web traffic to iWebVault and email traffic to the cloud provider — no conflict. Done wrong, mail bounces or your domain gets flagged as suspicious. This guide covers the exact DNS records to add for each provider while keeping your iWebVault hosting unchanged.

The overall setup

  • A and AAAA records — Point to iWebVault server. Web traffic.
  • MX records — Point to Google/Microsoft. Mail routing.
  • SPF — Authorize Google/Microsoft to send mail “from” your domain.
  • DKIM — Signing key for outbound mail from Google/Microsoft.
  • DMARC — Policy directive for mail authentication.
  • Optional — Autodiscover records for Outlook auto-configuration.

Plus a critical step: disable iWebVault’s local mail handling for this domain so it doesn’t intercept incoming mail meant for Google/Microsoft.

Critical first step: disable local mail handling

By default, when you create an email account in cPanel, the server tries to deliver mail locally for that domain. With external mail (Google/Microsoft), mail intended for the cloud could be intercepted by your local server.

  1. cPanel → Email → Email Routing.
  2. Select your domain.
  3. Choose “Remote Mail Exchanger.”
  4. Save.

Now server respects MX records pointing elsewhere. Mail flows to Google/Microsoft as DNS specifies.

Google Workspace setup

Step 1: Verify domain ownership

Google provides a TXT record like:

yourdomain.com.   IN  TXT  "google-site-verification=abc123..."

Add via cPanel Zone Editor. Wait for propagation. Verify in Google Admin.

Step 2: MX records

Current Google MX:

yourdomain.com.   IN  MX  1  smtp.google.com.

Single record — Google consolidated to one MX hostname in 2023. Older guides may show five MX records — those still work but the single record is the new standard.

cPanel → Zone Editor → Add MX → Priority 1 → Destination: smtp.google.com.

Remove ALL other MX records for this domain (including any pointing to iWebVault’s mail server).

Step 3: SPF

yourdomain.com.   IN  TXT  "v=spf1 include:_spf.google.com ~all"

Authorizes Google’s servers to send mail for your domain.

If you ALSO send mail from iWebVault (transactional from your WordPress site for example), combine:

"v=spf1 include:_spf.google.com a mx ~all"

Only ONE SPF TXT record per domain — combine all senders into one record.

Step 4: DKIM

  1. Google Admin → Apps → Google Workspace → Gmail → Authenticate email.
  2. Select your domain.
  3. Generate new record.
  4. Google provides a TXT record like:
google._domainkey.yourdomain.com.   IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0..."
  1. Add via cPanel Zone Editor. Hostname is “google._domainkey”.
  2. Wait for propagation.
  3. Click “Start Authentication” in Google Admin.

Step 5: DMARC

_dmarc.yourdomain.com.   IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

Start with p=none for monitoring. After confirming reports look clean, upgrade to p=quarantine then p=reject.

Step 6: Optional autodiscover for Gmail in Outlook

Gmail users in Outlook typically use IMAP. Manual setup. No additional DNS needed for basic operation.

Microsoft 365 setup

Step 1: Verify domain

Microsoft provides a TXT record like:

yourdomain.com.   IN  TXT  "MS=ms12345678"

Add via cPanel Zone Editor. Verify in Microsoft 365 admin.

Step 2: MX record

yourdomain.com.   IN  MX  0  yourdomain-com.mail.protection.outlook.com.

The exact hostname is provided by Microsoft during setup (replace “yourdomain-com” with your domain hyphenated).

Step 3: SPF

yourdomain.com.   IN  TXT  "v=spf1 include:spf.protection.outlook.com ~all"

Step 4: Autodiscover CNAME

autodiscover.yourdomain.com.   IN  CNAME  autodiscover.outlook.com.

Outlook clients use this to auto-configure account settings.

Step 5: DKIM

Two CNAMEs (Microsoft provides exact values):

selector1._domainkey.yourdomain.com.   IN  CNAME  selector1-yourdomain-com._domainkey.tenant.onmicrosoft.com.
selector2._domainkey.yourdomain.com.   IN  CNAME  selector2-yourdomain-com._domainkey.tenant.onmicrosoft.com.

After adding, enable DKIM signing in Microsoft 365 admin → Email authentication settings.

Step 6: DMARC (same as Google)

_dmarc.yourdomain.com.   IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

Optional: Skype/Teams

For Skype for Business / Teams federation, Microsoft provides additional SRV and CNAME records. Add if you use those services.

Verification — testing mail flow

  • Send test mail TO yourname@yourdomain.com from external. Should arrive in Google/Microsoft inbox, not iWebVault.
  • Send test mail FROM yourname@yourdomain.com to a Gmail/Outlook external address. Check headers — SPF, DKIM, DMARC should all pass.
  • mxtoolbox.com — Verify MX records resolve correctly.
  • mail-tester.com — Send test mail; get detailed authentication report.

Keeping iWebVault for outbound transactional mail

If your WordPress site needs to send mail (contact forms, password resets) and you’ve moved primary email to Google Workspace:

  • Option A: Use Google’s SMTP via WP Mail SMTP plugin. Mail sends via Google Workspace authentication. Simpler.
  • Option B: Keep iWebVault’s local mail for outbound. Need to add iWebVault’s IP to your SPF record: v=spf1 include:_spf.google.com a mx ~all.
  • Option C: Use external SMTP relay (Brevo, SendGrid) — independent of Google/iWebVault. SMTP relay.

Common issues

“Mail still going to iWebVault, not Google.” Email Routing not set to Remote Mail Exchanger. Set it.

“My website is broken after DNS changes.” You accidentally removed A records along with MX. Re-add A and AAAA records pointing to iWebVault.

“Two SPF records present.” Only one SPF TXT record allowed. Combine into one with multiple include: directives.

“DKIM showing ‘TXT not found’.” Wait longer for DNS propagation. Verify hostname exactly (the underscore in _domainkey matters).

“Mail working but lands in spam.” SPF/DKIM/DMARC not all set up. Usually DKIM missing — most common cause.

“Some users get mail, others don’t.” DNS propagation in progress. Wait 24-48 hours for full global propagation.

Common questions

“Will moving email to Google break my hosting account?” No. Website continues on iWebVault unaffected.

“Can I have some addresses on Google and some on iWebVault?” Technically yes via split delivery, but complex and rarely worth the trouble. Pick one for primary mail.

“Do I need to keep paying for iWebVault email if I use Google?” If your hosting plan bundles email, you pay either way. Just don’t use the iWebVault mailboxes.

“Migration plan from iWebVault email to Google?” Use IMAPSync to copy existing mailbox content. IMAPSync guide.

“Lowest-cost professional email option?” Google Workspace and Microsoft 365 are both $6-8/user/month. Zoho Mail offers a free tier for small numbers of users on custom domains.

What’s next

Splitting email and web hosting is standard practice — different services for different jobs. The DNS changes are mechanical: MX to the new provider, SPF/DKIM/DMARC to match, Email Routing to Remote. Done in order with attention to the “remove old MX records” and “Remote Mail Exchanger” steps, the transition is clean. Within hours mail flows to the new provider with proper authentication; visitors keep hitting iWebVault for the website.

Was this helpful?