Safe Links in Exchange (Safe URLs): why URL rewriting is false security

Microsoft Defender for Office 365 offers Safe Links, in practice often called "Safe URLs". The feature rewrites every link in inbound email to a Microsoft address, so the destination is scanned once more at the moment you click. That sounds sensible: an extra check just before you land somewhere. But the rewriting strips away exactly what you need to judge for yourself — the visible destination. You feel safer while you actually see less. And the heart of the fix is not that Microsoft should stop offering the feature. It is that administrators should stop switching on URL rewriting by reflex and only use it once they have weighed the downsides on purpose.

What does Safe Links (Safe URLs) actually do?

Say you receive an email with a link to https://payment-portal.com/login. With Safe Links on, Microsoft rewrites that link into something like https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpayment-portal.com%2Flogin&data=05%7C01%7C.... The original destination is now buried as a parameter inside a long, unreadable Microsoft URL.

When you click, Microsoft first routes you through its own checking server. That server inspects the target against current threat intelligence (time-of-click scanning). If the address is known to be malicious at that moment, you get a warning page instead of the site. If it is not (yet) known, you are forwarded. So the check happens at the click, not when you read the email.

Why it looks like a good idea on paper

Safe Links is not without value, and it matters to say so honestly. The feature delivers a few real benefits:

Time-of-click protection: a link that was clean at delivery but turned malicious later can still be blocked at the moment of the click.
Central blocking: as soon as Microsoft flags a domain as malicious, all your users are protected at once, without you lifting a finger.
Click telemetry: your SOC or admin team can see who clicked which link. That is gold when investigating an incident.
Low barrier: the feature is on within minutes and costs no extra licence if you already have Defender for Office 365.

The core problem: you can no longer read the real destination

A URL is not an impenetrable technical string. It is information. The domain tells you who you reach. The path hints at what you will do. The parameters give context. A trained eye sees instantly that microsoft-login.secure-verify.ru is not Microsoft, but a Russian domain impersonating it.

Once Safe Links rewrites the link to a safelinks.protection.outlook.com address, that information is gone. You only see a Microsoft URL with a tangle of parameters. You can no longer hover over the link and judge for yourself where it goes. All you see is that it is "something from Microsoft" — which feels exactly as safe as the attacker hopes.

Why this is false security

False security arises when a measure raises the feeling of safety more than actual safety. Safe Links is a textbook case. Employees unconsciously learn: "if the link goes through Microsoft, it has been checked and is therefore safe." So vigilance drops at precisely the moment it is needed most.

And time-of-click scanning is far from watertight. Attackers know exactly how it works and routinely bypass it:

Cloaking: the phishing site shows harmless content to Microsoft's scanner and the real, malicious page to the user. The scan passes; you are deceived anyway.
Zero-hour pages: a brand-new phishing domain is on no blocklist yet. At the click moment Microsoft simply does not know it and forwards you.
Open redirects on trusted domains: attackers abuse a legitimate domain that forwards (for example an ad or tracking service) so the first check looks clean.
Links outside the scope: URLs in attachments, QR codes or images are not rewritten. That is exactly where attackers move their links.

The dilemmas you face as an administrator

This is not a matter of "just on" or "just off". As an administrator you are caught between real, conflicting interests. Those dilemmas are rarely named out loud:

Time-of-click gain versus readability. Turn rewriting on and you gain protection against later-malicious links, but you lose people's ability to read the destination themselves. You cannot maximise both.
Extra layer versus habituation. An extra layer of defence always sounds good, but every layer that reassures people lowers their own alertness. Defence-in-depth can erode human vigilance.
Telemetry versus blindness. The click telemetry is valuable for your SOC, but you buy that data with the blindness of your users. Is that a fair trade?
Perception versus reality. Turning off rewriting feels "less secure" to management and auditors, even if it makes your people more resilient over time. You must dare to explain a choice that looks less safe.
Convenience versus dependence. The more you lean on the automatic check, the more dependent you become on a single vendor that takes the thinking out of your people's hands.

Not Microsoft — you, the administrator, are in control

It is tempting to say "Microsoft should just make the feature better". But the feature is not on Microsoft's desk — it is on yours. You decide in the Safe Links policy whether links are rewritten, whether the original URL stays visible, and which exceptions apply. The power and the responsibility sit with the administrator.

