Safe Links in Microsoft 365: is rewriting links really a good idea?

A security measure should help people assess a risk, and must not hide the information they need to do so.

Microsoft Defender for Office 365 can check links in email with Safe Links. When a recipient clicks a suspicious link, Microsoft can block access to the website. That is a useful additional layer of protection against phishing.

Many organisations also enable link rewriting. The original URL is then replaced by a long address on safelinks.protection.outlook.com. This allows Microsoft to check the link again at the moment someone clicks it.

The problem is that the recipient can no longer see clearly where the link really leads. Just as employees are being taught to check the address before clicking, the technical security measure makes that address harder to read.

So the debate is not about whether Safe Links is useful. The real question is whether that protection requires rewriting every single link.

What exactly does Safe Links do?

Safe Links is part of Microsoft Defender for Office 365. Although the feature is often referred to as an Exchange feature, you configure it in the Microsoft Defender portal or via Exchange Online PowerShell. Safe Links can perform several checks:

• Links are examined before the email is delivered.
• Suspicious links and links to files can be examined in more depth.
• Microsoft can hold delivery of the message until the check is complete.
• The link can be checked again when the recipient clicks it.
• A known malicious website can be blocked before it opens.

The pre-delivery check takes place whether or not the link is rewritten. Rewriting is therefore not needed to run that first check.

What happens when links are rewritten?

An original link might look like this: https://www.example.com/login. Safe Links can change it into an address that starts with https://eur01.safelinks.protection.outlook.com/. The original destination is then encoded in a long series of parameters behind the Microsoft address. When the recipient clicks the link, the request first passes through Microsoft, which checks whether the destination has since become known as malicious.

This time-of-click check is valuable. A website can still be harmless when the email arrives and only be altered a few hours later. This is also known as a delayed phishing attack. Thanks to the time-of-click check, Microsoft can still block such a later-modified website.

Why the destination becomes less recognisable

A URL carries information. The domain shows which organisation is behind the website. An employee can, for example, tell the difference between https://login.microsoftonline.com and https://microsoft.login-check.example. In the second example the visitor does not end up at Microsoft. The real domain is login-check.example. The word Microsoft is only there to inspire trust.

Security authorities therefore advise recipients to hover over a link before clicking and check which address appears. Watching for small deviations in domain names is also an important part of recognising phishing.

Safe Links can make this harder. When copying a link, in certain notifications, in plain text and in some other applications, the recipient mainly sees the long Microsoft address. The real destination is then no longer directly recognisable.

Microsoft states that supported versions of Outlook can show the original URL in a pop-up when hovering over a rewritten link. In the normal Outlook view the destination therefore does not have to be completely hidden. The experience can, however, differ per Outlook version, device, message format and application in which the email is opened.

The objection to rewriting is therefore not that the original destination is invisible under all circumstances. The objection is that a simple, recognisable link is replaced by a complex technical construction whose readability depends on the application being used.

The security measure contradicts the training

Many organisations teach employees to:

• check the domain before clicking;
• hover over a link to see the destination;
• watch for unusual spelling;
• check whether the address matches the sender;
• go to the known website directly when in doubt.

These are sensible recommendations. They help employees assess a risk independently. When all links are rewritten to a Microsoft address, however, a contradictory message emerges. The organisation says employees should check a link, but the technical setup makes that check harder.

A long Safe Links URL can also inspire unintended trust. After all, the recipient sees a Microsoft address. That can lead to the incorrect conclusion that the final website must be safe.

Safe Links checks a link, but does not guarantee that a website is trustworthy. New phishing websites may still be unknown. A legitimate website may have been compromised, and attackers can use techniques to show automated checks different content than ordinary visitors. The technical check therefore remains an additional layer of protection and must not replace the recipient's own judgement.

Microsoft can also check without rewriting

Within a custom Safe Links policy, Microsoft offers the setting Do not rewrite URLs, do checks via Safe Links API only. When this setting is used:

• the original URL remains in the message;
• the link is still checked before delivery;
• Microsoft can check again at click time in supported Outlook versions;
• the content of the email does not need to be modified.

The time-of-click check is then performed through a function in Outlook instead of a redirect in the URL. Microsoft supports this in Outlook for Windows, Outlook for Mac and Outlook on the web. This shows that scanning and rewriting are two separate design choices. You can use Safe Links without automatically changing every URL.

The limitation of checking via the Safe Links API

The API variant also has an important drawback. The time-of-click check only works in applications that support this feature. If someone opens the message in another mail client, the pre-delivery check still applies, but the additional check at click time may be missing. A link that was safe on arrival and is made malicious later could then still be opened.

Microsoft itself gives the example of a user who clicks such a later-modified link in an alternative mail client. Because that mail client does not support the Safe Links API, the change is not detected at click time. The decision not to rewrite should therefore be based on the actual working environment:

• Do virtually all employees use a supported version of Outlook?
• Is business email also opened in other mail clients?
• Are messages often forwarded automatically to external addresses?
• Do employees use shared devices or outdated Outlook versions?
• How important is protection against links that only become harmful later?
• How much weight does the recognisability of the original destination carry?

There is no setting that is automatically best for every organisation.

Microsoft itself uses both models

Microsoft's default configurations show that there is no single obvious choice. Within the built-in baseline protection, Microsoft uses Safe Links without URL rewriting. In the preset security levels Standard and Strict, links are rewritten.

When a new custom policy is created through the Microsoft Defender portal, the option not to rewrite is enabled by default. If you create the policy via PowerShell, rewriting is not disabled by default.

In Microsoft Teams and supported Office applications, Microsoft can also check links at click time without rewriting them. This confirms that URL rewriting is not a technical precondition for every form of Safe Links protection.

What is a sensible configuration for most organisations?

