URL rewriting is a security technique that intercepts links embedded in emails, replaces them with modified versions pointing to a security proxy, and evaluates each link for threats when a user clicks. Organizations use it to add a verification layer between users and potentially malicious web destinations.

Because phishing remains the single most reported cybercrime category, with 193,407 complaints logged by the FBI IC3 in 2024, URL rewriting has become a standard control in email security architectures.

• URL rewriting works by redirecting email link clicks through a security proxy that checks URLs before granting access to the destination.

• The technique can conflict with email authentication because modifying message body content may invalidate cryptographic signatures and contribute to DMARC failures.

• This approach does not protect against business email compromise (BEC) or attacks delivered through QR codes, so it is only one layer in an email security strategy.

• Organizations usually get the most value from URL rewriting when they combine it with sandboxing, authentication protocols, and other layered email defenses.

URL rewriting works by replacing links in email with proxy links that are checked again when a user clicks. When an inbound email arrives, the email gateway (SEG) scans the message body, identifies every embedded URL, and replaces each one with a rewritten version that encodes the original destination within a new link pointing to the security vendor's proxy infrastructure.

According to the CISA M365 Secure Configuration Baseline, the proxy performs several checks when a user clicks a rewritten link. It compares the URL against known-malicious blocklists, applies real-time file scanning if the URL points to a downloadable file, and then either blocks the request or redirects the user to the original destination.

URL rewriting in email security can take different forms depending on where the check happens and how much analysis the system applies. The mechanism described above takes several forms depending on where and how it operates in the email security pipeline. Each serves a different purpose.

The most common form of URL rewriting happens at the SEG level before a message reaches the inbox. The gateway extracts every URL from the message body and replaces each link with a proxy URL hosted on the security vendor's domain. The original URL is embedded as a parameter in the proxy URL, which the proxy decodes and evaluates at click time.

CISA mandates this approach for federal agencies, requiring that URL rewriting and malicious link click checking be enabled for all users and all agency domains. This is the default recommended configuration across all federal Microsoft 365 deployments.

One documented limitation: URLs in collaboration channels like collaboration apps and office applications are checked but not rewritten. This creates a coverage gap within the same platform where links in email receive full proxy interception while links in adjacent channels receive only reputation-based checks without the proxy redirect step.

Time-of-click scanning matters because it checks a URL at the moment of user interaction rather than only when the message is delivered. Rather than relying solely on delivery-time analysis, time-of-click scanning defers the full security evaluation to the moment a user interacts with the link. This approach counters delayed weaponization, a technique where attackers host benign content at the time of email delivery and then swap in malicious payloads after the message has landed in the recipient's inbox.

Time-of-click scanning closes this gap by re-evaluating the URL against current threat intelligence and behavioral signals at the exact moment the user clicks. CISA requires that systems wait for URL scanning to complete before delivering the message and that users not be permitted to click through to the original URL. This is why CISA treats time-of-click scanning as a SHALL-level requirement for all federal deployments.

Proxy-based content evaluation adds layered inspection after the click is intercepted. Advanced implementations go beyond simple reputation checks by applying layered content analysis at the proxy level. When a user clicks a rewritten URL, the proxy first checks the destination against reputation databases and blocklists. If the URL is not already flagged, the proxy may inspect downloadable files for malware and evaluate page activity through automated analysis.

Attackers often bypass URL rewriting by moving malicious destinations into formats or paths the control cannot fully inspect. The same trust signals that make URL rewriting effective for defenders can also create blind spots.

Threat actors do not need to defeat the mechanism directly in every case; they can route around it, exploit adjacent weaknesses, or operate in channels it does not inspect.

When a malicious URL is encoded within a QR code image rather than embedded as a hyperlink, URL rewriting has no hyperlink to identify or rewrite. This is a structural bypass: the email security system scans the message body for links, but the URL exists only as pixel data within an image.

An FBI FLASH advisory documented North Korean threat group Kimsuky deploying QR code phishing against NGOs, think tanks, academic institutions, and government entities. Victims who scanned the codes were routed through attacker-controlled redirectors that collected device attributes, including user-agent, operating system, IP address, locale, and screen size.

The redirectors then selectively presented mobile-optimized credential harvesting pages impersonating common email, identity, or VPN portals. Documented end-states included session token theft, MFA bypass, and lateral phishing from the victim's own compromised mailbox.

