What is real-time URL rewriting?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

You click a link in an email and something feels slightly slower than usual. You probably didn't notice it, but in that fraction of a second, a security system scanned the destination URL and decided it was safe. That's real-time URL rewriting in action.

Here's how it works. When a security gateway (like Barracuda or Microsoft 365 Defender) processes your incoming email, it replaces every link in the message with a proxy URL. The original destination gets encoded into that proxy address. When you click, your browser hits the proxy first. The proxy checks the destination's reputation, scans the content, and then either redirects you through or blocks you with a warning page.

The key insight here is when that check happens. Standard spam filters analyze links at the moment the email is delivered. But attackers know this. They can send an email with a clean, innocent link and then swap out the destination hours later, after the email has already passed every filter. That's sometimes called a delayed threat. URL rewriting catches it because the check happens at click-time, not delivery-time. Even if the destination changed after you received the email, the proxy catches it before you land there.

To answer a question many people have: yes, every link goes through the proxy, even if the destination is completely legitimate. The proxy doesn't know ahead of time which links are safe, so it checks them all. For clean URLs this is near-instant and you won't notice it in everyday use. For URLs that need deeper analysis, there can be a brief pause. It's a trade-off most security teams consider well worth it.

One thing worth knowing if you're a sender: URL rewriting affects your domain reputation scoring data. Clicks routed through security proxies can sometimes show up as coming from the proxy's IP address rather than the recipient's actual location. This can affect how your click analytics look, especially in enterprise environments where most recipients have this protection turned on.

URL rewriting is part of a broader set of defenses that email security gateways layer together. It works alongside tools like sandbox detonation and header anomaly detection to cover different parts of the threat timeline.

If you're diagnosing unexpected click data or seeing strange redirect patterns in your email analytics, our free email header analyzer can help you see what's happening at the infrastructure level. Or if things feel broken right now, the SOS hotline is free.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Get a ranked breakdown of URL rewriting trade-offs for my setup

I'm evaluating email security tools and keep seeing URL rewriting mentioned. I work in IT for an enterprise and need to understand the practical trade-offs. Please give me three ranked considerations based on my situation: 1. Performance impact: Does URL rewriting meaningfully slow down clicks for end users? What's a realistic latency range? 2. Legitimate URLs: If a link is completely safe, does it still route through the proxy on every click? What does that mean for our email analytics data? 3. Post-send threats: If an attacker changes a destination URL after our team has already received the email, can the system catch that at click-time? Please rank these from most to least operationally significant for a typical enterprise deployment.

Edit the yellow boxes, then send to the AI of your choice.