Possible Bug - at least an undocumented feature

[WilliamP6]

We have encountered a problem:

Our email has the sequence:

<a

<div

text

</div>

</a>

designed to create a button that is selectable over it's entire area, not just the enclosed text.

Preview creates an email that works as designed, but when the email is sent to our list, Constant Contact generates a </a> before the <div which deactivates the link for the whole button. The second </a> that is actually coded in the email is unmatched by a <a, and therefore is ignored when the html is interpreted. If you want to call to get proof of this occurrence or ask more questions, feel free (after 12:00 please) at , or email me back at

The email itself works. The preview email you send to us works. Also, your editor and preview detect no errors. This only occurs in the live email. We use Spamarrest, so the email gets detained on their website, allowing us to use "Develop:Show Page Source" to inspect the email. This is how we discovered the extraneous </a> tag.

[William_A]

Hello @WilliamP6 ,

I reached out to our higher level Tier 2 technical team, and it looks like this is a common issue in Outlook clients due to how they treat button nesting. All other email clients are showing the email and its functionality properly. As a means of resolving this, the T2 team is suggesting either using an image instead of a button (even a screencap of the button as it appears now could suffice in its stead), if you wish to use the custom code editor. If you're able to figure out what coding Outlook is requiring to make the button function as desired, you're also welcome to retry the live send again with that updated code.

[WilliamP6]

Actually I use a Macintosh. And we inspected the email under our browser and can see the </a> tag Constant Contact introduced into the html. This has nothing to do with the interpretation of the html. It has to do with Constant Contact modifying our html when the email is sent. As I said, a preview email works fine. It is only when the email is scheduled and sent that this happens. And it has been happening for over a year. I don't know if it happens with a <p, </p> imbedded, but it doesn't happen with a <table, </table>. This is really something that is happening in the software on your end, not a user-end problem.

[William_A · Accepted solution]

If you believe the issue goes further than what Tier 2 tested and found, I'd advise calling our general support and requesting a transfer to their team for custom code troubleshooting. They may be able to do more discovery live with you, which is what we generally advise for custom code-related issues.