Why SFMC Sends to the Old Email: All Subscribers List Override

One of the most confusing bugs in SFMC: the customer updated their email in the client's system, the nightly file import brought the new address into the Data Extension, but emails still go to the old address.

We've seen this on multiple engagements. Takes someone who's seen it before to diagnose in under an hour.

The cause: two places store email addresses

SFMC keeps email addresses in two independent places:

1. Data Extension - the email column of whichever DE the send uses.
2. All Subscribers List - the account-level master list, keyed by Subscriber Key.

When SFMC sends, and the subscriber's Subscriber Key already exists in the All Subscribers List, it uses the email from the All Subscribers List - not the email in the Data Extension.

So even if the DE has the new email, the All Subscribers List still holds the old one. SFMC follows the old one, email goes to the wrong address.

Why it's designed this way

The All Subscribers List is SFMC's single source of truth for who a subscriber is at the account level. Subscribers can belong to multiple DEs and multiple sends, but their "identity" (Subscriber Key -> email) lives once in All Subscribers.

When you send from a DE, SFMC reconciles the DE rows against All Subscribers. If there's a conflict (different email for the same Subscriber Key), the All Subscribers version wins.

This is actually useful in normal operation - it prevents inconsistent email addresses drifting between multiple DEs. It's only surprising when you're trying to update the email.

The fix: update the All Subscribers List too

Updating the DE alone isn't enough. You also need to push the email change into the All Subscribers List. Methods:

Method 1: Import directly to All Subscribers

Use the Import Subscriber Wizard (Email Studio > Subscribers > All Subscribers > Import) and import a file with Subscriber Key + EmailAddress. Update type: Add and Update. The Subscriber Key matches existing records; email gets updated.

Method 2: Email Address Update automation

For regular updates, build an Automation:

Runs daily alongside whatever updates the DE.

Method 3: AMPscript UpsertContacts

For real-time updates via API, AMPscript functions like UpsertContacts() can push into the All Subscribers side on demand.

What about new subscribers?

If a subscriber's Subscriber Key doesn't yet exist in All Subscribers List, SFMC auto-creates the record using the email from the DE on the first send. No override problem because there's nothing to override.

The issue only appears when the Subscriber Key already exists with an old email value.

Diagnosing it on a live engagement

If a client reports "emails going to wrong address," check in this order:

1. Query the DE: does it have the new email?
2. Go to Subscribers > All Subscribers, search for the Subscriber Key. What email is stored there?
3. If DE has new email but All Subscribers has old, you've found it.

Test by updating the All Subscribers record manually (it's editable in the UI) and doing a test send. If the send goes to the correct new address, confirmed diagnosis.

Prevention on new engagements

Include an All Subscribers sync in the data pipeline design. Whenever customer email updates flow into SFMC, they should update both the relevant DE(s) and the All Subscribers List. A separate Import Activity targeting All Subscribers runs alongside the DE import.

Document this in the runbook so it doesn't get dropped when someone new picks up the engagement.

Takeaway

The DE is not the source of truth for email addresses - the All Subscribers List is. Update both when email addresses change. Build the sync into the data pipeline from day one, not as a patch after the first angry client call.

---

Shipping an SFMC subscriber management pipeline? Our Salesforce team sets up All Subscribers sync, Contact Builder attributes, and identity resolution on production engagements. Get in touch ->

See our full platform services for the stack we cover.