When you have entities in system A and some related data in a second, decoupled system B, and you need to update the data in system B depending on changes to entities in system A, system A needs to provide certain mechanics for this, otherwise you are stuck. System A needs either
an event mechanic where system B is actively informed about certain changes in A, or
a history mechanism where B can query changes happened in A afterwards
(or both, of course). 1 will allow to implement a synchronous update, 2 will allow the implementation of an asynchronous update (for example, in certain time intervals like once a day). Both kind of approaches should utilize non-business keys for identifying and distingushing between entities (and since an email address is clearly a business information which can change during the lifetime of a contact, it is seldom suitable for this purpose). So another requirement on system A is to provide non-business keys which are never ever changed any more after an entity is created.
I do not know much about "Dynamics CRM", but I would be astonished if it does not provide the historic information about the lifetime of each contact, so when contact "Foo" with ContactId 123 was created by merging contacts "Bar1" and "Bar2" with ContactIds 42 and 43, an external system holding data associated with "Bar1" and "Bar2" can scan over all newly created contacts withing the last 24 hours, detect that "Foo" was created by a merge of "Bar1" and "Bar2" and update the associated data accordingly.