Open redirects can weaken URL rewriting when a scanned link appears to point to a trusted site but then forwards the user elsewhere. Open redirect vulnerabilities exist when a legitimate website accepts a URL parameter that specifies an arbitrary redirect destination without validating it. Attackers identify large web platforms with this flaw and craft URLs that point to the trusted domain with the redirect parameter set to an attacker-controlled page.

When the URL rewriting proxy evaluates the link, it scans the apparent destination, finds a reputable site with a clean reputation, and allows access. The trusted domain then silently forwards the user to the attacker's actual destination. This technique is especially dangerous when combined with OAuth authentication flows.

OAuth relies on redirect URLs to pass authorization tokens from the authorization server to the client application. An open redirect within the allow-listed URL range can be used to route the authorization token to the attacker's endpoint instead of the legitimate client. The attacker receives a valid token without ever presenting credentials. CISA has documented active exploitation of open redirects as phishing vectors.

URL rewriting helps most when a link changes after delivery, but it fails when there is no link to intercept or when the attack relies on impersonation instead. URL rewriting catches URLs that become malicious after delivery, when static pre-delivery scanning would miss the threat. Attackers can weaponize URLs after the email lands in the inbox, and time-of-click evaluation is the primary defense against this technique. URL rewriting also enables downstream controls like browser isolation that depend on intercepting the click before it reaches the user's device.

However, URL rewriting offers no protection against BEC. These attacks use impersonation and social engineering language as the payload, containing no malicious link for URL rewriting to intercept. It also cannot inspect URLs embedded in images such as QR codes and has uneven coverage across collaboration channels within the same platform.

URL rewriting can break email authentication when changing the message body invalidates signatures created before delivery. URL rewriting creates a documented technical conflict with email authentication protocols that many organizations overlook during deployment.

DKIM authentication works by cryptographically signing the email body and specified headers, as defined in RFC 6376. When a SEG rewrites URLs in the message body, it changes the content that was signed. The body hash no longer matches the original signature, and DKIM validation fails.

DMARC validation requires that at least one of Sender Policy Framework (SPF) or DKIM passes and aligns with the sender's domain, as defined in RFC 7489. If URL rewriting breaks DKIM and the SEG relays the message from an IP address outside the sender's SPF records, both authentication methods fail and DMARC validation fails, potentially causing the message to be quarantined or rejected.

The documented mitigation is for the SEG to generate its own DKIM signature over the modified message after rewriting. Multiple DKIM signatures are acceptable under the standard. However, both mitigations require deliberate configuration, and organizations that deploy URL rewriting without addressing these conflicts risk disrupting legitimate email delivery.

Several assumptions about URL rewriting can create a false sense of coverage if teams do not understand what the control actually does. Several widely held assumptions about URL rewriting do not hold up under scrutiny. Recognizing these gaps is just as important as understanding the technology's intended function.

• A Rewritten URL Has Been Verified and Is Safe to Click: A rewritten link indicates that the click is being routed through a security control, not that the final destination is automatically safe.

• URL Rewriting Protects Against All Link-Based Phishing: QR code phishing campaigns deliver URLs as images, bypassing email-layer URL rewriting tools entirely. This bypass is structural, not incidental.

• URL Rewriting Provides Coverage Across All Communication Channels: CISA documents that within Microsoft 365, Safe Links rewrites URLs in email but does not rewrite URLs in collaboration channels or office applications.

• Sandbox Detonation of a Rewritten Link Will Always Detect the Malicious Page: Sandboxing and proxy analysis improve detection, but they do not eliminate every post-delivery or out-of-band phishing path.

The main implementation challenge with URL rewriting is fitting it into a broader email security stack without breaking other controls.

• Authentication Framework Alignment: The SEG performing URL rewriting should be configured to re-sign messages with a valid DKIM signature and should be included in the sending domain's SPF records if it relays mail.

• Layered Security Architecture: URL rewriting, URL scanning, and sandboxing are most useful when organizations treat them as part of a broader stack alongside SPF, DMARC, DKIM, and phishing-resistant multi-factor authentication.

URL rewriting adds a useful verification step between a user's click and a web destination, but its role is limited. Teams that understand its strengths and blind spots are better positioned to build layered defenses that account for what URL rewriting handles well and where it falls short.