The need for double opt-in (“email confirmation” in Infusionsoft-speak) is significantly reduced when using WeDeliver.Email – it also introduces a specific issue as described below.

Historically, the use of double opt-in served several purposes:

1. Confirmation that the user/email address is genuine
2. A way of getting Infusionsoft to send mails from a “more trusted” server that is only used to send emails to double opted-in contacts and hence getting better deliverability – this is made redundant by using WeDeliver.Email
3. A way of protecting against Infusionsoft penalising you for spam complaints – they are less likely to take action against spam complaint from double opted-in contacts. But again, this is less of a risk using WeDeliver.Email as the ISP spam complaints will go to Mandrill etc. rather than Infusionsoft.

The challenge that we face is that it’s the email address that gets double opted-in, not the contact itself.

There is little point sending a confirmation email to the Email2 address as we would only want their primary address to be confirmed within Infusionsoft, but of course by sending the email to Email1, the risk of undeliverability is higher.

Furthermore, when a contact clicks a double opt-in link that is sent to their Email2 address, they will see a message saying that the address xxxxx-xxxx@wedeliver.email has been confirmed, rather than their correct email address. This is bound to cause confusion!

For this reason, my strong recommendation is to not use the Infusionsoft email confirmation “locked” sequence. Instead, replace it with a standard sequence containing an email that sends out a “link click” email to the Email2 address. This should then lead into a “Link Click” goal which would then move on to the rest of the campaign.

This would still serve the purpose of allowing a contact to confirm that they are legitimate, but would confirm the contact itself rather than confirming a specific email address.