For an organisation that mainly works with current, supported versions of Outlook, the following configuration is worth considering:

• Enable Safe Links for email.
• Enable real-time scanning of suspicious links and links to downloads.
• Let Microsoft hold delivery until the check has completed.
• Apply Safe Links to internal messages as well, when the risk of compromised internal accounts carries enough weight.
• Enable "Do not rewrite URLs, do checks via Safe Links API only".
• Do not allow users to click through a serious Safe Links warning.
• Test the behaviour in all Outlook versions and on all relevant devices in use.

This keeps the original destination readable, while the pre-delivery check remains in place and supported Outlook versions also check again at click time.

For organisations with many different mail clients, rewriting can be a defensible choice. The redirect through Microsoft then ensures that the time-of-click check does not depend on Outlook. Rewriting is therefore not wrong by definition. It is mainly wrong when it is enabled without deliberation and then presented as nothing but added security.

Also consider the drawbacks for email and investigations

Rewriting links does not only affect awareness. It also changes the content of the message. That can be noticeable when:

• copying a link into a document or report;
• forwarding a message;
• archiving email;
• comparing a message with the original;
• conducting digital forensics after an incident;
• processing by other email or ticketing systems;
• displaying links on mobile devices;
• accessibility and the use of assistive technology.

Microsoft also rewrites a URL per recipient. When a message is forwarded or answered manually, links that were already rewritten can remain rewritten.

For incident investigations the original destination can usually still be extracted from the Safe Links URL, but for an ordinary recipient that is not practical. A security measure that can be deciphered for technical investigation is not therefore user-friendly.

Human verification remains necessary

No technical check knows all malicious websites. Especially with targeted phishing, a domain may only exist briefly or be used against a small group of victims. Employees must therefore keep looking at the context:

• Am I expecting this message?
• Does the request fit the sender?
• Is there unusual urgency?
• Am I being asked to log in again when that is normally not needed?
• Is there a request for money, personal data or a change of payment details?
• Does the destination match the organisation mentioned in the message?

A recognisable URL helps with that assessment, but is not enough. Even a correct-looking domain can have been compromised. URL checks should therefore be combined with process agreements, phishing-resistant multi-factor authentication and an easy way to report.

How do you include Safe Links in an awareness programme?

Explain to employees what Safe Links does and does not do. Merely telling them that the feature exists is not enough. The key message is:

Safe Links can block known malicious websites, but a link that is not blocked is not automatically safe.

Show in training sessions:

• how a normal web address is structured;
• where the real domain sits in a long URL;
• how subdomains can be abused;
• that the Microsoft address of Safe Links is not the final destination;
• how employees report a suspicious email;
• when to verify the sender through another channel.

Use phishing simulations to measure more than just who clicks. Also measure how many employees report a suspicious email and how quickly the first report comes in. One employee who files a good report can prevent dozens of colleagues from clicking the same link. In practice that is often more valuable than chasing an unrealistic click rate of zero.

The conclusion

Safe Links is a valuable security measure. Scanning links before delivery and at click time can prevent many phishing attacks. Automatically rewriting every link, however, comes at a price. It makes the destination less transparent, changes the content of the email and can undermine the security advice to check links yourself.

Because Microsoft also supports checking via the Safe Links API, organisations do not simply have to choose between technical protection and readability. For organisations that almost exclusively use supported Outlook versions, checking via the Safe Links API without URL rewriting is the obvious route. In an environment with many different mail clients, rewriting can still be justified.

The right choice therefore does not start with the question of which button Microsoft recommends, but with the question of which configuration offers the best combination of technical protection, transparency and safe behaviour in your working environment.

Related articles

• External sender warning in Exchange: how effective is the banner?
• Phishing red flags employees should know
• Why phishing simulations work
• How to spot CEO fraud and prevent it
• Email security and social engineering: what employees need to know

Sources

• Microsoft Learn: Safe Links in Microsoft Defender for Office 365
• Microsoft Learn: Set up Safe Links policies
• Microsoft Learn: Recommended security settings for Microsoft 365
• NCSC (Netherlands): How do I recognise a phishing email?
• NCSC (Netherlands): Getting started against phishing

FAQ

Is Safe Links the same as Exchange Online Protection?

No. Safe Links is a feature of Microsoft Defender for Office 365. The feature works alongside the regular protection against spam and malicious files, but requires a suitable Defender for Office 365 licence.

Are links still checked when rewriting is off?

Yes. Microsoft checks links before delivery even when URL rewriting is disabled. In supported Outlook versions an additional check via the Safe Links API can also take place at click time.

Why does Microsoft rewrite links?

By routing the click through Microsoft, the destination can be checked again just before it opens. This protects, among other things, against websites that are only made malicious after the email has been delivered.

Is URL rewriting a bad security measure?

Not under all circumstances. In an environment with varied or unsupported mail clients, rewriting can provide valuable protection at click time. The downside is that the original destination becomes harder to read and the content of the email is modified.

What is the advantage of the Safe Links API?

The original link stays intact. The email is easier to read and the recipient can assess the destination domain more easily. In supported Outlook versions an additional check at click time remains possible.

What is the drawback of the Safe Links API?

The additional check at click time depends on support by the mail client. In an alternative mail client, only the check performed before delivery offers protection.

Can an employee assume that a link that is not blocked is safe?

No. Safe Links lowers the risk, but cannot give a full guarantee. New, targeted or technically cloaked phishing websites may still be unknown. The recipient must therefore keep assessing the sender, the context and the destination.

Which setting is preferable?

For organisations that almost exclusively use current, supported Outlook versions, scanning via the Safe Links API without URL rewriting is preferable. In a mixed mail environment, the benefit of universal click-time checking must be weighed against the reduced readability.