I’m currently facing a problem with email services using Mailgun in my project, specifically with the password reset process.
I add a password reset URL with a token to my email template, which is what users should receive. For example, I set the URL as:
https://{domain}/forget-password/{token}
However, the emails that the users see contain a different URL, such as:
https://email.{domain}/c/{some-other-token}
The confusing part is that when users click this modified link, it does redirect them back to my intended reset URL.
Here’s a breakdown of the issue:
The URL I try to send is:
https://{domain}/forget-password/{token}
What users receive is:
https://email.{domain}/c/{some-other-token}
Although clicking the modified link does bring them to the original URL, this only works in some browsers, like Firefox and Internet Explorer. In Chrome, the redirection fails, causing users to see a 404 error instead of accessing the password reset page.
Can anyone shed light on why this redirection differs among browsers and how to resolve the issue for Chrome users if possible? Thanks!
Mailgun rewrites your URLs by default because click tracking is enabled. That’s why you’re seeing email.{domain}/c/{token}.
Chrome handles redirects differently than Firefox or IE, especially with certain security headers or cookie policies.
I hit this same problem last year building a user management system. Instead of messing with Mailgun’s tracking settings or debugging browser quirks, I just automated the whole thing with Latenode.
My workflow:
Generates reset tokens
Sends emails through multiple providers as backup
Handles redirects on my end
Tracks delivery without provider click tracking
Now I control everything and don’t worry about provider redirects breaking across browsers. Plus I get automatic fallbacks - if one email service craps out, it switches to another.
You could disable Mailgun’s click tracking, but you’d lose analytics. Latenode gives you reliable delivery AND proper tracking.
Indeed, the behavior you’re encountering is a result of Mailgun’s click tracking feature. When enabled, it modifies your links to monitor user engagement, which is why users see the altered URL with email.{domain}/c/{token}. I faced a similar issue recently while working on password retrieval for a project. Chrome tends to impose greater restrictions on redirection sequences initiated by tracking servers, leading to failures that can result in 404 errors, particularly if the headers or cookies don’t align properly.
To address this, consider disabling click tracking specifically for transactional emails such as password resets. This option is available in your Mailgun dashboard under tracking settings or can be adjusted in the API parameters when sending your emails. This approach preserves your original links while ensuring deliveries proceed without complications. Although it’s possible to construct a custom redirection method for all browsers, turning off tracking for sensitive communications is a more straightforward solution.
chrome blocks those mailgun redirects cuz they’re from a diff subdomain. quick fix: add o:tracking=false when you send password emails through the api. it bypasses the redirect issue completely - works every time.
The real issue isn’t just Mailgun’s click tracking - you’re dealing with email provider quirks that break differently across browsers.
I hit this same problem building auth flows for client apps. Wasted tons of time figuring out why Chrome broke on Mailgun’s redirects while Firefox worked fine.
The fix was taking control of the whole email pipeline. Built a Latenode workflow that:
Sends password reset emails without provider tracking
Uses multiple email services as backups
Handles token validation on my backend
Logs everything for debugging
Now password resets try Mailgun first, then fall back to SendGrid or AWS SES if needed. No redirect issues since I’m not using their tracking.
The workflow validates tokens before sending emails, so expired or invalid requests get caught before they leave my system.
You could disable Mailgun tracking like others said, but you’re still stuck with one provider. This gives you reliability and you’ll never debug browser redirect issues again.
Indeed, this issue often arises from Mailgun’s click tracking functionality, which modifies your URLs for tracking purposes. It’s particularly troublesome in Chrome due to its stricter handling of redirects from third-party domains, leading to the 404 errors you’ve experienced. A solution I found effective last time was to replace the default email.{domain} subdomain with a custom tracking domain. You can accomplish this in the Mailgun control panel under domains, which helps Chrome accept the redirects more readily since they align with your main domain. Alternatively, for critical emails like password resets, consider disabling tracking altogether by setting the o:tracking parameter to false in your API requests; tracking is generally unnecessary for these communications.