81 votesS C commented
DMARC isn't really something for Mailgun to support... DMARC is just your domain telling recipients what to do with emails that fail to pass SPF and DKIM checks. As Mailgun do support SPF and DKIM then any DMARC policy you want to publish will work alongside their service.
I see no benefit to Mailgun creating a 'DMARC record generator' when others already exist for this. These policies can vary widely so it's not just a quick 'heres your DMARC record' blob for you to blindly cut and paste.
As for Mailgun handling DMARC reports, there may be a benefit to this but it is very likely that they'd get reports for email sent from other sources along with themselves. It's far better to have a dedicated service such as dmarcian or postmark look into this.
Although this is very highly voted I see little reason for Mailgun to enter this market. they should focus on improvements to their core business - sending email.
135 votesS 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.