We want to develop a process to update subscribers' email addresses. In the process, subscribers will receive an SMS msg with a link to update the email address.

Then we would like to implement a double opt-in process, where after submission of the new address, a confirmation email will be sent to the new address with a link to confirm. Via TriggerSend or injecting to journey with API.

The issue we are facing is that MC updates the email address immediately once it sends a subscriber an email. Therefore, the new email address is being updated before it's fully confirmed.

We thought about a few solutions, but all of them have serious disadvantages:

  1. Using a script, change status to opt-out after send, until the email is confirmed. But this may result in disabling subscribers if didn't confirm the email and actually had a working email before.
  2. Using a script, change email to old one after sending. But again there are issues, like subscriber status, maybe he had an email bounced, then this will affect data and future sends.

I thought of using 1 dummy subscriber for all sends, but I didn't find any documentation on that, and I'm afraid it will cause issues with simultaneous sends from multiple users.

Will appreciate any inputs on the subject. How to approach this issue?

1 Answer 1


SFMC does not update the email address in All Subscribers immediately in ALL scenarios - this is specific to the method you use for sending, see here:


In the first two scenarios where the send is initiated from Sales Cloud, the email address in the All Subscribers list will be updated at send time, but based on the current email address for the Lead or Contact in the Synchronized Data Extension, so you need to ensure that the synchronization interval is sufficient to allow for any email address changes on Lead or Contact records to be reflected in Marketing Cloud. By default, this is every 15 minutes.

For Data Extension based sends, the email address used to send an email to a Subscriber will not be updated based on the value of your email address field in your Data Extension. That’s because by default, this email address is only used when creating a new Subscriber record at send time.

If your Sendable Data Extension contains different email addresses for Subscribers who exist in the All Subscribers list, then you should consider sending the email from a Journey. Alternatively, you can update the email address of the affected Subscribers in the All Subscribers list before sending, or contact Salesforce support and request the default behaviour to be overridden, to allow the Email Address field in a Sendable Data Extension to update the Subscriber record at send time.

Note that if you are sending to a Salesforce Audience from Content Builder Send Flow, either a Salesforce Report, Campaign or a Salesforce Data Extension, then the email address will be updated at send time.

Also when an email address is updated from a Triggered Send, for example a Sales Cloud Triggered Send, an API-based Triggered Send, or a Journey Builder Send Email Activity (which uses a Triggered Send Definition behind the scenes) and the Subscriber status is ‘Held’, then it will be automatically reset to ‘Active’ when the email is sent. Note, this ‘status reset’ behaviour does not currently apply for triggered send definitions created using the Transactional Messaging API.

The way I set up an email change is this:

1 ) set up a field or similar in which the NEW email address is stored.

2 ) KEEP the OLD email address at the same time, until end of process


3 ) Build a service that

3a) validates the new email! List detective, suppression lists.... see closing notes. If the new email is invalid, break process and output an error. edit: consider also that you might not want to allow changing the new email to a value that is already used by another person, which could create duplicates through the backdoor.

3b) creates a dummy ID with a prefix such as

var prefix = emc_
var guid = Platform.Function.GUID()
var dummyID = guid + prefix 

3c) sends out an email via the transactional API using dummyID + new email. This will not update anything, but it creates a duplicate Contact. We will get to that later.

The subscriber now receives an email to their new email, no existing contact is updated.


4 ) if this email is confirmed by clicking a link, make the link target a service that

4a) updates email on all subscribers from OLD to NEW value.

4b) changes the OLD email field to value of NEW email in your starting location.

4c) empties NEW email field in starting location

4d) makes sure that everything relevant for your business logic, that was stored using the old email as key (think auto suppression lists - sendable DEs with PK email address), is updated like all subscribers.

4e) updates the email in the master system, could be SFSC, could be SFMC, could be something completely different; depends on your setup


5 ) set up daily contact deletion automation; Determine a time after which you say the link does no longer need to work (1 day, 14 days...) Select all people from All Subscribers whose Key starts with your prefix and whose creation date is older than your defined time.

Something like

SELECT SubscriberKey 
FROM _subscribers
WHERE key LIKE 'emc_%'
AND DateJoined <= /* insert your timing */

Insert them into your contact deletion process, which clears the duplicate and will make the confirmation link non-functional. Note that this should happen regardless of user confirming or not. All your dummy IDs have to go.

optional 6) If you need tracking information about that email you sent for confirmation, make sure you back that tracking data up somewhere before the contact with all its associated data is deleted / anonymized.


limitations: Anything that prevents transactional sendouts makes this fail.

  • List detective blocks the transactional message, if the new email is invalid for list detective, the whole process cannot be completed.

  • Auto suppressions for transactional messages: if the new email is on one, the whole process fails.

This can get especially fun if a new email address is 100% VALID for other systems in your infrastructure, but INVALID for marketing cloud (because list detective says that you cannot be [email protected] !).

The other system might require the change, but SFMC cannot perform it.

So the whole process only makes sense for subscribers intended for use in marketing cloud.

For everything else (think of a connected infrastructure - "i want to change email to a commerce cloud profile"), the implementation pattern is still useable, but SFMC is the wrong system to implement the email change in. You cannot stop SFMC from using its validation logic (you can only soften it up).

So SFMC by design enforces blocking logics that make no sense in any other system, preventing a commerce cloud profile's email change to [email protected] (which is a valid thing to do) because Marketing Cloud has a list detective that decides this. This is absurd and you have to avoid coming into a situation where you have to explain this.

  • 1
    You, sir, were 21 seconds faster than me :-) In respect, I shall remove my post, as great minds think alike :-P Commented Nov 17, 2021 at 10:11
  • sweet! good thing i went for coffee after posting. Commented Nov 17, 2021 at 10:34
  • @JonasLamberty first, thanks for the amazing solution. But why not use 1 dummy subscriber without deleting him at all. The system will just update the new email every time. And if so, can we scale with it to let's say hundreds of sends in an hour?
    – yoni
    Commented Dec 13, 2021 at 14:03
  • this might even work, but setting up a process that wants to update the same record over and over, potentially from separate sources, potentially at the same time, just screams conflict. In case of such a conflict, it will immediately be customer-facing, as it risks sending emails to a wrong person, and email change is sensitive. I wouldn't risk that. Also, you make logging on unique id level pretty much impossible, because always logging the same ID doesn't help when you want to differentiate. Contact deletion with separate dummy-Ids enables you to have a temporary logfile with unique events. Commented Dec 13, 2021 at 14:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .