Rewritten Link Still Blocked After Allowlisting in INKY

Overview

This article explains why a link may still be blocked after a sender, domain, message, or URL has been allowlisted in INKY.

A link issue is different from a message delivery issue. The email may be delivered successfully, and the sender may be trusted, but a URL inside the message can still be blocked by INKY link rewriting, Microsoft Safe Links, browser protection, endpoint security, or another URL security service.

Use this article if you are seeing behavior such as:

  • A sender was allowlisted, but the user still cannot click a link.
  • A message was reported as safe, but a link inside it is still blocked.
  • A user sees an INKY block page after clicking a rewritten link.
  • A user sees a Microsoft Safe Links page after clicking a link.
  • A URL is still blocked even though the email was allowed.
  • A link exception was added, but an already-delivered email still has a blocked link.
  • Multiple users received the same email, but each user’s rewritten link behaves separately.

Important concept: message allow and link access are separate

Allowing a sender, domain, or message does not always unblock links inside the email.

INKY may evaluate:

  • Who sent the message
  • Whether the message appears suspicious
  • Whether the message contains phishing or impersonation indicators
  • Whether a URL inside the message is risky
  • Whether the URL should be rewritten, blocked, or allowed

Because of this, a message can be allowed or delivered while a URL inside the message remains blocked.

Before changing settings, confirm whether the problem is:

  • The message itself is blocked, quarantined, or flagged
  • The message is delivered, but a link inside the message is blocked

If only the link is blocked, focus on link rewriting and URL behavior.

Step 1: Confirm what happens when the user clicks the link

Ask the affected user what they see when they click the link.

Common outcomes include:

What the user sees Most likely area to check
INKY block page INKY link rewriting or INKY URL analysis
Microsoft Safe Links page Microsoft Safe Links
Browser warning Browser protection, endpoint security, or destination website reputation
Timeout Destination website, rewritten URL, or network issue
404 or website error Destination website or URL issue
Nothing happens Browser, email client, or endpoint issue

The block page is important because it helps identify which system is blocking the link.

Step 2: Confirm whether the link is rewritten by INKY

INKY may rewrite links in emails so that URLs can be analyzed when users click them.

Check whether the URL starts with an INKY rewriting domain or redirects through INKY before reaching the destination.

If the link is rewritten by INKY and the user sees an INKY block page, continue reviewing INKY link behavior.

If the user sees a Microsoft Safe Links page, the block may be coming from Microsoft Safe Links instead.

If the user sees a browser warning or endpoint security page, the block may be outside INKY.

Step 3: Check the INKY banner color

The INKY banner color can affect whether an allow or report action can change link behavior after the message has already been delivered.

Confirm whether the message has a red/Danger banner or gray/Caution banner.

Red/Danger banner

If the email was delivered with a red/Danger banner, allowlist entries are generally not retroactive for the blocked links in that already-delivered message.

In this case, later allowlisting the sender, domain, or URL may help future messages, but it may not automatically open the links in the already-delivered email.

To open links in that specific email, the message may need to be reported as safe using the available INKY reporting action, then confirmed by the appropriate administrator or dashboard workflow.

Important: this applies to the specific message. If the same email was sent to multiple recipients, each recipient’s rewritten link may need to be handled separately.

Gray/Caution banner

If the email was delivered with a gray/Caution banner, URL behavior may be checked at click time. In this case, adding the URL or domain to the appropriate allow list or exception may allow later clicks to open successfully.

This means gray/Caution link behavior may be more likely to respond to URL/domain allow changes after delivery than red/Danger link behavior.

Step 4: Confirm whether the email was already delivered

Some link-related changes only apply to future messages.

If a link rewriting exception or URL exception is added after an email was already delivered, it may not update the rewritten links that are already in the user’s mailbox.

Ask:

  • Was the email already delivered before the exception was created?
  • Are you trying to open a link in an existing email?
  • Or are you trying to prevent future emails from having the same issue?

If the goal is to prevent future link blocks, add the appropriate URL or domain exception and send a new test message.

If the goal is to open a link in an already-delivered message, the correct action may depend on the banner color, message classification, and whether the block is coming from INKY or another tool.

Step 5: Confirm whether the sender or the URL was allowed

A sender allow and a URL exception are different.

If only the sender or sender domain was allowed, links inside the message may still be blocked.