So the message is not "turn everything off", but: stop turning rewriting on as a reflex. Do not treat it as free extra safety, but as an intervention with a price. Weigh the scanning value (time-of-click, telemetry, central blocking) deliberately against the price you pay: people who no longer learn to look. In many organisations that price is higher than the gain, especially if you invest in making people resilient at the same time.

What to do instead

A mature approach combines technology and behaviour instead of sacrificing the second for the first:

Keep the scanning, reconsider the rewriting. Use Defender's detection and blocking value, but question critically whether hiding the URL is worth that value.
Invest in URL literacy. Teach people to read domains: where the real domain ends, what a subdomain is, what an odd extension looks like. This is a skill, not a fact to memorise.
Measure behaviour with phishing simulations. Not to catch people out, but to see whether recognising and reporting improves. Steer on the report rate, not only the click rate.
Make reporting easy and safe. One button to report suspicious mail, without anyone feeling stupid. Fast reports are your best early warning.
Combine with phishing-resistant authentication. With FIDO2 or passkeys a stolen password is worth far less, even if someone does click once.

How to train staff in real URL analysis

Be honest: URL analysis is not easy. Anyone who shouts "people should just check the link, simple, right" does not understand it well enough. Domains can be misleading, subdomains confusing, and attackers deliberately play with your expectations. So train it as a skill, with repetition and real examples.

An important detail: as long as Safe Links rewrites the URLs, you cannot even run this training properly — there is nothing left for your people to read. If you want to teach people to look, the real URL must be visible. Start small: in short, recurring exercises, show a handful of URLs each time and have people point out the real domain. Then build up to harder cases: homoglyphs, long subdomain chains, and links that look right at first glance but are not quite.

How attackers disguise a URL — examples to practise

Use this kind of example in your training. Let people point out themselves what is wrong:

Homoglyphs: goog1e.com (a digit 1 instead of the letter l) or g00gle.com (two zeros). Visually almost identical, technically a different domain.
Misleading subdomain: microsoft.login.secure-verify.ru. The real domain is secure-verify.ru; "microsoft" and "login" are merely subdomains that earn your trust.
Wrong extension: paypal-secure.com instead of the real paypal.com. Familiar brand name, just the wrong domain.
Open redirect: a link to a trusted domain that forwards via a parameter to a malicious site, for example ...?redirect=https://phish.example.

FAQ

Is Safe Links (Safe URLs) completely useless then?

No. The time-of-click scanning, the central blocking of known malicious domains, and especially the click telemetry for your SOC have real value. The problem is not the background detection, but rewriting the visible link plus the false sense of safety it creates. You do not throw the baby out with the bathwater; you only reconsider the rewriting.

Should I turn Safe URLs off right away?

Not blindly. But do not turn it on blindly either. Treat it as a deliberate trade-off: weigh the scanning and telemetry gain against the price that your people can no longer read the destination and grow complacent. If you choose rewriting, do it with eyes open and compensate with URL-analysis training. In many organisations the readability and resilience of people is worth more over time than the extra automatic layer.

How do I recognise myself whether a link is safe?

Read toward the end of the domain: the real domain sits just before the first single slash (the extension such as .com or .nl and the word before it). Everything before that are subdomains an attacker can fill in freely. Watch for homoglyphs (digit 1 for letter l, zero for o), brand names on the wrong domain, and redirect parameters. In doubt? Do not click, but go to the known site yourself or call the sender on a number you already have.

What if an employee clicks a malicious link anyway?

Respond quickly and without blame. Have the employee report to IT immediately, disconnect the device from the network if malware is suspected, and reset the passwords and active sessions of the accounts involved at once. Check that MFA is still intact and review the logs for who else received the same email. A fast, calm report limits the damage far more than a guilty silence.

Where is the line between caution and paranoia?

Caution is a fixed habit around risky actions: logging in, paying, or anything with sensitive data. There you always verify. Paranoia is freezing at every email and daring to do nothing. Draw the line on process: for unusual financial or login requests you verify through an independent channel, for ordinary internal mail you trust your trained instinct. That keeps you both workable and resilient.