Sender/Message Allow vs URL/Link Exception in INKY
Overview
This article explains the difference between allowing a sender or message and allowing a URL or link domain in INKY.
These actions are related, but they do not always solve the same problem. A sender or domain allow may help with future message classification, but it does not always unblock links inside an email. If a user can receive the email but cannot open a link, you may need to review link rewriting, URL exceptions, Microsoft Safe Links, browser protection, or another URL security tool.
Use this article if you are seeing behavior such as:
- A sender was allowlisted, but the user still cannot click a link.
- A domain was allowlisted, but INKY still blocks a URL in the message.
- A message was reported as safe, but the link still does not open.
- A link is still blocked after the sender was added to the allow list.
- A user can open the email, but clicking the link shows an INKY or Microsoft Safe Links block page.
- You are unsure whether to allow the sender, the message, the URL, or the domain.
Why sender allows and URL exceptions are different
Email security checks can apply to different parts of a message.
A sender or message allow is usually related to the email sender, message classification, or banner behavior.
A URL or link exception is related to links inside the email.
For example:
- A message may come from an allowed sender but still contain a suspicious or blocked URL.
- A sender may be legitimate, but one link in the message may be newly registered, compromised, redirected, or classified as risky.
- A message may have been processed before the sender was allowlisted.
- A link may be blocked by INKY link rewriting, Microsoft Safe Links, browser security, endpoint security, or another tool.
Because of this, allowing the sender does not always mean links inside the message will automatically open.
Quick comparison
| Action | What it helps with | What it may not fix |
| Sender allow | Future messages from a specific email address | Blocked links, Microsoft quarantine, Google quarantine, browser blocks |
| Domain allow | Future messages from a specific sender domain | Blocked URLs, sender authentication failures, third-party sender mismatch |
| Message reported as safe | A specific message classification, depending on the category | Future messages, some admin-level detections, some link blocks |
| URL or link-domain exception | Link rewriting or link access for a specific URL/domain | Sender reputation, message classification, quarantine |
| Microsoft Safe Links allow | URL blocks caused by Microsoft Safe Links | INKY message classification or INKY link rewriting |
| Quarantine release | Releases one quarantined message | Future classification or future quarantine decisions |
Step 1: Identify the actual issue
First, confirm what the user is experiencing.
If the email itself is blocked, quarantined, missing, or delivered to Junk
This is usually a message delivery or message classification issue.
Check:
- Is the message in Microsoft 365 quarantine?
- Is the message in Google Workspace quarantine?
- Is the message in Junk?
- Is the message missing from the mailbox?
- Is the message delivered with an INKY banner?
- Was the sender/domain already allowlisted?
- Does the allow entry match the threat category?
- Does the allow entry require DMARC pass?
In this case, start with message delivery, allow list, message trace, or email log troubleshooting.
If the email was delivered but the user cannot click a link
This is usually a URL or link-protection issue.
Check:
- What page appears when the user clicks the link?
- Is it an INKY block page?
- Is it a Microsoft Safe Links page?
- Is it a browser or endpoint security warning?
- Is the link rewritten by INKY?
- Is the link rewritten by Microsoft Safe Links?
- Was the URL or link domain allowed, or only the sender?
- Is the message already delivered, or are you trying to prevent future blocks?
In this case, sender allowlisting may not be enough. Review URL/link behavior.
Step 2: Determine whether the block is message-based or link-based
Use this table to decide which path to follow.
| What the user reports | Most likely issue type | Start with |
| “The email was quarantined.” | Message delivery / quarantine | Microsoft 365, Google Workspace, or INKY quarantine |
| “The email went to Junk.” | Message delivery / filtering | Message trace, email log, spam policy, INKY classification |
| “The email is in the Inbox but has a banner.” | Message classification | INKY banner category and allow list |
| “The sender is allowed but the message still says phishing.” | Message classification / allow mismatch | Threat category, allow scope, DMARC setting |
| “The email is open, but the user cannot click the link.” | Link / URL block | Link rewriting, URL exception, Safe Links, browser block |
| “The link shows a Microsoft warning.” | Microsoft URL protection | Microsoft Safe Links |
| “The link shows an INKY warning.” | INKY URL protection | INKY link rewriting / URL analysis |
| “The browser says the site is unsafe.” | Browser or endpoint protection | Browser, endpoint, or destination reputation |
Step 3: If the sender or domain was allowed, confirm what the allow covers
A sender or domain allow may help with future INKY classification, but the allow must match the issue.
Check:
- Was the sender address allowed?
- Was the sender domain allowed?
- Was the visible From domain allowed?
- Was the actual sending domain reviewed?
- Was the allow created at the correct user, team/customer, or organization level?
- Was the allow created for the correct threat category?
- Does the allow entry require DMARC pass?
- Was the message received before or after the allow was created?
A sender allow may not work as expected if:
- The message was flagged under a different category than the allow entry.
- The allow was created at the wrong level.
- The sender failed DMARC and the allow requires DMARC pass.
- The visible From domain does not match the actual sending service.
- The message was already processed before the allow was created.
- The issue is actually a blocked URL, not a blocked sender.
Step 4: If the user cannot click a link, check the link separately
If the email is already delivered and the issue is only the link, review the URL itself.
Check:
- What is the destination URL or domain?
- Is the URL rewritten by INKY?
- Is the URL rewritten by Microsoft Safe Links?
- Does the user see an INKY block page?
- Does the user see a Microsoft Safe Links block page?
- Does the user see a browser or endpoint warning?
- Was the URL/domain added to a link exception list?
- Is the request to fix one already-delivered message or prevent future link blocks?
Important: adding a sender or domain to the allow list may not automatically unblock a URL inside a message. URL and link handling may require a separate URL/domain exception or link-specific review.
Step 5: Confirm whether the message was already delivered
Some changes apply only to future messages or future clicks.
If a message was already delivered before an allow or exception was created, the existing email may not always change.
For example:
- A sender allow may help future messages but may not change the classification of a message already processed.
- A URL/link-domain exception may help future messages but may not update already-delivered rewritten links.
- Some link behavior depends on whether the link is checked at delivery time or click time.
- Some blocks may be caused by Microsoft Safe Links or browser protection after the message has already passed through INKY.
If you are testing a change, send a new test message after the allow or exception is created.
Step 6: Check whether Microsoft Safe Links or another tool is involved
A link may be rewritten or blocked by more than one tool.
Check the link format or the block page.
Common possibilities:
- INKY rewritten link
- Microsoft Safe Links rewritten link
- Browser warning
- Endpoint security block
- Destination website error
- Third-party URL protection
If the user sees a Microsoft Safe Links page, the block is likely coming from Microsoft Safe Links, not INKY.
If the user sees an INKY page, review INKY link rewriting or URL analysis.
If the user sees a browser warning, review browser protection, endpoint security, or the destination website reputation.
Step 7: Decide which action fits the problem
Use the table below to decide what to review or change.
| Problem | Recommended area to review |
| Future emails from a trusted sender are being flagged | Sender or domain allow list |
| One already-delivered message is incorrectly classified | Message reporting / false-positive process |
| A trusted sender’s links are blocked | URL/link behavior, not only sender allow |
| A specific URL or domain should not be rewritten in future mail | Link rewriting exceptions |
| Message is held in Microsoft quarantine | Microsoft 365 Defender quarantine |
| Link is blocked by Microsoft Safe Links | Microsoft Safe Links policy or allow process |
| Message appears to come from a customer’s own domain but is sent through a third-party platform | Trusted Third-Party Sender configuration |
| Sender is allowed but still flagged | Allow category, allow level, DMARC setting, and actual sending domain |
Common examples
Example 1: Sender is allowed, but the link is still blocked
A partner allows vendor.com, but users still cannot click a link in the email.
Possible reasons:
- The sender allow applies to message classification, not URL access.
- The link domain is different from the sender domain.
- The link is rewritten and blocked by INKY.
- The link is blocked by Microsoft Safe Links.
- The link is blocked by browser or endpoint security.
- The message was already delivered before the allow was created.
Review the URL, block page, and link rewriting behavior.
Example 2: Message was reported safe, but future emails are still flagged
A user reports one message as safe, but later messages from the same sender are still flagged.
Possible reasons:
- The report only affected the original message or user.
- The threat category requires an admin-level allow.
- The allow was not created at the customer/team level.
- The sender fails DMARC and the allow requires DMARC pass.
- The visible From domain is different from the actual sending domain.
Review the threat category, allow scope, and DMARC setting.
Example 3: Message is released from quarantine, but future messages are quarantined again
A message is released from Microsoft 365 quarantine, but new messages from the same sender continue to be quarantined.
Possible reasons:
- Releasing a message only releases that one message.
- Microsoft 365 policy is still quarantining future messages.
- INKY or another tool is still adding classification signals.
- Sender authentication is still failing.
- A future allow or policy adjustment may be needed.
Review Microsoft quarantine reason, message trace, INKY classification, and sender authentication.
Information to gather before contacting support
If you still need help, 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, if present
- Screenshot of the link block page, if the issue is a blocked link
- The rewritten URL or destination domain, if safe to share
- Screenshot of the allow list entry, if one exists
- Whether the allow was created for sender, domain, message, URL, or link domain
- Whether the allow entry requires DMARC pass
- Full message headers or EML, if available
- Microsoft 365 Message Trace or Google Workspace Email Log Search result, if available
- Whether Microsoft Safe Links or another URL protection tool is enabled