Any news ?

Hi Chris, do you have any updates regarding this?

Running into this issue now. It would be good to have a way to handle this and guidance.

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.

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.

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.

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.

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?

ok so how we change email domain for email tracking "if HSTS is enabled on your domain" ? I cant find any api.

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)

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.