Migrating from SendGrid: 3 Traps I have Seen at 12 Companies

Migrating off SendGrid (or onto SendGrid) is a routine project. The mechanics are simple: change SMTP host, change credentials, update DNS, monitor. After running this migration at twelve companies in five years, three traps have appeared every single time. The migration itself is fine. The traps surface 3-7 days after cutover, when the team has moved on and nobody is watching.

This article describes the three traps and how to defuse them. The audience is whoever is responsible for transactional email at a SaaS or e-commerce shop, switching providers because of price, deliverability or contract.

Trap 1: The Forgotten Subdomain Authentication

SendGrid sets up "Sender Authentication" via two CNAME records per sending subdomain. The CNAMEs point at SendGrid-managed DKIM key servers and at SendGrid's return-path. Most teams configure them once and forget.

When you migrate, you publish new authentication for the new provider. If you forget to remove the SendGrid CNAMEs, two things happen:

1. SPF still includes sendgrid.net, so any mail still leaving via SendGrid passes SPF.
2. DKIM signatures from any forgotten SendGrid integration still verify.

If a forgotten cron job, plugin or vendor is still talking to SendGrid, you discover it weeks later when SendGrid suspends your account for non-payment and that traffic dies silently.

The Defuse

# Audit every SendGrid-related DNS record before cutover
dig +short TXT example.com | grep -i sendgrid
dig +short CNAME em.example.com
dig +short CNAME s1._domainkey.example.com
dig +short CNAME s2._domainkey.example.com

For each integration that used SendGrid (Mailchimp, Zapier, Intercom, CRMs), check the From address. If anything still sends from @em.example.com or via a SendGrid-routed subdomain, update it explicitly.

⚠️ Warning: Run an SPF lookup limit check after migration. SendGrid usually nests 2-3 lookups inside include:sendgrid.net. Leaving it there pushes you closer to the 10-lookup SPF limit.

Trap 2: The Reputation Reset

SendGrid's shared pool and your new provider's shared pool are different IPs. Receivers compute reputation per IP. The moment you cut over you start at zero reputation.

If you cut over on a Monday and immediately send your normal Tuesday digest of 200k emails, the receivers see "new IP suddenly sending 200k". Same domain, but reputation is per-IP for the first 30 days. You will see 5-15% drop in inbox placement for 2-3 weeks.

The Defuse

1. Cut over only transactional first (small volume, high engagement).
2. Wait 7 days; verify Postmaster shows reputation rising.
3. Cut over weekly digests at 25% volume; double daily.
4. Cut over marketing last, ramping from 10% to 100% over 14 days.

This is the same warm-up pattern as a fresh dedicated IP. Many teams skip it because "same domain, same reputation" — that is true only for the long-term DMARC reputation, not for short-term IP reputation that gates inbox placement.

Trap 3: The Suppression List Is Not Transferred

This is the trap that bites hardest. SendGrid maintains a per-account suppression list (bounces, complaints, unsubscribes, blocks). The new provider has a fresh empty list. If you do not migrate the suppression list, you will send to thousands of confirmed bad addresses on day one.

Within hours, your complaint rate spikes, receivers throttle you, and the new provider may auto-pause your account.

The Defuse

Export the SendGrid suppression list before cutover. Use the API:

curl -X GET "https://api.sendgrid.com/v3/suppression/bounces?limit=500&offset=0" 
     -H "Authorization: Bearer ${SENDGRID_KEY}" > bounces.json

curl -X GET "https://api.sendgrid.com/v3/suppression/spam_reports?limit=500&offset=0" 
     -H "Authorization: Bearer ${SENDGRID_KEY}" > complaints.json

curl -X GET "https://api.sendgrid.com/v3/suppression/blocks?limit=500&offset=0" 
     -H "Authorization: Bearer ${SENDGRID_KEY}" > blocks.json

curl -X GET "https://api.sendgrid.com/v3/asm/suppressions/global" 
     -H "Authorization: Bearer ${SENDGRID_KEY}" > global_unsubscribes.json

Paginate through everything. SendGrid limits 500 per page; large accounts have hundreds of thousands of suppression entries.

Then import into the new provider, categorising correctly:

• Bounces → permanent suppression with bounce reason.
• Spam reports → complaint suppression.
• Blocks → suppression with the original SMTP code preserved.
• Global unsubscribes → unsubscribe list.

💡 Tip: Test the import with a 10-record sample first. The new provider may reject malformed entries silently.

The Pre-Cutover Checklist

1. DNS audit: every record referencing SendGrid.
2. Integration audit: every system that ever sent via SendGrid.
3. Suppression list exported (bounces, complaints, blocks, unsubscribes).
4. New provider authenticated (SPF, DKIM, DMARC, BIMI).
5. Warm-up plan written and assigned to an owner.
6. Postmaster Tools verified for new sending pattern.
7. Rollback plan if cutover fails.

The Cutover Itself

Day 0: Update SMTP credentials in production for transactional only. Marketing stays on SendGrid.
Day 1-7: Monitor reputation, bounce rate, complaint rate. Compare to pre-cutover baseline.
Day 7-14: Cut over digests at 25% → 50% → 100%.
Day 14-28: Cut over marketing in 10% steps.
Day 28: Disable SendGrid. Keep DNS pointing for 30 more days in case of rollback.
Day 60: Remove SendGrid DNS entries.

The Common Justifications and Their Reality

"We are migrating because SendGrid is expensive"

The migration itself costs you 2-4 engineer-weeks plus 2-3 weeks of degraded inbox placement. If your saving is < €5k/year, the math is borderline. Above €15k/year, do it.

"We are migrating because deliverability is bad"

Usually the deliverability problem is your sending pattern, not SendGrid. Migration may reset things temporarily, but the same pattern produces the same outcome on the new provider in 60 days. Fix the pattern first.

"We are migrating because of features"

This is the strongest reason. If a feature is missing or worse on SendGrid (e.g. webhook reliability, regional data residency, GDPR-compliant data processing), migration may be the only path.

Closing

The mechanics of leaving SendGrid are simple; the discipline of doing it without a deliverability dip is what separates successful migrations from painful ones. Target SMTP's migration assistant imports a SendGrid suppression list export end-to-end, runs the DNS audit, and the Send-Time Firewall enforces the warm-up cap automatically so the post-cutover IP ramp cannot be accidentally violated by an excited marketing release.