Why Email Links Get Rewritten: How to Read a Safe Link

A message arrives with a link to a shared document. You hover over it out of habit, and the status bar shows https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2F followed by three hundred characters of noise. The one thing every security awareness course tells you to do, look at where the link goes before you click it, has just been taken away from you by the security product.

That is not a malfunction. Rewriting is how time-of-click protection works. It does leave you holding a string you cannot read at the precise moment you were trying to make a judgement about it. What follows is what the major wrappers do, which of them carry the real address inside the string, which do not, and how to get the destination back without handing the link to a stranger.

What a rewritten link is#

An email security gateway sits in front of the mailbox. As a message passes through, the gateway parses the HTML body and replaces the href of every link with one pointing at its own service, leaving the visible anchor text alone. The words still read "View invoice"; the target now reads urldefense.com/v3/__https://….

The point is that the link gets scanned twice. Once when the message arrives, which is the easy case, and again when somebody actually clicks, which is the case that matters. A campaign that sends a clean URL on Monday and repoints the same domain at a credential-harvesting page on Wednesday defeats delivery-time scanning completely. It does not defeat a check performed at the moment of the click, because the click is when the gateway looks again.

That is the whole trade. You give up the ability to read the destination, and the gateway gets a chance to say no after delivery.

Microsoft Safe Links#

Safe Links is the URL-rewriting half of Microsoft Defender for Office 365. Rewritten links carry the prefix https://<DataCenterLocation>.safelinks.protection.outlook.com, so the nam01 at the front of one link and a different label at the front of another are the same service reached through a different region.

The original URL is not hidden. It sits in the url query parameter, percent-encoded. The rest of the query string is Microsoft's own bookkeeping (identifiers that tie the link to the tenant and the message), and none of it is needed to read the destination.

A few behaviours are worth knowing before you draw conclusions from a wrapped link:

• Wrapping is done per recipient. Two people on the same message hold different wrapped links.
• The rewrite survives a manual forward or reply, and links newly added to that reply get wrapped as well. Automatic forwarding by an inbox rule usually does not carry the rewrite through, unless the final recipient is also protected or the URL had already been rewritten in an earlier message.
• Only http, https and ftp links are handled. Safe Links ignores S/MIME-signed messages, does not protect URLs in RTF (TNEF) messages, and does not run on mail-enabled public folders.
• Links to SharePoint and OneDrive are no longer wrapped, though they are still processed by the service.
• In Teams and in the Office apps, Safe Links checks URLs at click time and does not rewrite them at all. Only mail gets the visible mangling.

Microsoft's documentation is candid about one failure mode in particular. An administrator can turn rewriting off and rely on a client-side API call at click time instead. If the recipient then reads that message in a client that does not implement the API, and the link was harmless on delivery, nothing catches it later.

Proofpoint URL Defense, and its three formats#

Proofpoint has changed its encoding twice, and all three generations still turn up in mailboxes and in old ticket histories.

v1 is the plain one: a urldefense.proofpoint.com/v1/… address with the destination percent-encoded in the u parameter, readable with a single decode.

v2 keeps the u parameter and adds a substitution that catches people out. Percent signs became hyphens and forward slashes became underscores, so a run like -3A sitting in the middle of a v2 link is a colon and -2F is a slash. Put % back where the hyphens are and / back where the underscores are, percent-decode the result, and the original address appears.

v3 looks the worst and is the friendliest of the three. The shape is https://urldefense.com/v3/__<url>__;<base64>!!<identifiers>$, and the destination sits between the double underscores in something close to plain text. That is why a v3 link is often readable by eye. Characters the wrapper could not carry literally are replaced with * placeholders, and the base64 chunk after the semicolon holds the characters those placeholders stand in for. The !!…$ tail is tracking and customer identification, not part of the address.

The wrappers that hand you the URL#

Two more are common enough to recognise on sight.

LinkProtect rewrites to https://linkprotect.cudasvc.com/url?a=…. The destination is the a parameter, percent-encoded, and nothing beyond a decode is required.

Google's redirector, https://www.google.com/url?q=…, is not an email security product at all, but it wraps links inside Gmail and in mail that has travelled through Google Groups. The destination is the q parameter.

What Safe Links, the readable Proofpoint versions, LinkProtect and Google have in common is that the original URL is genuinely inside the string you were sent. No lookup, no service, no network request. That is why our email link unwrapper runs entirely in the browser tab: the decoding is string manipulation, so the wrapped link never leaves the machine. It also follows nesting, up to six layers deep, because a message that crossed two gateways arrives with one wrapper wound around the other.

The wrappers that keep it#

Not every product embeds the address. Mimecast's URL Protection rewrites to a link of the form https://protect-eu.mimecast.com/s/<token>, where the token identifies a record on Mimecast's own side. The original URL is not present in the string in any encoding, and no amount of decoding will produce it. Only Mimecast can resolve the token, through the decoder in its administration console or by appending a + to the link and reading the page that comes back.

Cisco Secure Email's Outbreak Filters rewrite through secure-web.cisco.com, sending the click to Cisco's web security proxy. These generally behave the same way, a token the vendor resolves, though some older links do carry a percent-encoded URL after the token. If you cannot see one in the string, it is not there to be recovered.

This distinction matters more than it first appears. A tool that always produces an answer is saying something untrue about the opaque cases, and a confidently wrong destination lands at exactly the moment somebody is deciding whether to trust a link. Naming the wrapper and stating that the URL is not in there is the correct output, not a failure to produce one.

Pasting a wrapped link somewhere costs something#

A wrapped link is not a neutral string. A Safe Link carries the receiving organisation's identifiers and a per-message value. A v3 URL Defense link carries customer identifiers in its tail. Pasting one into an unknown web form uploads the fact that a particular organisation received a particular message, taken from a message the person pasting it already found suspicious enough to investigate.

For a security team that is a small but real leak, and an avoidable one, because none of the decodable formats need a server at all. Anything doing that work server-side is choosing to.

Resist the other shortcut too: opening the wrapped link to see where it goes. That is a click. The gateway performs its check, and if the link is clean you have now visited the destination, which is the thing you were trying not to do while you were still deciding.

What rewriting does not catch#

Rewriting protects the click, and nothing else about the message, so the gaps are predictable.

A URL inside a PDF or a Word attachment was never part of the HTML body the gateway rewrote. Plain-text parts are frequently left alone. And a wrapper has nothing to say about a message carrying no link whatsoever, which describes the invoice-fraud and gift-card genres entirely.

The deeper limit is that a reachable destination is not an honest one. A brand-new lookalike domain with a valid certificate passes every technical check a link scanner can perform, because nothing about it is technically wrong. Whether the name is a lie is a judgement, which is why the unwrapped host is where the work starts rather than where it ends.

Reading the destination once you have it#

With the wrapper off you have a hostname and a path, and the useful questions are ordinary ones.

Is the host a near-miss of a brand you know? Swapped characters and inserted hyphens are the entire business model of that genre. Our typosquatting checker generates the plausible variants of a domain so you can see whether the one in front of you is among them, and the longer write-up covers the substitutions that survive a careful read.

How old is the registration? A domain created eleven days ago, used in a message about an overdue invoice, is not a coincidence. WHOIS settles that in one lookup.

What certificate does it present? The SSL inspector shows the chain and the issuer. A certificate issued last week to a domain claiming to be a decade-old bank is a mismatch worth noticing.

If the message rather than the link is what is in doubt, the headers carry better evidence: our email header analyzer parses the Received chain and the authentication results, and how to read email headers walks through what those fields actually prove. The rest of the set sits under email security.