URL rewriting is an email security technique designed for a problem that one-time inbox scanning cannot solve: a link may look harmless at delivery and become dangerous later. An email gateway (SEG) can preserve another opportunity to assess that link before someone clicks it.
In 2025, the FBI Internet Crime Complaint Center received 191,561 phishing and spoofing complaints, and many of these attacks turn on a link the recipient opens well after delivery already cleared the gateway. The control adds value between delivery and the click, but its protection ends outside that path.
Key Takeaways
URL rewriting moves the security decision from delivery time to click time and creates a key opportunity to catch a link weaponized after delivery.
A rewritten link guarantees only that a check will run, and attackers can abuse legitimately wrapped links to borrow that trust.
Changing a message body can invalidate DomainKeys Identified Mail (DKIM) signatures and contribute to Domain-based Message Authentication, Reporting, and Conformance (DMARC) failures unless the gateway re-signs mail or validates authentication before rewriting anything.
Because URL rewriting acts only on hyperlinks in email, it does nothing against Quick Response (QR) codes, chat messages, or payload-free business email compromise (BEC).
How Does URL Rewriting Work in Email Security?
URL rewriting works in two phases: the gateway substitutes proxy links in transit, and the proxy evaluates the real destination at each click. Each phase closes a different part of the gap the opening stat points to: delivery-time scanning catches what a link looked like at arrival, and click-time evaluation catches what it has become since.
Delivery-Time Scanning Substitutes Links Before They Reach the Inbox
When an inbound message arrives, the SEG parses the body, finds every hyperlink, and replaces each one with a URL on the vendor's scanning domain. This substitution routes a later click through the security service before the browser reaches the destination. Gateways can rewrite inbound mail, outbound mail relayed through the gateway, or both, and retain the original destination inside the new URL rather than discard it.
Many gateways run a first scan at this stage, and some hold the message until that analysis finishes. The delivery-time check can identify links already associated with phishing pages, malware, or suspicious redirects, but its verdict reflects only what the destination looks like while the message moves through the mail system. Rewriting therefore preserves another evaluation opportunity.
The rewrite is mostly unobtrusive in Hypertext Markup Language (HTML) mail because the visible link text stays the same. Hovering commonly reveals the wrapper URL rather than the original address, though some products or clients may display or decode the destination. Copying the link or reading the message in plain text also exposes the wrapper. Vendors may call the mechanism link rewriting, link wrapping, or click-time protection.
Click-Time Interception Routes Clicks Through a Live Proxy
Clicking a rewritten link sends the request to the vendor's proxy rather than directly to the destination. The proxy compares the URL against blocklists and known-malicious site lists, and it can apply real-time file scanning when the URL points to a download. More advanced implementations add detonation by opening the URL in an isolated sandbox environment before deciding whether to allow the request.
This checkpoint can use information that was unavailable when the message arrived. A URL may have acquired a malicious reputation, begun redirecting visitors, or started delivering a harmful file since the initial scan. The proxy can incorporate that newer intelligence instead of relying on the earlier result.
A passing check redirects the browser to the original destination, while a failed check blocks the request. The wrapper indicates that an evaluation will occur and provides no guarantee that the page is safe. DNS filtering, browser protections, endpoint defenses, and post-delivery remediation may still intervene. The proxy's outcome depends on current threat intelligence and whether the destination shows the scanner the same content it presents to a human visitor.
Delayed Weaponization Makes Click-Time Coverage Necessary
Click-time evaluation exists because of delayed weaponization. An attacker builds targeted phishing campaigns whose links resolve to a harmless page and waits for delivery to clear the gateway. The attacker then swaps a Domain Name System (DNS) record or edits a redirect and may instead activate the page on a timer. Cloaking reverses the trick by serving benign content to scanner Internet Protocol (IP) ranges and phishing content to human visitors, so static delivery-time scanning sees a clean page either way.
The Verizon 2024 Data Breach Investigations Report found that the median time for users to fall for a phishing email is less than 60 seconds. Blocklists can also lag behind newly malicious pages, so a check at the moment of the click most directly reflects what the destination has become.
Click-time checks can cover several cases that delivery-time scanning may miss:
Links Weaponized After Delivery: Destinations can change through DNS updates and redirect edits, while timers can delay activation.
Credential-Harvesting Pages: Sign-in imitations can be checked against current malicious-site lists.
Malicious File Downloads: Download URLs can trigger real-time file scanning.
Internal and Lateral Phishing: Links from compromised internal accounts still pass through the checkpoint.
Click Visibility forPhishing Incident Response: Decisions can log who clicked a link and when.
Together, these cases explain why click-time evaluation catches what delivery-time scanning cannot. This distinction is worth keeping straight, since the same phrase also describes an entirely different technique on the web-server side.
URL Rewriting in Email vs. URL Rewriting on Web Servers
The same term describes two unrelated techniques, email link protection and web-server URL rewriting, and only the email version is a phishing control. Email URL rewriting happens in transit at the mail gateway and modifies the delivered link so the recipient's security service can inspect the destination at click time. The recipient's organization controls this process, and the wrapper may become visible when someone hovers over or copies the link or views the message in plain text.
Web-server URL rewriting happens when a website receives a request. The site owner uses it to map a public path to an internal resource and create cleaner addresses. It can also restructure a site without breaking old links. The visitor generally sees no change because the server handles the mapping internally. By contrast, an HTTP redirect tells the browser to move to a different address, which then becomes visible to the user.
Related email terms have distinct meanings:
Time-of-Click Protection: This is the verification phase that rewriting makes possible. Rewriting substitutes the link; time-of-click protection runs when the wrapped link opens.
Delivery-Time URL Scanning: This analyzes links as the message arrives, with or without rewriting, but cannot see later changes.
Link Sandboxing: This renders or executes linked content in an isolated sandbox environment to observe its behavior.
Keeping these terms distinct matters because enterprise security teams often treat them as interchangeable when evaluating vendors or writing policy, which obscures real coverage gaps. Naming each mechanism precisely makes it easier to see where one control ends, another begins, and where attackers still have room to operate.
How Can Attackers Bypass URL Rewriting?
Attackers bypass URL rewriting by moving the destination out of the hyperlink, hiding behind a link the control has already wrapped, or cloaking what the scanner sees.
Out-of-Band and Borrowed-Trust Tactics Bypass the Rewrite
Some bypasses prevent the email control from seeing a normal hyperlink at all, while others exploit the familiarity of trusted services. These tactics can move the click outside the normal email path through an attachment or another channel, while a legitimate page can conceal the attack through its appearance.
The bypasses that fit this pattern take several forms, each sidestepping the rewrite in a different way:
QR Code Phishing Attacks: An image-encoded URL gives the gateway no hyperlink to rewrite, and a phone scan happens off the protected workstation.
Abuse of Legitimately Wrapped Links: An attacker can send a phishing URL through a compromised account, let the gateway wrap it, and forward the vendor-branded link. Chaining services buries the destination further.
Links Inside Attachments: URLs in Portable Document Format (PDF), HTML, Scalable Vector Graphics (SVG), or productivity files are not reliably parsed or rewritten. SVG files can also carry JavaScript.
Collaboration Platform Delivery: Chat messages sit outside the mail flow, so links may receive a reputation check without being rewritten.
Search Engine Ad Abuse: Sponsored results can impersonate a brand and lead to phishing through an ad network's domain without an email link.
Device Code Phishing on Legitimate Pages: A victim visits a real identity-provider page and enters a code. The proxy allows the legitimate URL, while the attacker captures OAuth tokens for mailbox access, which results in a multifactor authentication (MFA) bypass.
Recognizing these patterns is where security awareness training earns its value, since users become the checkpoint the gateway never gets to be. Training that covers QR codes, attachment-borne links, and unfamiliar identity prompts equips recipients to pause on the exact cues a rewrite cannot catch.
Redirect Chains and Cloaking Bypass the Rewrite
Other bypasses keep the link inside email but manipulate what the proxy can observe. They rely on intermediate destinations and trusted forwarding behavior. Visitor checks can also separate automated scanners from human recipients.
These manipulations show up in a handful of recurring patterns, each keeping the click inside email while narrowing what the proxy can verify:
Multi-Hop Redirect Chains: A clean first hop can satisfy the proxy before later hops carry the user to a phishing site.
Open Redirects on Trusted Domains: A reputable site that forwards visitors to a parameter-supplied URL lends the attacker a trusted host. In an Open Authorization (OAuth) flow, an allow-listed redirect can also leak authorization tokens.
CAPTCHA Challenge Gates: A challenge page can stop automated crawlers before they reach the login form shown to a human.
Geofencing and Device Fingerprinting: Phishing kits can check IP location, user agent, and browser attributes, then serve blank pages to security crawlers.
These tactics exploit the difference between evaluating a URL and observing the full experience that follows it. The proxy can re-evaluate the first hop using current intelligence, but later redirects or selective content may still conceal the final destination.
How Does URL Rewriting Affect Email Authentication?
Rewriting changes the signed body of a message, which can break email authentication and drag DMARC down unless the gateway is configured deliberately.
Body Changes Break the Original DKIM Signature
DKIM has the sending domain sign selected headers plus a hash of the message body. The receiving server recomputes that hash and compares it with the signature; any difference fails validation. Because URL rewriting edits the body, the hash no longer matches and the original DKIM signature validation fails. Relaxed canonicalization tolerates whitespace differences, but no canonicalization preserves a signature after a link changes.
Secure/Multipurpose Internet Mail Extensions (S/MIME) and Pretty Good Privacy (PGP) signed messages face the same problem. Gateways therefore commonly exclude them from rewriting and leave signature checks to the endpoint. This preserves the signed content but means those messages do not receive the same click-time treatment.
Sender Policy Framework (SPF) adds a second failure path by checking whether the delivering server appears in the sending domain's published record. When a SEG rewrites outbound mail and relays it from its own IP addresses, the record must include those addresses or SPF fails. DMARC needs only one method to pass and align with the visible From domain, but if rewriting breaks DKIM and relaying breaks SPF, nothing aligns. A receiver enforcing a DMARC enforcement policy may quarantine or reject the message.
Re-Signing and Validation Preserve Authentication Across the Rewrite
Three mechanisms keep authentication intact across a rewrite, each suited to a different part of the mail flow:
Mechanism | Where It Applies | How It Preserves Authentication |
|---|---|---|
Post-Rewrite DKIM Signing | Outbound gateways | Signs the modified body with a key published under the sending domain, so the arriving signature validates and aligns; also requires adding the gateway's relay addresses to the SPF record |
Pre-Rewrite DKIM Validation | Inbound gateways | Checks the original signature at the mail transfer agent while the body is still intact, then sends the modified copy to the mailbox, preserving the original authentication result |
Authenticated Received Chain (ARC) | Any intermediary that modifies mail | Records each hop's authentication results and signs them onward, so a trusting receiver can weigh that history instead of relying only on a failing DKIM signature |
These approaches support different flows. Re-signing supports outbound messages and pre-rewrite validation supports inbound processing, while ARC carries authentication history across intermediaries rather than restoring a signature itself. A gateway handling both inbound and outbound traffic may need more than one method.
Limitations and Tradeoffs of Click-Time Protection
URL rewriting trades link transparency, some deliverability, and user privacy for a click-time verdict. These tradeoffs surface in a few recurring situations, each showing where the click-time verdict comes at a cost:
Hidden Destinations Undercut Awareness Training: Training teaches recipients to inspect a domain before clicking, but hovering, copying, or viewing a plain-text message may expose only the wrapper.
Single-Use Links Can Be Consumed: Pre-delivery scanning may follow a password reset or one-time login URL and spend the token before the recipient clicks.
Forwarded Messages Keep the Wrapper: Mail forwarded outside the organization still routes external recipients through the sender organization's proxy and may fail for them.
Click Logs Create Privacy Obligations: The proxy holds a timed history of URLs opened from email, which creates retention and jurisdiction contract questions.
Payload-Free Attacks Pass Untouched:Payload-free BEC attacks use impersonation and social engineering language rather than a link, so rewriting never engages.
These tradeoffs don't make URL rewriting a weak control, but they do explain several persistent misconceptions about what it actually guarantees.
Common Misconceptions About the Rewrite
Four common beliefs about URL rewriting overstate what the control can do:
A Rewritten Link Has Been Verified as Safe: The wrapper indicates only that the click will be routed through a check that can be wrong.
It Stops AllLink-Based Phishing Attacks: QR codes, attachment links, and sponsored search results may never present an email hyperlink to wrap.
It Covers Every Channel: Chat tools and document collaboration sit outside the mail flow, where no rewrite happens.
Email Sandbox Detonation Always Catches the Page: Geofenced and CAPTCHA-gated kits can show an automated visitor nothing.
Would a security team assume its email program is fully covered simply because every link now redirects through a scanning domain? Each of these misconceptions says otherwise, and each maps to a real gap that only a layered defense can close.
Where Does URL Rewriting Fit in a Layered Defense?
Federal baselines treat URL rewriting as one mandatory control among several, a framing that suits any organization.
Federal Baselines Pair the Rewrite with Complementary Controls
The Cybersecurity and Infrastructure Security Agency (CISA) requires Safe Links-style click-time protections in its Microsoft 365 Secure Configuration Baseline for federal agencies, and a CISA cloud security directive made the relevant cloud security baselines compulsory for federal civilian agencies, with a compliance deadline of June 20, 2025. The guidance treats attachment sandboxing, impersonation-focused anti-phishing policies, and zero-hour purge of delivered messages as separate requirements rather than alternatives.
Controls that cover the remaining gaps include:
Phishing-Resistant MFA Methods: Fast Identity Online (FIDO) or Public Key Infrastructure (PKI) authenticators make captured credentials useless at an impostor site.
Attachment Sandboxing: Detonating files covers malware delivered as attachments, which link-focused controls never inspect.
DNS Filtering: Blocking malicious domains at resolution time works whether a link arrived by email, QR code, chat, or bookmark.
Awareness Training: Training extends the human decision layer across Short Message Service (SMS), voice, and social media, while user reports can feed threat intelligence.
These controls address channels and attack methods that email link rewriting cannot reach. They also limit the damage when a proxy allows a destination that changes behavior or hides its content from automated analysis.
Configuration Choices Decide Whether Rewriting Strengthens Protection
Configuration choices determine whether URL rewriting strengthens protection without disrupting authentication, single-use links, or incident response. Organizations can consider where validation occurs and which messages receive rewriting. They can also decide how click data supports later investigation. These decisions work best as a connected policy rather than isolated gateway settings.
These choices fall into a few categories that together define how the rewrite fits alongside authentication, exception handling, and response:
Inbound DKIM Validation: The gateway can check the original signature at the mail transfer agent while the body remains intact. Validation before rewriting preserves the authentication result.
Post-Rewrite DKIM Signing: For outbound mail, the gateway can sign the modified body. Its relay addresses also belong in the SPF record so both authentication paths reflect the infrastructure delivering the message.
Policy Scope and Allow Lists: Organizations can exclude trusted domains and senders of one-time-use links when scanning would consume a token. Scope can also distinguish inbound and outbound mail, signed messages, and destinations requiring special handling.
Click-Log Monitoring and Alerting: Click events can show responders who reached a page later confirmed as malicious. Retention, access, and privacy rules can define how long that history remains available and who may use it.
These choices align link protection with the rest of the mail system. The goal is to ensure authentication, delivery, exception handling, and response workflows continue to support one another after the message body changes.
Making Every Click a Checkpoint
URL rewriting turns a one-time delivery decision into a live check at the click. Its blind spots are specific: images, attachments, chat channels, borrowed trust, and messages with no link. Mapping those gaps to other controls, while configuring signing and validation so authentication survives the rewrite, creates a more realistic foundation for evaluating link protection.
Frequently Asked Questions
Why Do Links in My Email Start with an Unfamiliar Domain?
Your organization's email security service has routed the link through its own domain for inspection. The original destination remains encoded inside the longer address.
Can Attackers Use Rewritten Links from Legitimate Security Tools to Make Phishing Look Trustworthy?
Yes. Attackers can reuse links wrapped by legitimate services so the security domain looks familiar. The final destination still requires evaluation when the recipient clicks.
Can URL Rewriting Break Password Reset Links?
Yes. An automated scan may consume the token by opening a single-use link before the intended recipient does, so the reset link fails.