What Is URL Rewriting in Email? Safe Links Explained

URL rewriting in email is the practice of replacing every hyperlink in a message with a URL that points to a security gateway. When you click a rewritten link, the gateway intercepts the request, checks whether the destination is still safe, and either forwards you through or blocks the page. The whole process takes under a second. From the outside it is invisible — until you hover over the link and see a long, unfamiliar address where a clean URL used to be.

The technique exists because of a timing gap in traditional email security. A scanner that inspects a message at delivery can only check whether a link is malicious at that exact moment. An attacker who knows this can register a domain that looks clean on the day the message is sent, wait for it to be delivered, and then activate the malicious payload hours or days later — after the delivery-time scanner has already passed the message through. URL rewriting solves that gap by deferring the check from delivery to click. By the time you click, the gateway knows whether the page has changed since arrival.

This guide explains what URL rewriting is, how the mechanism works step by step, what it costs in usability and privacy, and how it compares to the adjacent security controls it is often confused with. It also covers the common misconceptions — including the one that treats a rewritten link as evidence the original message was suspicious — and explains where link protection at the client layer fits when a gateway is not in the picture.

How does URL rewriting actually work?#

The process runs on the mail gateway, not in the email client. When a message passes through the gateway on its way to the recipient, the system scans every href in the HTML body and every plain-text URL it can detect. Each of those URLs is then replaced with a new URL that routes through the gateway's own infrastructure. The original destination is encoded inside the new URL, usually as a query parameter or a path segment.

When you click the link in your email client, your browser follows the rewritten URL to the gateway. The gateway decodes the original destination, runs a real-time check against its threat intelligence — category databases, reputation scores, sandboxing, allow and block lists — and then makes a routing decision. If the destination is safe, it redirects your browser there. If it has turned malicious, it blocks the request and shows a warning page instead.

That real-time check is what the industry calls time-of-click protection. It is the key distinction from a delivery-time scanner: the gateway has access to threat data that was not available when the message first arrived, so it can catch a link whose status changed after delivery. Most enterprise implementations also log every click with the user identity, the original URL, the redirect decision, and the timestamp — which is both the audit benefit and the privacy concern.

1. 1

   Message arrives at the gateway

   The inbound mail gateway receives the message before it reaches the recipient's mailbox. The URL rewriting system parses every link in the HTML body and any plaintext URLs it detects.

2. 2

   Every link is replaced

   Each original URL is encoded and embedded into a new gateway URL. The rewritten link is swapped into the message body in place of the original. The recipient's mail client only ever sees the gateway version.

3. 3

   Recipient clicks

   The browser follows the rewritten URL to the gateway endpoint. The gateway decodes the original destination and runs a real-time safety check using current threat data.

4. 4

   Gateway routes or blocks

   If the destination passes the check, the gateway redirects the browser there. If the destination has been flagged as malicious since delivery, the gateway blocks the request and shows a warning page. The click is logged either way.

What breaks when URL rewriting is applied?#

The costs are real and worth stating plainly. The most visible is the URL itself. A link that used to read as a recognisable domain now shows a long gateway address — often dozens of characters, ending in an encoded blob of the original URL. When a reader hovers over a link before clicking, the destination shown in the status bar is the gateway, not the site they are about to visit. That reverses a basic piece of link-safety advice: checking where a link actually goes before you click becomes meaningless once the links are all rewritten.

A second common breakage is email tracking. Marketing teams and sales tools embed tracking links that redirect through their own infrastructure. When URL rewriting wraps those links inside a gateway URL, the click-tracking redirect may fail, or may count clicks attributed to the gateway rather than to the original recipient. Open rates and click rates from systems relying on redirect-based tracking become unreliable.

Forwarded email is a third failure mode. URL rewriting policies are typically tied to the recipient in the original message. When that recipient forwards the message to someone outside the organisation, the rewritten links still route through the first organisation's gateway, which checks the second person's click against a policy that was never meant to cover them. Depending on configuration, those clicks may be blocked, rate-limited, or simply logged as anomalous.

Finally, if the gateway itself goes down, all rewritten links in all previously delivered messages go with it. A healthy archive of old mail becomes a collection of dead links until the gateway is restored.

URL rewriting vs adjacent email security mechanisms#

URL rewriting is one layer in a defence stack, not a replacement for the other controls. Understanding which mechanism does what job clarifies when a failure means URL rewriting has gaps and when it means something else in the stack failed.

Common misconceptions about URL rewriting#

The first and most widespread misconception is that a rewritten link means the original message was suspicious. It does not. URL rewriting is applied to every inbound message processed by the gateway, regardless of whether any threat was detected at delivery. The rewriting is the mechanism that enables the time-of-click check; it is not a flag or a quarantine action. A message with rewritten links is a message that passed through a URL rewriting gateway — nothing more.

The second misconception is that URL rewriting makes a link safe. It reduces risk by adding a click-time check, but it does not guarantee the destination is clean. A sophisticated attacker can serve benign content to the gateway's inspection IP while serving malicious content to every other visitor. The reputation check passes, the link is not blocked, and the user reaches a malicious page. Threat intelligence databases also have coverage gaps, particularly for newly registered domains. URL rewriting is a control, not a guarantee.

The third is that URL rewriting is a privacy-preserving feature. It is not, in the ordinary sense. The gateway logs who clicked which link, when, from which IP, on which device. In a corporate environment that is an intended audit feature. For a recipient who expected a private reading experience, it is worth knowing that every click through a rewritten link is recorded and attributed. The original URLs are also decoded and visible inside the gateway's logging infrastructure, which means any encrypted content in a URL query string is exposed at that layer.

Finally, a common technical misconception: that the original URL is permanently hidden once the link is rewritten. The original destination is encoded inside the rewritten URL itself, usually in plaintext or base64. You can decode it manually, or paste the rewritten link into a URL decoder, to see where it points before clicking. The gateway does not hide the destination — it intercepts the path to it.

Where does AI Emaily fit with link security?#

URL rewriting solves for a specific timing problem: a link that scanned safe at delivery can turn malicious before you click. AI Emaily addresses the same risk at the client layer — tracking pixels are blocked before they load, rendered content is sanitized so no untrusted HTML reaches your browser, and links are sandboxed — rather than by wrapping every URL through a gateway. That is a different architecture from Safe Links, and one worth understanding: we do not rewrite or proxy your links through an intermediate server, which means the destination shown in your status bar is still the real one. The client-side controls do address the downstream effect: malicious content does not load silently, and the phishing and spam protection layer flags suspicious messages before you ever reach the link. We build AI Emaily, and those protections are included on every plan, starting with a 7-day free trial. See aiemaily.com/pricing for details.

Frequently asked questions#