Safe link rewriting is a security technique that rewrites URLs in email or web traffic so users click a filtered link that is checked again at access time. The rewritten link lets a gateway inspect the destination, block known malicious sites, and reduce time-of-click phishing and malware exposure.
How safe link rewriting works
Safe link rewriting changes a URL before delivery so the email client or gateway can route the click through a security service first. That service evaluates the destination again at click time, which matters because threat actors often shift links after delivery or hide behind initially benign infrastructure.
The technique is strongest when the rewritten URL preserves enough context for the user while making the destination inspectable by policy, reputation, and sandboxing checks. It is not a substitute for user awareness or authentication controls, but it adds a control point at the moment of risk, which is often where phishing succeeds.
Why time-of-click inspection matters
Classic email filtering only sees the message when it arrives. Safe link rewriting adds a second decision point later, so a link that looked harmless at delivery can still be blocked if the destination turns malicious, is newly registered, or begins redirecting to payloads after the message is sent.
This is especially useful against phishing kits and malware campaigns that rely on delay, redirects, or link cloaking. It also helps when users forward messages or click from different devices, because the security decision travels with the link rather than with the original inbox view.
Where rewriting can fail or be bypassed
Link rewriting reduces exposure, but it does not remove it. Attackers can abuse shortened URLs, nested redirects, compromised legitimate sites, or sign-in prompts that appear only after the first safe hop. Users may also copy a rewritten URL into another context, which can break the intended inspection path.
Because the control depends on the security service seeing the final destination, gaps in URL normalization, unsupported protocols, or poorly handled redirects can weaken protection. The practical question is whether the gateway can still make a reliable decision at the moment the user reaches the target.
How organisations use it in layered email security
Safe link rewriting is usually one layer in a broader anti-phishing stack that includes attachment scanning, impersonation detection, sender authentication, user reporting, and post-click investigation. Used well, it narrows the window between delivery and exploitation and gives defenders a chance to stop a live campaign after the email has already landed.
For Microsoft 365 environments, Microsoft 365 Security Guide and Microsoft Defender for Office 365 Configuration Guide are useful references for the surrounding hardening, policy, and alerting model. For a broader phishing threat view, MITRE ATT&CK T1566 Phishing shows how link-based initial access fits into the attack chain.
Risk and Threat Considerations
Safe link rewriting reduces phishing exposure, but it also creates a trusted inspection dependency. If the rewriting service is bypassed, misconfigured, or unable to analyse the final redirect chain, users may still reach credential-harvesting pages or malware delivery sites before defenders see the abuse.
Failure mechanism: Attackers exploit gaps between delivery-time scanning and click-time inspection, or they use redirects, compromised domains, and scanner evasion to make the rewritten link resolve to a harmful destination after the message is delivered.
Impact: A successful bypass can lead to credential theft, session capture, malware execution, and follow-on account compromise, especially when the clicked link lands on a convincing login page or a staged payload hosted on trusted infrastructure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | Safe link rewriting is an email and web click protection control. |
| Recommendation — Enable safe link inspection for email and web traffic to block malicious destinations at click time. | ||
| NIST SP 800-53 Rev 5 | SI-8 — Spam Protection | Controls filtering and blocking of malicious email content and links. |
| Recommendation — Apply SI-8 to filter malicious messages and associated links before users can act on them. | ||
| OWASP ASVS | V12 — Secure Communication | Rewritten links depend on trustworthy transport and destination verification at click time. |
| Recommendation — Verify that security controls preserve destination integrity and inspection across redirects. | ||
| MITRE ATT&CK | T1566.002 — Spearphishing Link | Link rewriting directly counters phishing links used for initial access. |
| Recommendation — Map suspicious click telemetry to T1566.002 and hunt for link-based initial access. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-Transit is Protected | Click-time inspection protects user interaction with URLs in transit across delivery and access. |
| Recommendation — Protect link traffic in transit and enforce destination checks at the point of access. | ||
Practitioner Guidance
Why practitioners should care: Safe link rewriting works best when it is treated as an enforcement control, not just a visibility feature. The most useful deployments combine policy, reputation, and user-facing warnings with telemetry that lets analysts review clicks, verdict changes, and post-click outbreaks.
What to watch for: Pay close attention to false negatives around redirects, newly registered domains, and legitimate sites that are later compromised. If users report that safe links are breaking workflows, validate whether the control is preserving the inspection path or whether exceptions have opened a blind spot.
Related resources from NHI Mgmt Group
- Guide: Phishing links
- Where do link-rewriting and sandboxing controls fail in email attacks?
- How do security teams know if deep-link handling is safe enough in a mobile app?
- Why do helpers like raw, html_safe, and link_to become dangerous when they receive user-controlled values?
- What is the difference between writing new code in memory-safe languages and rewriting legacy code first?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org