What is the difference between rewriting all URLs and rewriting only suspicious links?

Rewriting all URLs creates broader coverage, but it can add noise, user fatigue, and unnecessary processing. Rewriting only suspicious links is a more selective control that uses risk scoring to focus scrutiny on messages most likely to be malicious. That approach preserves visibility on higher-risk traffic without turning every link into a security event.

Why Selective URL Rewriting Changes the Security Tradeoff

Rewriting every URL is a blunt but simple way to force traffic through a protection layer, while rewriting only suspicious links is a narrower control that depends on detection quality. The practical difference is not just scope: it changes how much user friction, helpdesk noise, and message handling overhead the organisation is willing to accept in exchange for broader interception. For email security teams, that tradeoff matters because the wrong setting can either overwhelm users or miss messages that deserve closer inspection.

Selective rewriting is usually more sustainable when an organisation already has scoring, filtering, or threat intelligence that can distinguish ordinary communications from higher-risk ones. It is also easier to justify where business units are sensitive to link handling, because fewer messages are altered and fewer benign clicks are routed through additional checks. Teams that adopt the broader model often do so to maximise coverage during periods of elevated phishing activity, but they still need to account for false positives and the operational cost of treating harmless links as security events. In practice, many security teams discover the friction cost only after users begin to ignore warnings or route around the control.

How the Two Approaches Work in Practice

All-URL rewriting usually works by normalising every link in a message so that clicks pass through a security gateway or detonation path. That gives the control a consistent inspection point and can simplify reporting, because every outbound click is handled the same way. The downside is that the gateway now becomes part of the normal user experience, which means any latency, false blocking, or tracking artefacts affect all mail rather than just risky mail.

Suspicious-only rewriting is more selective. The system first evaluates the message or embedded link, then rewrites only when the message crosses a defined risk threshold. That threshold may use sender reputation, domain age, impersonation patterns, URL characteristics, or campaign correlation. The benefit is reduced noise: benign newsletters, internal notices, and expected vendor messages can flow with less disruption, while higher-risk messages receive extra scrutiny. The cost is dependence on detection accuracy. If the classifier is too conservative, malicious links remain untouched; if it is too aggressive, the control starts behaving like the broad model without the same transparency.

A useful way to think about it is that all-URL rewriting is coverage-first, while suspicious-only rewriting is judgment-first. The first model is easier to explain but noisier to live with; the second is easier to live with but more dependent on tuning, telemetry, and periodic review. OWASP Non-Human Identity Top 10 is not directly about email URL rewriting, but it is a useful reminder that any security control relying on automated decision-making needs clear ownership, scope, and failure boundaries.

All-URL rewriting gives uniform enforcement and simpler audit trails.
Suspicious-only rewriting reduces friction but depends on detection thresholds and review quality.
Both approaches need exception handling for internal tools, signed communications, and critical business workflows.

Where this guidance breaks down is when the organisation cannot reliably distinguish suspicious from benign messages, because then selective rewriting becomes inconsistent and broad rewriting becomes unnecessarily disruptive.

Where Selective Rewriting Breaks Down and What Practitioners Should Watch

Tighter link rewriting often increases operational overhead, requiring organisations to balance phishing resistance against user trust and message fidelity. The edge case is not whether the control works in principle, but whether it behaves predictably across the mail patterns the business actually uses.

Internal newsletters, marketing platforms, ticketing systems, and automated notifications can all look unusual to a detector without being malicious. If the scoring model is weak, selective rewriting becomes a source of false alarms; if the rewrite engine is overly aggressive, all-URL rewriting starts to look safer because at least its behaviour is consistent. There is also a governance issue: once users see some links rewritten and others left alone, they begin asking which messages are trusted and which are merely unreviewed. That ambiguity can be useful when it reflects risk, but harmful when it reflects tuning gaps. The strongest programmes document the decision rule for rewriting, the exception process for business-critical mail, and the review cadence for thresholds.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	9.1 — Email and Web Browser Protections	URL rewriting is a mail/web protection control that filters risky links.
Recommendation — Apply browser and email protections to redirect risky clicks through inspection.
MITRE ATT&CK	T1204 — User Execution	Rewritten links aim to disrupt the user-click path attackers depend on.
Recommendation — Map click-based delivery patterns to T1204 and tune detections for user-execution lures.
NIST CSF 2.0	PR.AC — Access Control	Rewriting changes how users access external destinations through trusted gateways.
	DE.CM — Security Continuous Monitoring	Selective rewriting depends on ongoing detection and threshold monitoring.
Recommendation — Use access-control policy to define when links are intercepted and when exceptions apply. Continuously monitor alert quality and adjust suspicious-link thresholds as campaigns change.
OWASP Non-Human Identity Top 10	NHI-01 — Inventory and Ownership	The supplied link is only tangentially relevant; no intrinsic NHI subject is present.
Recommendation — Do not map this topic to NHI-specific controls unless machine identity is the primary subject.

Practitioner Guidance

What to prioritise: Decide whether your main objective is maximum interception or minimum disruption. If the business is facing active phishing pressure and can tolerate friction, broad rewriting is easier to defend; if user experience and message integrity matter more, selective rewriting needs strong detection and regular calibration.

What to verify: Test how the control handles common legitimate patterns, not just obvious phishing samples. Teams should verify false-positive rates, click-path latency, and whether rewritten links preserve enough context for users and analysts to trust the message they are opening.

Common mistake: Treating selective rewriting as a set-and-forget optimisation. The threshold ages quickly as attacker behaviour, vendor messaging, and internal notification patterns change, so the control needs periodic retuning rather than static policy.

Practitioner takeaway: The real decision is not “rewrite or do not rewrite,” but how much trust you place in detection to decide which links deserve extra control and which should remain untouched.