Our work e-mail server has started rewriting links in incoming mail through a redirecting gateway, for "security reasons": if I receive an e-mail containing a link to https://security.stackexchange.com, the link gets rewritten to


before the mail arrives into my Inbox. Clicking on this opaque blob redirects me to https://security.stackexchange.com.

Presumably, the idea is that if the target address turns out to be malicious then the mail server provider (Sonicwall) can decide to block the link even retroactively in messages that have already been delivered.

Is this kind of link tracking considered good security practice? Are there any authoritative opinions on it from researchers, for instance? At a first thought, I can come up with many disadvantages, and minimal advantages (but I am no security expert).

I have tried looking for opinions online, but the only articles I find come from people that are trying to sell similar technology, so they might be biased: for instance this, this and this.

  • 43
    One immediate drawback I can see is that it becomes harder to differentiate legitimate and illegitimate URL. (Not saying the displayed URL should be trusted anyway.)
    – Yuriko
    Sep 2, 2022 at 14:21
  • 26
    @Yuriko Yes, and it is not the only drawback; for instance, breaking PGP signatures, privacy issues (Godaddy can track every time I clicked on a link in my e-mail and from where), training users to click mindlessly on long URL blobs. Sep 2, 2022 at 14:24
  • 4
    Also see Is a safelinks.protection.outlook.com link phishing? for a discussion of the issues with Outlook's ATP Safe Links. Sep 3, 2022 at 4:34
  • 9
    The overwhelming and obvious downside is that these days, when anyone gets a link from "fexed.com" or "amazoon.com" (note the spellings) we all know instantly it's a silly spam. The system in question eliminates this; you have utterly no idea what you are clicking. You have to click to find out - which is a terrifying concept!
    – Fattie
    Sep 4, 2022 at 16:29
  • 2
    an other con: it may render the url unusable. For example: the URL could be only accessible from a vpn/specific host that blocks connections to the internet, so clicking the url/copying it into a VM/browser with the VPN can lead you to a network error and you then have to copy the text of the URL instead (and if who sent you the link overrode the text you'd have to manually de-encode the url hoping it contains the proper url encoded and not just an identifier for it).
    – GACy20
    Sep 5, 2022 at 7:53

4 Answers 4


This practice actually has a bunch of security downsides that make it problematic.

First, modifying the email breaks any sort of digital signature on it, such as DKIM. This can be used by the mail server or the mail client to verify that the author is who they say they are. For example, if your mail client says, "This email is from stackexchange.com," then you can know that the email may be legitimate if it looks like a StackExchange email, but this can't be done if you modify the email.

Second, it also means that the URL no longer points to the actual domain. This makes phishing easier, since every illegitimate link looks just like a legitimate link: it goes to some rewritten domain. If the user is expecting a link to an internal domain, they can no longer determine if the link is legitimate just by looking at the hostname in the URL.

A better practice would be to use some sort of endpoint software or trusted DNS server which logs all domains used or disallows known malicious sites. This is common in a lot of places and avoids the security downsides of tampering with data. You can also scan them when they come into the server and look for suspicious looking URLs, such as those which look like some sort of impersonation attack on legitimate domains or those which are known to be associated with malware or phishing.

I also should point out that you should not under any circumstances use a TLS intercepting proxy as Steffen Ulrich suggests. Security research has found numerous vulnerabilities in these devices, including weak algorithms, insecure protocol versions, and lack of certificate validation, any of which can mean that data can just be decrypted by an attacker. What's more, they are often just functionally broken and don't speak the protocol correctly, which I can tell you from years of dealing with end user problems as a Git contributor.

  • 2
    "... should not under any circumstances use a TLS intercepting proxy as Steffen Ulrich suggests. Security research has found numerous vulnerabilities in these devices," - TLS interception is a trade-off between having reduced visibility and impacting privacy. And severe vulnerabilities have been found in many security software - like VPN, antivirus, firewalls ... . Does this mean none of these should be used? And of course vulnerabilities are also often found in mail servers, browsers, office programs ... - should these not be used too? Have fun using anything with this kind of argument. Sep 3, 2022 at 15:15
  • The proposal with denying access to a domain by using the DNS server is a good point. But it has its limits since it only sees the domain without having any context and without knowing the full URL and its content. This helps with phishing on domains registered by the attacker, but not with a common type of phishing where the attacker misuses some path in a compromised domain. For example Cisco Umbrella started with a pure DNS based approach (by buying OpenDNS) but after a while has also added a TLS intercepting web proxy to it to provide more visibility. Sep 3, 2022 at 15:28
  • 2
    @SteffenUllrich: If TLS interceptors are to be tolerated, the original certificate should be added as an attribute to the intercepting certificate so the browser/user can inspect it. It also turns out that by doing so this closes most of the vulnerabilities (although not TLS version downgrade).
    – Joshua
    Sep 3, 2022 at 16:10
  • 1
    @SteffenUllrich: The back pressure against TLS interceptors will continue until until such a thing is done. (Manual inspection doesn't help. Closing the vulnerabilities requires an automatable version.)
    – Joshua
    Sep 3, 2022 at 17:33
  • 1
    @Joshua: I'm not sure. From my experience the amount of TLS interception actually increased - because the amount of TLS increased and there is the need for visibility in order to detect attacks. But let's just disagree and stop the discussion - this is not the right place for it. Sep 3, 2022 at 17:52

This is done by a number of providers; however it has a number of downsides that mean it is often preferable to just scan for bad links rather than modify them.

  1. It breaks PGP or SMIME digital signatures. This is a big one, as it prevents end-to-end verification unless encrypted. DKIM signatures can be validated by your mail gateway before modification, and warning headers added by wrapping a mime-multipart-inline around the signed wrapper, but body modification will definitely break signatures.
  2. It prevents users from visually verifying valid URLs. You have no way to spot phishing URLs yourself any more, and have passed complete agency to the monitoring software.
  3. It may break use-once URLs. Some security systems send out use-once URLs to access things. If this system checks a link by downloading it to check before passing on, it is possible that this can result in a double-retrieval which will prevent the end use from accessing a use-once URL. I have seen this happen with Sympa (mailing list software)
  4. You would likely get just as good protection by checking for dubious URLs, and adding a Subject tag or mail header (or quarantining the entire email) if something looks suspicious.

On the one hand, it is good that some sort of scanning is taking place. That's better than nothing! But the way it has been implemented possibly has too many downsides and so I would not call it best practice. Scanning inbound emails, and checking for suspicious URLs, is definitely best practice but not necessarily making modifications to the incoming email.

  • 3
    The one-use thing is an excellent point. A common example is Slack, the robot links of which are staggeringly badly and inconveniently programmed and constantly fail in casual use due to the once-only aspect of the way they are done. The system in question destroys the ability to use systems like Slack.
    – Fattie
    Sep 4, 2022 at 16:31
  • The one-use problem is not specific to only URL rewriting but happens also when the link is checked at the moment the mail is received by the firewall, i.e. even if no modifications are made to the mail. And the proposed change of the subject in suspicious mails (#4) has also the problem of breaking signatures (#1). Sep 5, 2022 at 18:49

The best security can be provided if the link gets analyzed at the moment it is visited. At this time the most recent reputation information about link and domain are available. And ideally the actual content behind the URL from the perspective of the visitor should be included in the decision too. This can be achieved if all web traffic of the user is analyzed in a TLS intercepting web proxy, as often included in corporate firewalls. Since everything is passed through the proxy no explicit URL rewriting need to be done.

Passing all web traffic over an analyzing proxy can not be done in all situations though, especially not if the access device is not in full control of the company - like when using devices not in full control of the company (BYOD). And TLS interception might be seen as a problem too, sometimes for performance reasons and often for privacy.

The second best option is thus not to have the actual content of the page from the perspective of the user, but at least analyze the link at the time of access to get the latest reputation information and to also check the content of the page from the perspective of the analyzer. This might be the same as seen from the user, but some sites detect analyzers and provide them different (innocent) content than the actual victims. This second best option can be achieved with URL rewriting in the receiving mail server. It might also be achievable with a plugin in the mail client or the browser which checks the link against some API or rewrites the link only at the time of access. Such plugins are specific for the mail client or browser though, need to be explicitly installed (might be done automatically on company managed devices) and might not be available for all clients.

URL rewriting (and plugin and web proxies) also allow interaction with the user, i.e. if the decision is not fully clear the user might be warned about potential problems but might be offered to continue if they are sure that the link is trusted. This reduces the impact of false positives.

URL rewriting in the receiving mail server has its clear problems though: anything which relies on the mail being unchanged (i.e. PGP, S/MIME or DKIM signatures) will complain about a changed mail. And URL rewriting is not possible with encrypted mails, while a web proxy still protects in this case too.

The worst option (apart from no checks at all) is to check the link ONLY when the mail arrives at the mail server. At this time there are much less reputation information available about the link, so the chance of missing a problem is much higher. Also the decision at this time is final, i.e. either the mail is blocked (or the link removed) or passed through without changes. So false positives must be reduced as much as possible which leads to an even higher rate of false negatives, i.e. of not detecting attacks. Of course, filtering obviously bad mails at this early stage is a good idea, and this option can also be used together with URL rewriting or access via proxy.

In summary: None of the offered solutions is perfect, each has its own problems. URL rewriting is a good alternative if analysis of all traffic in an TLS intercepting web proxy or if the installation of a security plugin in the mail client is not an option. It has its problems though with any kind of signed mails.

  • 1
    I disagree. Delivery-time checks are great. They can convict messages and prevent annoyances from reaching any inboxes. However, as you note, they are insufficient, especially wrt more sophisticated attacks. That's where click-time checks come in. Because you can't be assured that links will be clicked from within a network with its own inspection, rewrites become important as a final line of defense. (To your final point: DKIM should be vetted before rewrites, but PGP & S/MIME signatures will indeed break. Good thing they're really rare.)
    – Adam Katz
    Sep 2, 2022 at 15:44
  • 4
    Would this not better be achieved with Safe Browsing or similar technologies that are already available? Scanning links locally browser-side has the same benefits and fewer drawbacks, in my view. Sep 2, 2022 at 16:34
  • 3
    @FedericoPoloni: That's basically the browser plugin approach (Safe Browsing is special here in that it gets shipped with the browser). As for Safe Browsing - it is fine but it is out of control of the companies and there are no ways to add company specific thread intelligence. Sep 2, 2022 at 17:15
  • 1
    @AdamKatz: you are right that delivery-time checks are valuable because they allow an early blocking of unwanted mails. I made it more clear that this is the worst option if it is the ONLY option, but that it adds value when used in addition to the others. Sep 2, 2022 at 17:19
  • 2
    You have only discussed a class of options at the network or mail handler level, but not all options. For example, you didn't discuss the option of leaving the email alone and letting the user decide, or of having the user install a browser plugin.
    – usul
    Sep 3, 2022 at 13:28

This is a profoundly annoying practice. Especially if the rewriting rules are misconfigured to rewrite URLs sent to parties that have no means to reach the redirecting server.

Good luck configuring it correctly in a complex corporate setup.

In relation to security, if a security feature is preventing people from doing their work, they either find workarounds (with much worse security implications) or just stop doing at least some of their work.

Other answers mentioned a great deal of other problems of this security approach, so one can conclude that this "solution" goes somewhere in the range between:

  • "Security theater"-type solution
  • "Not our fault"-type solution, where people responsible for security are forcing others to use less secure, unofficial practices (e.g. external mail providers) in order to blame these unofficial practices for breaches when the breaches occur.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .