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:
- Sender: billing@trustedvendor.com
- Link destination: payments.thirdpartyportal.com
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