Today's guest post comes from Travis Murray. Travis is a Deliverability Engineer based in Canada. He has spent the last five years guiding clients and helping his peers with their deliverability concerns.
(Psst--hiring for deliverability? He's somebody you should consider. He's looking, and he's a smart person.)
The impact of SSL on Email Deliverability has always been a less obvious one. Securing a page does not directly help inbox placement but having insecure content or links in emails can result in fewer people clicking through and having less trust in a brand.
Since Chrome 68 (July 2018), Chrome has been marking sites connected under HTTP as “Not Secure”. This has generally been easy to explain: SSL is needed if a site collects any kind of sensitive information, such as passwords, payment information, etc. If subscribers are browsing a page over HTTP, even without sensitive information, I still strongly suggest considering SSL. Without SSL, these activities can be recorded or monitored, which is especially risky for subscribers using public Wi-Fi.
Google has announced that it will be pushing this point further. Over the past few months, it has been moving to have Chrome ensure that secure pages only download secure files. This will become the most impactful in Chrome 86 when it begins blocking insecure images on secure pages.
You have likely already seen a number of the mixed-content messages if your client has used a page that is secured but the page is pulling in content over HTTP, not HTTPS. With images, this is classified as mixed “passive” content, which is less of a security concern than mixed “active” content, such as an unsecured script file running on a page. This is still a poor security practice that you will want to help them with to prevent issues moving forward.
Some example scenarios:
If they use secure landing pages with any insecure images then they need to secure those endpoints as soon as possible.
If they use a platform to build their emails that is secured, but their images are insecure then they need to secure those endpoints as soon as possible.
If they send emails with no secure links (so no mixed content errors) then … they should still consider securing their endpoints as soon as possible.
Clients will want to test for these errors on landing pages, inboxes, the platform where they build their emails and any other tools they use that might try to load actual resources from their emails.
In my testing, larger ESPs like Gmail, Yahoo and Hotmail all proxy insecure images and do not currently show a mixed content warning. This leads me to believe those inboxes will not have issues loading images post-Chrome 86, at least that is my hope. I would not expect smaller ESPs or B2B email clients to do this.
If you have a client who is considering leaving their URLs insecure for some reason, I would leave them with this forward thinking note from the Chromium Blog: “In the future, we expect to further restrict insecure downloads in Chrome. We encourage developers to fully migrate to HTTPS to avoid future restrictions and fully protect their users.”
Today's guest post comes from Travis Murray. Travis is a Deliverability Engineer based in Canada. He has spent the last five years guiding clients and helping his peers with their deliverability concerns.
You can connect with him on Linkedin or contact him via email.
(Psst--hiring for deliverability? He's somebody you should consider. He's looking, and he's a smart person.)
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.