Marketing campaign email delivery fails after Summer '23 cloud migration

We completed our cloud migration to Summer '23 three weeks ago, and since then our marketing campaign emails are not being delivered. The campaigns show as “Sent” in Salesforce, but recipients report never receiving the emails. Our email bounce rate has jumped from 2% to 68%.

I’ve verified the SPF and DKIM records in our DNS configuration:


TXT record: v=spf1 include:_spf.salesforce.com ~all
CNAME: salesforce._domainkey → salesforce._domainkey.acme.com

Email deliverability testing through Salesforce Setup shows “Configuration Valid” but actual campaign sends fail. Our IT team confirmed DNS propagation is complete across all nameservers. The sender authentication package was deployed during migration, but something isn’t working correctly.

Before the migration, we were using Marketing Cloud Connect with proper sender authentication. Now emails either bounce or land in spam folders. Has anyone resolved email delivery issues after Summer '23 cloud migrations?

Complete solution addressing all three focus areas:

SPF/DKIM Configuration Correction: Your SPF record is correct, but the DKIM configuration needs immediate correction. Here’s the proper setup:

  1. Retrieve correct DKIM values: Navigate to Setup → Email Administration → Deliverability → Sender Authentication. You’ll see entries like:

Domain: acme.com
Selector: s20230601
Host: s20230601._domainkey.acme.com
Value: s20230601._domainkey.salesforce.com
  1. Update DNS CNAME records: The selector changes with each migration. Your IT team needs to add:

Type: CNAME
Name: s20230601._domainkey
Value: s20230601._domainkey.salesforce.com
TTL: 3600

Critical: The selector prefix (s20230601) is unique to your Summer '23 migration. Don’t use generic documentation.

  1. Verify SPF includes: Confirm your SPF record includes Salesforce:

v=spf1 include:_spf.salesforce.com include:_spf.google.com ~all

The ~all should be ~all (soft fail) not -all (hard fail) during testing.

  1. Add DMARC policy: If missing, create this TXT record:

_dmarc.acme.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@acme.com; pct=100"

Start with p=none (monitoring only) until DKIM is working, then gradually move to p=quarantine then p=reject.

DNS Propagation Verification: Three weeks is excessive for DNS propagation - this indicates the records weren’t updated correctly. Implement this verification process:

  1. Immediate verification using command line:
nslookup -type=TXT acme.com
nslookup -type=CNAME s20230601._domainkey.acme.com

Expected output should show the Salesforce DKIM target.

  1. Check all nameservers: Your domain likely has multiple nameservers. Verify each one:
dig @ns1.yourdns.com s20230601._domainkey.acme.com CNAME
dig @ns2.yourdns.com s20230601._domainkey.acme.com CNAME
  1. Monitor propagation globally: Use online tools like whatsmydns.net to check propagation across different geographic regions. DNS should propagate within 24-48 hours maximum.

  2. Clear local DNS cache: After updating records:

  • Windows: `ipconfig /flushdns
  • Mac: `sudo dscacheutil -flushcache
  • Linux: `sudo systemd-resolve --flush-caches
  1. Reduce TTL temporarily: Before making changes, lower TTL to 300 seconds (5 minutes). Wait for old TTL to expire, make changes, then restore normal TTL (3600 seconds).

Email Deliverability Testing Process: Systematic testing prevents resuming campaigns before authentication is fixed:

  1. Salesforce built-in test: Setup → Email Administration → Deliverability → Test Deliverability

  2. Manual header verification: Send test email to yourself, view full headers:


Authentication-Results: spf=pass smtp.mailfrom=acme.com;
  dkim=pass header.d=acme.com header.s=s20230601;
  dmarc=pass header.from=acme.com

All three (SPF, DKIM, DMARC) must show “pass”.

  1. Test across providers: Send test campaigns to:

    • Gmail (strictest DKIM validation)
    • Outlook/Microsoft 365
    • Yahoo Mail
    • Corporate domains with strict filters
  2. Verify sender reputation: Summer '23 migration may have reset your sending reputation. Check:

    • Google Postmaster Tools
    • Microsoft SNDS
    • Return Path Sender Score
  3. Gradual ramp-up: After authentication passes:

    • Day 1: Send to 10% of list
    • Day 2-3: Send to 25% if deliverability is good
    • Day 4-7: Gradually increase to 100%

This rebuilds sender reputation post-migration.

Root Cause: Summer '23 cloud migration invalidated your old DKIM keys and generated new ones. Your DNS records weren’t updated with the migration-specific DKIM selector, causing authentication failures. Email servers rejected messages or marked them as spam due to failed DKIM validation.

Implementation Checklist:

  1. ✓ Retrieve exact DKIM values from Salesforce Setup
  2. ✓ Update DNS CNAME records with correct selector
  3. ✓ Lower TTL before changes, wait for propagation
  4. ✓ Verify DNS propagation using nslookup/dig
  5. ✓ Test deliverability using Salesforce tools
  6. ✓ Send test emails to major providers
  7. ✓ Verify authentication headers show “pass”
  8. ✓ Gradually resume campaign sends
  9. ✓ Monitor bounce rates and spam complaints
  10. ✓ Restore normal TTL values after confirmation

Prevention: Document the exact DKIM selector and DNS records immediately after any Salesforce migration. Include these in your migration runbook. Set calendar reminders to verify email authentication monthly.

After implementing these corrections, your email deliverability should return to normal within 48 hours. The 68% bounce rate will drop as updated DNS records propagate and receiving servers recognize the valid authentication.


This draft is based on general Salesforce knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

Summer '23 requires DKIM key rotation for migrated orgs. Your CNAME record looks incomplete. You need the full DKIM selector that Salesforce generated during migration. Check Setup → Email Administration → Deliverability → Sender Authentication. Copy the exact CNAME records shown there.

The SPF record is correct, but I suspect your DKIM CNAME is pointing to the wrong target. After cloud migration, Salesforce assigns a new DKIM selector specific to your pod. The CNAME should look like: s20230601._domainkey.acme.com CNAME s20230601._domainkey.salesforce.com where the selector prefix matches your migration date. DNS propagation taking 24-72 hours is normal, but three weeks suggests the record itself is wrong. Use dig or nslookup to verify what your DKIM record actually resolves to.

Ran nslookup and found the DKIM record is pointing to our old domain configuration. The selector in DNS doesn’t match what Salesforce Setup shows. IT made the changes during migration but used outdated documentation. This explains why validation passes but emails fail delivery.

That’s the issue. Summer '23 migration generates new DKIM keys and you must update DNS records with the exact values from Salesforce Setup. The old DKIM keys are invalidated during migration. Also verify your DMARC policy - if it’s set to quarantine or reject and DKIM fails, emails will be blocked entirely.

Quick check: What’s your TTL on the DNS records? If it’s set high (like 86400 seconds/24 hours), even after correcting the records, you’ll need to wait for cache expiration. Consider temporarily lowering TTL to 300 seconds while fixing this.

Don’t forget to test after updating DNS. Salesforce provides an email deliverability test tool under Setup → Email Administration → Deliverability → Test Deliverability. Send test emails to multiple providers (Gmail, Outlook, Yahoo) to verify authentication headers are correct before resuming campaign sends.