Stop Rewriting URLs in Emails. There’s a Better Way.

The security feature your CISO loves might be the one your General Counsel hates.

If you’ve ever hovered over a link in a corporate email and seen something like:

https://link-protection.example.com/v2/url?u=https-3A__example.com_reset...

you’ve encountered URL rewriting — the most common click-time defense against phishing. It works. It also breaks things.

What URL rewriting actually costs you

Rewriting looks like a clean security win — until you examine the tradeoffs:

● Users can’t read links anymore. A long vendor URL becomes unreadable. “Hover before you click” loses its value.

● Privacy leaks to intermediaries. Every click is routed through a third party that now sees who clicked what and when.

● One-time tokens get burned. Password resets, magic links, and signed URLs may be triggered by automated scanners before the user ever clicks them.

● Latency on every click. Click-time scanning adds delay to navigation.

● Internationalized URLs break. Unicode and percent-encoded URLs are often mangled during rewriting.

● Long-term link rot. When vendors change domains or formats, old links in archived emails stop working.

● DKIM integrity issues. Rewriting modifies the message body, interfering with cryptographic guarantees. And even with all of that, attackers can still bypass detection using redirect chains or delayed activation.

The core idea: policy metadata, not URL surgery

Instead of modifying every URL, what if we left the content untouched and attached policy metadata to the message? That’s the approach proposed in the IETF draft draft-vinnakota-mime-url-policy-01:

URL-Policy: https://policy.example.com/url-check

URL-Policy-Token: 4f9e7c12–8d11–47b1-a9c5–2d43c1f66e20

Nothing in the message body changes. URLs remain exactly as the sender wrote them — including Unicode, query parameters, and fragments. The headers simply indicate that a policy endpoint is available, and that the message is associated with an opaque token.

What happens at click time

When a user activates a link in a supporting client:

1 The client detects the URL-Policy header.

2 The original URL stays intact.

3 The client sends the URL and token to the policy endpoint.

4 The endpoint returns a decision — allow, block, or warn.

5 Navigation proceeds based on that decision.

Example request:

POST /url-check HTTP/1.1
Host: policy.example.com
Content-Type: application/json
{
"token": "abc123",
"url": "https://example.com/reset?token=XYZ"
}

The exact API is intentionally flexible — the standard defines the signal, not vendor-specific implementation.

Why this is materially better

● DKIM survives. No body modification means signatures remain valid.

● One-time links work again. No pre-click scanning that consumes tokens.

● Privacy improves. Click telemetry stays within the recipient’s domain.

● Internationalization just works. No rewriting means no encoding issues.

● Archives stay valid. Links still work years later.

● Backward compatibility is automatic. Clients that don’t support the headers simply ignore them.

The part most people miss: legal and compliance impact

Beyond usability and security, URL rewriting introduces legal and regulatory complications. Emails are not just communication — they are records.

eDiscovery

Courts increasingly expect email production with intact metadata and a verifiable chain of custody. Recent rulings have actively grappled with how hyperlinked content should be treated in production:

● Nichols v. Noom, Inc., 2021 WL 948646 (S.D.N.Y. Mar. 11, 2021)

● In re Meta Pixel Healthcare Litig., №22-cv-03580-WHO (N.D. Cal. June 2, 2023)

● In re Uber Technologies, Inc., Passenger Sexual Assault Litig., 2024 WL 1772832 (N.D. Cal.Apr. 23, 2024)

These cases highlight that hyperlinks are not always equivalent to attachments, and their treatment affects how email records are interpreted in litigation. URL rewriting makes this worse on two axes: the archived email no longer matches what the sender actually sent, and the rewritten links may not even resolve years later when the matter goes to trial. For a plain-English overview comparing all three rulings, see Complete Discovery Source’s analysis.

Regulated record keeping

Regulations such as SEC Rule 17a-4, FINRA Rule 4511, HIPAA, and MiFID II all require preservation of authentic records. When a security gateway rewrites URLs in business communications mid-flight, the “original” record technically stops being original — which is why some compliance-grade archives have to retain both the pre- and post-modification versions just to stay defensible.

Authentication as evidence

DKIM signatures are increasingly used to establish email authenticity in legal proceedings. Body modification breaks them; header-based policy preserves them. In regulated environments, this is not just a usability issue — it impacts compliance and auditability.

What this proposal does not try to do

● It does not replace gateway-level scanning.

● It does not require browser changes.

● It does not dictate detection logic.

● It does not replace existing MIME mechanisms such as message/external-body (RFC 2046).

It simply separates content integrity from security enforcement.

The trust model, briefly

● The recipient domain controls the headers. Sender-provided values are untrusted until validated by the recipient.

● Header presence alone does not imply trust in the policy endpoint — trusted endpoints are determined by local administrative policy.

● Tokens are opaque and non-identifying, validated through implementation-specific methods (shared storage, pre-registration, or cryptographic validation).

Why this matters

The bet underlying all of this is simple: content integrity and security enforcement should not be in conflict. URL rewriting forces them to be. Header-based policy doesn’t.

Learn more

IETF draft (HTML): datatracker.ietf.org/doc/draft-vinnakota-mime-url-policy/

IETF draft (text): ietf.org/archive/id/draft-vinnakota-mime-url-policy-01.txt

About the author

Phani Prasad Vinnakota Rajendra is the author of the IETF Internet-Draft referenced above. He brings over two decades of experience spanning web application development, embedded systems, legal discovery, cybersecurity, and large-scale database architecture, with a focus on building scalable and resilient systems.

Disclaimer: This article is for informational purposes only and does not constitute legal advice. Case citations and regulatory references are provided for context; readers should consult qualified counsel for guidance on specific situations.