Secure email gateways rewrite links to route clicks through a security service that can inspect the destination, block known threats, and sometimes recheck a link when it is opened. They should not always do so: rewriting can break workflows, expose click activity to another service, create compatibility problems, and provide little extra protection when other controls already address the risk.
What a secure email gateway does
A secure email gateway is a system that checks email as it enters or leaves an organization. Depending on its configuration, it may filter spam, scan attachments, apply policy, and assess links for phishing or malware. It can be operated as a cloud service, installed within an organization’s environment, or combined with other email security controls.
Link rewriting is one possible part of this filtering process, not a universal feature. A gateway changes a link in the message so that a click first passes through a security service. The service can then assess the destination and either allow the user to continue or show a warning or block page.
This matters because an email can be judged safe when it arrives and become dangerous later. A sender might use a legitimate site that redirects visitors, or a harmful page might appear only after the message has passed through initial scanning. Rechecking at click time can help close that gap.
How link rewriting works
In a message without rewriting, a link points directly to its destination. With rewriting, the visible link text may still look ordinary, but the underlying address leads first to a security service. That service identifies the destination associated with the link, checks it against its available security information, and applies the organization’s policy.
The exact process varies. Some systems assess the destination when the message is received, some check again when a person clicks, and some use both approaches. A gateway may also inspect redirections, where one address sends a visitor onward to another. Its ability to follow those steps depends on the service and the behavior of the destination.
A simplified example: an employee receives a message with a link to a document. The gateway replaces the original destination with a protected link. If the document address is later found to lead to a phishing page, a click-time check may warn the employee even though the message was delivered earlier.
Rewriting does not mean a gateway can see everything that happens after a click. A service may be unable to inspect a page that requires a login, behaves differently for different visitors, or changes after the check. A warning system reduces some risks; it does not make every link safe.
Why gateways rewrite links
The central reason is the time gap between delivery and a user’s click. Email security tools commonly scan messages before delivery, but a link’s reputation or destination can change afterward. Click-time inspection gives the gateway another opportunity to catch a threat.
Rewriting can also make security policy more consistent. Rather than relying only on a person to recognize a suspicious address, an organization can apply a common decision process across covered messages. Depending on the product, administrators may be able to record blocked attempts or investigate which messages contained a particular link.
Some systems use rewritten links to show a warning before a person visits a destination considered risky or unverified. Others may use them to block access. These responses are policy choices; the mere presence of a rewritten link does not reveal whether the destination has been classified as dangerous.
- Reputation checks: Compare a destination with threat information available to the security service.
- Click-time reassessment: Check again when a user activates the link, rather than relying only on the delivery-time scan.
- Centralized enforcement: Apply an organization’s warning or blocking rules across messages.
- Incident investigation: In some configurations, provide records that help security staff understand link activity.
Why rewriting can cause problems
A rewritten link is longer and different from the address a sender placed in the message. That can make it difficult to judge where it ultimately leads, particularly when a person is reading on a small screen or copying a link into another application. The visible link label can still be misleading, so users should not treat either the label or the rewritten form as proof of safety.
Rewriting can also interfere with applications that expect a particular link format. Links used for account verification, sign-in, document access, or other automated processes may include unique information or rely on a specific sequence of redirects. A security service may handle many such links correctly, but compatibility depends on the service, the destination, and the application. A failure may look like an expired link, an access error, or a repeated warning.
Privacy is another consideration. A click routed through a security provider can create a record of link activity, depending on the service’s design and settings. That record may be useful for threat response, but organizations should understand what is collected, who can access it, and how it is handled. It is not accurate to assume that every rewriting system records the same information.
Finally, the mechanism can create false alarms or delays. A legitimate page may be blocked because its reputation is uncertain, or a warning page may add an extra step to routine work. If users encounter too many unnecessary warnings, they may become less attentive to warnings that matter.
When rewriting is useful—and when it may not be
Rewriting is most useful when an organization wants an additional check at click time, especially for messages that could lead to account theft or harmful downloads. It can be a practical layer for staff who receive messages from outside the organization and cannot independently verify every destination.
It may be less useful when the gateway’s checks are unreliable for important workflows, when the organization cannot accept the associated activity logging, or when equivalent protection is already provided by another well-configured control. That does not automatically mean rewriting should be disabled. The decision should consider the actual risks, the users and systems affected, and the safeguards that would remain.
For example, a university might want click-time checking for ordinary incoming messages but find that a rewritten link disrupts a learning platform’s sign-in flow. The sensible response is to investigate the specific failure and consult the gateway and application documentation. Broadly disabling link protection because one workflow broke could leave unrelated links without that layer of checking.
Rewriting is also not a substitute for checking who sent a message, using multifactor authentication where available, keeping devices and software maintained, or reporting suspicious messages. Security depends on multiple controls; no single link scanner can establish that a message or destination is trustworthy.
Alternatives and complementary protections
Organizations can assess links without changing every link in every message. Depending on their systems, they may scan destinations at delivery, use browser or endpoint protections, restrict access to known harmful destinations, or apply additional checks to messages judged higher risk. These approaches have different strengths and limitations, and some can be combined with rewriting.
Delivery-time scanning is less intrusive for users, but it may not detect a destination that changes later. Browser protections can help at the point of access, but their coverage and policy depend on the environment. User education helps people recognize unusual requests, but it cannot reliably replace technical controls. A layered approach can reduce reliance on any single method.
For an individual user, the practical alternative is not to try to decode a long rewritten link. If a message asks for credentials, payment, or urgent action, verify the request through a separate trusted route, such as an established internal contact or a known application. Do not use contact details supplied only in the suspicious message.
How to evaluate a rewriting policy
Before enabling, changing, or exempting link rewriting, administrators should review the policy and test the workflows people actually use. A sensible review asks both whether the control catches relevant threats and whether it creates avoidable disruption.
- Identify which messages and users are covered, including any exceptions.
- Check how the service handles redirects, sign-in links, and links with unique access tokens.
- Understand what click activity is recorded and who can review it.
- Test common business or campus workflows, including access from mobile devices.
- Review how users report false blocks and how exceptions are approved.
- Confirm that exceptions are narrow, documented, and periodically reassessed.
Administrators should consult the gateway’s official documentation and the documentation for affected applications, since behavior and available settings differ. If a link fails, record the message context and the error shown, then ask the relevant support team to investigate. Avoid forwarding a sensitive or suspicious link to an unapproved service for testing.
Common misconceptions
“A rewritten link means the original was malicious.” Not necessarily. Rewriting may be applied to all links, selected categories of messages, or destinations that need another check. The format alone does not indicate the security verdict.
“A safe result guarantees the page is safe.” It does not. A destination can change after inspection, behave differently for a particular user, or contain content the gateway cannot assess. Treat a clean check as one useful signal, not a guarantee.
“Disabling rewriting removes the need for link security.” Disabling one control does not eliminate the underlying risk. An organization should first determine what protection replaces it, if any, and whether the change is limited to a specific workflow.
Frequently Asked Questions
Why does my email link look different after delivery?
A security gateway may have replaced the original destination with a link that routes through its checking service. This allows the service to assess the destination when you click, depending on its configuration.
Can I tell whether a rewritten link is safe?
The rewritten format alone cannot tell you. Pay attention to any warning, consider whether you expected the message, and verify sensitive requests through a separate trusted route. A successful check is not an absolute guarantee.
Why do secure email gateways check links when clicked?
A destination can change after an email is delivered. Checking at click time gives the gateway another chance to identify a newly recognized threat or a changed destination.
Can link rewriting break sign-in or verification links?
It can in some setups, particularly when an application depends on a specific link format or redirect sequence. The cause and fix vary, so users should report the error to their organization’s support team rather than altering the link themselves.
Should an organization turn off link rewriting?
Not as a blanket response to inconvenience. Administrators should weigh threat protection, privacy, compatibility, and other controls, then test whether a narrow exception or a different configuration solves the problem.
The practical takeaway
Secure email gateways rewrite links to add a checkpoint between an email and its destination, often so a threat can be reassessed when someone clicks. The technique is useful but imperfect: it can disrupt legitimate workflows, complicate link handling, and involve activity records. Organizations should use it where it adds meaningful protection, test real-world compatibility, explain warnings to users, and make any exceptions carefully rather than treating rewriting as either essential everywhere or useless everywhere.