Check whether the customer allowed:

  • Sender address
  • Sender domain
  • Message
  • URL
  • Link domain
  • Link rewriting exception
  • Microsoft Safe Links allow
  • Browser or endpoint security allow

If the problem is only with the link, review the URL or link domain directly.

Example:

Allowing trustedvendor.com may not allow payments.thirdpartyportal.com.

Step 6: Review Link Rewriting Exceptions for future messages

Link Rewriting Exceptions can be used to prevent specific trusted domains from being rewritten in future messages.

This is useful when a known-safe domain is repeatedly blocked or rewritten unnecessarily.

Important notes:

  • Link Rewriting Exceptions apply to future messages.
  • They may not change links in emails that were already delivered.
  • They should be used carefully and only for domains confirmed to be trusted.
  • Do not broadly exempt large public domains or shared infrastructure unless the risk is fully understood.

Step 7: If the user needs the link immediately

If a user needs access to the destination quickly, an administrator may be able to review the message in the INKY dashboard and locate the original destination URL in the message or threat details.

Before sharing the original URL, confirm that the link is legitimate and safe.

Recommended checks:

  • Confirm the sender is legitimate.
  • Confirm the destination domain is expected.
  • Review the INKY classification.
  • Review the block page reason.
  • Check whether Microsoft Safe Links, browser protection, or another tool is also blocking the site.
  • If available, review the original message headers or EML.

Step 8: If multiple users received the same link

INKY rewritten links may be unique to each message or recipient.

If the same email was sent to multiple users, fixing or reporting one message may not automatically remediate every copy of the email.

Check:

  • How many users received the email?
  • Are all users seeing the same block page?
  • Is each blocked link rewritten uniquely?
  • Was the email sent once to a distribution list or individually to multiple users?
  • Is the request to fix existing emails or prevent future emails?

If the issue affects multiple users, review whether a URL/domain exception is appropriate for future messages.

Step 9: Check whether Microsoft Safe Links or another tool is blocking the URL

A link may pass through INKY and then be blocked by Microsoft Safe Links, browser protection, endpoint protection, DNS filtering, or another security service.

Use the block page or rewritten URL format to identify the system.

Indicator What it usually means
INKY-branded warning or block page INKY link rewriting or URL analysis
Microsoft Safe Links URL or warning page Microsoft Safe Links
Browser “deceptive site” or “unsafe site” warning Browser reputation or security service
Endpoint or DNS filtering page Endpoint security, DNS security, or web filtering
Website 404, timeout, or access denied Destination website or network issue

If Microsoft Safe Links is blocking the URL, review Microsoft Safe Links policies and allow procedures.

If browser or endpoint protection is blocking the URL, review the destination website reputation and endpoint/browser security controls.

Common causes

Cause What it means What to check
Sender was allowed, but URL was not The sender allow does not apply to the link destination Review URL/link domain
Message was already delivered New exceptions may only apply to future mail Send a new test message
Red/Danger banner Later allowlisting may not retroactively open links in that email Use the appropriate report-safe/admin review workflow
Gray/Caution banner URL may be checked at click time Review URL/domain allow behavior
Microsoft Safe Links is blocking The block is from Microsoft, not INKY Review Safe Links policy
Browser warning appears Browser or endpoint security is blocking the destination Review site reputation and endpoint policy
URL uses third-party redirect/tracking service Destination may differ from visible link text Review final destination URL
Same link went to multiple users Each rewritten link may be unique Review each affected message or use future exception

Information to gather before contacting support

If the link is still blocked after reviewing this article, gather one affected example.

Include:

  • Customer or team name
  • Sender address
  • Recipient address
  • Subject line
  • Date and time received, including time zone
  • Screenshot of the INKY banner, including banner color
  • Screenshot of the block page
  • The rewritten URL, if safe to share
  • The destination URL or domain, if known and safe to share
  • Whether the sender/domain, message, URL, or link domain was allowlisted
  • Whether the email was already delivered before the allow or exception was added
  • Whether Microsoft Safe Links or another URL protection tool is enabled
  • Full message headers or EML, if available
  • Microsoft 365 Message Trace or Google Workspace Email Log Search result, if available

 

 

Have more questions?

Contact us

Was this article helpful?
0 out of 0 found this helpful

Provide feedback for the Documentation team!

Browse this section