Why Are My Emails Going to Spam After Migration?
Complete guide to fix email deliverability issues and restore inbox placement
You just completed your email migration to Microsoft 365 or Google Workspace, but now your emails are landing in spam folders. This is one of the most frustrating and common issues after migration—but the good news is it's completely fixable. This guide explains exactly why it happens and how to restore your email deliverability.
⚠️ Critical Issue
Email deliverability problems can damage your business reputation, reduce response rates, and cause you to miss important communications. This needs immediate attention—don't wait.
5 Main Reasons Emails Go to Spam After Migration
Incorrect or Missing SPF Records
SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are authorized to send email from your domain. After migration, your SPF record must include your new email provider's servers.
Common Mistakes:
- • Old provider's SPF record still in place
- • Missing "include" directive for new provider
- • Too many DNS lookups (10 lookup limit)
- • Multiple SPF records (only one allowed)
DKIM Not Configured
DKIM (DomainKeys Identified Mail) adds a digital signature to your emails, proving they haven't been tampered with. Many migrations fail to set up DKIM properly.
What Happens Without DKIM:
- • Emails fail authentication checks
- • Reputation score decreases
- • Higher chance of spam folder placement
- • Some providers (like Gmail) heavily penalize missing DKIM
DMARC Policy Issues
DMARC (Domain-based Message Authentication) tells receiving servers what to do when SPF or DKIM checks fail. Without proper DMARC, your domain is vulnerable to spoofing and your emails may be rejected.
Common DMARC Problems:
- • No DMARC record at all
- • Policy set to "p=reject" before testing (too strict)
- • Alignment issues between SPF/DKIM and DMARC
- • Not monitoring DMARC reports
New IP Reputation (Warm-up Required)
When you migrate to a new email platform, you're often sending from new IP addresses with no reputation history. Email providers are suspicious of unknown IPs and may initially route emails to spam.
IP Warm-up Strategy:
- • Start with small email volumes (50-100/day)
- • Gradually increase volume over 2-4 weeks
- • Send to engaged recipients first
- • Avoid spam complaints during warm-up
DNS Propagation Delays
After updating DNS records (SPF, DKIM, DMARC), changes can take 24-48 hours to propagate globally. During this period, some emails may fail authentication checks.
What to Do:
- • Wait 48 hours after DNS changes before troubleshooting
- • Use DNS checkers to verify propagation
- • Lower DNS TTL values before migration (e.g., 300 seconds)
- • Inform recipients of potential delays
Have questions about this topic?
Our migration specialists can help. Chat live or request a free consultation.
Step-by-Step: Fix Email Deliverability After Migration
Step 1: Verify SPF Record
Check your current SPF record and ensure it includes your new email provider.
Correct SPF Records:
Microsoft 365:
v=spf1 include:spf.protection.outlook.com -allGoogle Workspace:
v=spf1 include:_spf.google.com -all💡 If you use multiple email services, combine them: v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all
Step 2: Configure DKIM
Enable DKIM signing in your email platform and add the DKIM records to your DNS.
How to Enable:
Microsoft 365:
- Go to Microsoft 365 Admin Center → Protection → DKIM
- Select your domain and click "Create DKIM keys"
- Copy the two CNAME records provided
- Add them to your DNS provider
- Return and click "Enable" after DNS propagation
Google Workspace:
- Go to Admin Console → Apps → Google Workspace → Gmail
- Click "Authenticate email" → "Generate new record"
- Copy the TXT record provided
- Add to your DNS provider
- Click "Start authentication"
Step 3: Set Up DMARC
Create a DMARC policy that starts lenient and gradually becomes stricter.
Recommended DMARC Progression:
Phase 1 (Monitoring - Start here):
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comPhase 2 (After 2 weeks):
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.comPhase 3 (After 4 weeks):
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.comStep 4: Test Your Configuration
Use email testing tools to verify your authentication setup is working correctly.
Recommended Testing Tools:
- ✅ MXToolbox - Check SPF, DKIM, DMARC records
- ✅ Mail-Tester - Send test email and get deliverability score
- ✅ Google Postmaster Tools - Monitor reputation for Gmail deliverability
- ✅ Microsoft SNDS - Track reputation for Outlook/Hotmail
Preventing Spam Issues During Migration
The best approach is preventing these issues before they happen. Here's how WorkspaceMigration ensures deliverability during migrations:
Pre-Migration DNS Audit
We review your current DNS configuration and plan authentication updates before migration starts.
Proper Timing
DNS changes are made 48 hours before migration cutover to ensure full propagation.
Authentication Setup
SPF, DKIM, and DMARC are configured correctly as part of every migration project.
Post-Migration Testing
We conduct deliverability tests after migration to verify inbox placement before go-live.
Struggling with Email Deliverability?
Our experts fix SPF, DKIM, and DMARC issues as part of every migration. Get help now.
Get a Free Migration Quote
No spam, just expert advice.
Need Help Fixing Email Deliverability?
Our migration experts handle SPF, DKIM, and DMARC configuration as part of every project—ensuring your emails land in inboxes, not spam folders.