Why some email links won't work, and how to fix them (the HSTS)

You have tried to add a link in your campaign that leads to a website. You type the domain, but when you click Use, you see a red notification telling you that the link won't work on email send. This is because the domain that you are linking to is a bit more strict on the rules of how they would prefer to be visited. Let's get into some details. The following explanation does get a little technical:

The HSTS issue

If you are using your own sending domain instead of our Loopify domain (email@lpy.io) and your links from your email don't seem to work properly, there is a high chance that your domain has a strict policy on links:

"The HTTP Strict-Transport-Securityresponse header (often abbreviated as HSTS) allows a website to tell browsers that it should only be accessed using HTTPS, instead of using HTTP."

Now, what does this mean?

We are using MailGun as an email provider to send emails and they do not support forced HTTPS redirects. If there is a strict domain that forces HTTPS redirects via HSTS, the tracking link cannot finish the callback to MailGun's servers and it results in a failed link. 

Currently, Mailgun doesn't officially support HTTPS tracking links. If the tracking cookie (after the /c/ in the URL) wasn’t generated by the domain in the URL, the link will not resolve.

Workaround

There is a workaround though (as stated on their website), which requires the use of a CDN. They recommend utilizing CloudFlare, even though most CDNs should suffice. Here are the full steps to the workaround.

Another approach is to create a reverse HTTP proxy. Instead of pointing your CNAME record to mailgun.org, you point it to your server. Your server can then proxy the requests to MailGun.
An example of how to do this with IIS can be found here: https://techcommunity.microsoft.com/t5/iis-support-blog/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world/ba-p/846222.

Here's an IIS web.config example:

example of IIS web.config:<?xml version="1.0" encoding="utf-8"?>
<configuration>
	<system.web>
		<httpRuntime maxUrlLength="2000"/>
	</system.web>
	<system.webServer>
		<rewrite>
			<rules>
				<rule name="lets-encrypt-well-known-verification" stopProcessing="true">
					<match url="^\.well-known/(.*)$"/>
					<action type="None"/>
				</rule>
				<rule name="Proxy" stopProcessing="true">
					<match url="(.*)"/>
					<action appendQueryString="true" type="Rewrite" url="http://mailgun.org/{R:1}"/>
				</rule>
			</rules>
		</rewrite>
	</system.webServer>
</configuration>

For azure app service environments you also need this file in the site directory:
applicationHost.xdt
<?xml version="1.0" encoding="UTF-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.webServer>
<proxy xdt:Transform="InsertIfMissing" enabled="true" preserveHostHeader="true" reverseRewriteHostInResponseHeaders="false" />
</system.webServer>
</configuration>

An example using nginx can be found here: https://connortumbleson.com/2021/03/29/ssl-tracking-links-on-mailgun-with-ghost-blog/

The HSTS can also include sub-domains if any request made to your site could have the following Response Headers property: Strict-Transport-Security: max-age=16070400; includeSubDomains. 

Note: remember that this problem can reoccur in the future if you at one point decide to make your domain strict again!

So, if you are using HSTS on your domain, an option would be to disable it, use a different domain with HSTS disabled, use our own sender domain that goes through lpy.io instead or try the workaround!