Fix email tracking with SSL websites
Using email tracking with SSL website prevents user to perform the action with Google Chrome.
If you use SSL with HSTS, it triggers big warning in Chrome when the user click on the link http://cl.ly/image/0A373O2r3539
Email tracking in mailgun is performed by replacing links in email by a custom subdomain setup in the admin panel, ie email.domain.com which as to be configured as a CNAME for mailgun.org.
Chrome will try to access httpS://email.domain.com which will fail because the underlying server is mailgun.org and not domain.com's server.
Instead of pointing email.domain.com => mailgun.org, configure your server for https://email.domain.com and redirect every request (with parameters) to https://mailgun.org/$requestedURI.
Then the usual mailgun tracking system can track click and redirect to the right domain.com url.
This could be easily done if there was a way to override the mailgun admin panel check for the CNAME record, ie a checkbox "I've setup a forwarding subdomain to mailgun.org"
A degrated version would be to have links replaced by https://mailgun.org/click?ID but this would probably harm deliverability for mail coming from domain.com (and not mailgun.org)
More info on SSL HSTS: http://en.wikipedia.org/wiki/HTTPStrictTransport_Security
Darren Ravenscroft commented
Thought this could do with another comment.
Extremely infuriating that this doesn't have a default method without all the work around nonsense.
Small hint for Mailgun engineers: Cloudflare is able to mark the certificate as valid (in strict mode) based on either left side or right side of CNAME record, e.g.
email.example.com CNAME mailgun.org
Cloudflare would consider connection valid if https://mailgun.org returned SSL certificate for email.example.com or mailgun.org
Before you implement a proper HTTPS solution (you may check out SSL for SaaS), you could just buy a single domain cert for mailgun.org and upload it, as a workaround.
Quick update: Mailgun are able to write tracking links as HTTPS for custom tracking domains, but this must be manually requested from them. Turns out it's a bit of a 'secret menu' option.
You will be asked to confirm you have already setup your custom domain through a CDN as HTTPS (they also recommend the Cloudflare method previously mentioned). Once you have confirmed, they can enable writing HTTPS tracking URLs for you.
Obviously, Mailgun are not actually handling any of the certs with this approach. This may actually be preferable for some people, if you don't want more third-parties generating certs for your domains/subdomains.
Either way, I can confirm that they are able to get this working!
I had trouble getting these other solutions working, but I found another service called JangoSMTP which offers this, apparently for no extra cost. I did a quick test with one of my client domains and it worked.
https://jangomail.zendesk.com/hc/en-us/articles/360005953214-Enabling-HTTPS-on-your-Custom-Tracking-Domain for anyone who's interested!
Introducing SSLMate for SaaS - Get Certificates For Your Customers' Vanity Domains: https://sslmate.com/blog/post/introducing_sslmate_for_saas
Hope this is useful to the Mailgun people.
Miloš Havlíček commented
Please implement this feature. It is important for us. Solution could be to automatically generate Let's Encrypt certificate like e.g. uptimerobot.com do for customers status pages on their subdomains.
I can confirm that S C's suggestion of piping the traffic through Cloudflare over HTTPS works. It's by no means a perfect solution, since the initial HTTP request is made over plain HTTP and could be intercepted/redirected/modified in some way.
One the request reaches Cloudflare, it is redirected to HTTPS for the redirect to Mailgun's server occurs, after which the (HTTP) redirect to your own URL (hopefully HTTPS) occurs.
So there are still parts of the process that are not HTTPS, and can't be until Mailgun start using HTTPS for tracking links.
As of April 2018, the free 'flexible' TLS Cloudflare option only covers one level of subdomain (e.g. subdomain.domain.com), not two levels (e.g. click.subdomain.domain.com). To get TLS working for two levels of subdomain, Cloudflare requires that you purchase a dedicated certificate (https://support.cloudflare.com/hc/en-us/articles/228009108-Dedicated-SSL-Certificates - currently $10 per month), with which you can specify your Mailgun tracking domain (and up to 50 subdomains on the same domain).
After the certificate is live, the traffic for the tracking domain can be put through Cloudflare by switching the cloud to orange.
After that, you'll want to turn 'Always use HTTPS' on. It's up to you how much you want to make the change permanent, and if you want to deploy HSTS including subDomains/preloading. Be careful though - do your research on HSTS before comitting :)
To repeat, this is not an ideal solution or a silver bullet - it's a part-workaround at best and only fixes part of the problem. But it does at least allow for full HSTS and preloading.
HSTS preloading of course, should not be the main motivation for HTTPS tracking links. The idea is that the URLs customers are clicking on cannot be messed with by a malicious third-party.
To address the issue properly, Mailgun need to implement TLS at their end. Granted, this feature request was made in 2014, when providing SSL/TLS certs for customers' domains would've been arduous and expensive. But with Let's Encrypt launching two years ago in April 2016, this is something they've been technically able to do for a long time, and there isn't much excuse for not doing so nowadays.
If there is a good reason it hasn't been implemented, please do let us know.
I have queried this with Mailgun on Twitter. Apparently it is "in the pipeline" - though they said the same at the end of last year.
Tweet thread: https://twitter.com/ian_oliver/status/980764256504307712
Can you please fix this. It's an absolute pain.
Miloš Havlíček commented
It is important for us to this issue be solved ASAP. Without it we cannot use includeSubDomains directive and so we cannot use HSTS preloading because of the directive is not presented. Workarounds are so tiring.
S C commented
Bit of info for anyone coming here looking for a solution to this long-standing issue:
The links generated can be sent via a server configured as a proxy and still work (caveat being depending on the config the (true) client IP may no be visible in your reports). They will still be written in the email as http links obviously but if your proxy webserver is upgrading these to https (or you are using HSTS at the client to do this) then you will still be fine to simply pass these requests back to http://mailgun.org/$1.
If you don't wish to run your own proxy then you can use a DNS/CDN such as Cloudflare to do this for you. If you go the Cloudflare route (which is what I continue to use until this is addressed properly by Mailgun) then you need to:
1. Set up Cloudflare for your domain including SSL
2. Create the CNAME as per your domain config in Mailgun - have this as a direct CNAME (grey cloud)
3. Verify DNS settings at Mailgun to enable further tracking config
4. Change CNAME at Cloudflare to a proxied connection (orange cloud)
5. Configure traffic to the above subdomain as 'Flexible SSL' (that is client->CF can be SSL, CF-> backend will be plain http).
a. If you are using an SSL mode other than Flexible (e.g. Full or Full Strict) then accomplish the above by creating a page rule: URL= yourtrackingsubdomain.domain.com/* SETTING= SSL to Flexible
Now links in emails (which will be http) can be accessed as either http or https and Cloudflare will present your valid cert before proxying to Mailgun on an insecure link. Onl dowside is that the visitor IP shown at Mailgun will in all likelihood be that of the CLouflare proxy, not the end-user.
I hope this helps until Mailgun address the problem.
Joe Fletcher commented
The sole reason I started using Mailgun was for open tracking, but just discovered I can't use it until they have an HTTPS solution for these subdomains since I use HSTS with includeSubDomains - because in 2017 all domains should use HTTPS Everywhere, especially a mail service with tracking! :) Nonetheless, Mailgun is very cool and I'll keep using it without tracking till a solution is provided.
This is a glaring oversight, and has been an issue for several years. Is there any work being done on solving this?
How has this not been resolved yet?
Vazgen Hakobjanyan commented
ok so how we change email domain for email tracking "if HSTS is enabled on your domain" ? I cant find any api.
Damian Nowak commented
Yeah, now that we have Let's Encrypt, Mailgun can simply use it as they have control over the "email" subdomain due to CNAME record.
Without SSL tracking these days, Mailgun's tracking feature simply doesn't exist. (Read: it's unusable junk)
Andy Gambles commented
Solution is either allow us to supply a certificate OR allow us to use any verified domain as a tracking domain (which is how Mandrill works). We could then add a non HSTS domain as a verified domain and use this for tracking.
Viktor Nagornyy commented
Here's a possible solution, which is what KeyCDN started doing if you use CNAME to brand URLs they serve from their network.
Use free Let's Encrypt certificate for CNAME sub-domain, this way there's no additional charges for SSLs and we are able to use HTTPS in our tracking links. Simply give us an option to enable free SSL certificate for CNAME sub-domain, and your system provisions SSL certificate for our sub-domain using Let's Encrypt.
More info on what KeyCDN did with Let's Encrypt:
It works great.
Uriah Galang commented
how can i apply the proposed solution it is quite confusing any visual guide to help me out thanks
Jacob Magnusson commented
This is really frustrating. Do you plan to take any action on this?
Perhaps one solution would be for us users to host the subdomain and then let us do a reverse proxy to your click tracking server.