Why an Allowlisted Sender or Domain Is Still Flagged by INKY

Overview

This article explains why an email may still be flagged by INKY after a sender, domain, subdomain, message, or URL has been added to an allow list.

In most cases, this does not mean the allow list is broken. It usually means the allow entry does not match the exact reason INKY classified the message, the allow was created at the wrong level, the sender failed authentication requirements, the message was processed before the allow was created, or another security service is taking the final blocking action.

Use this article if you are seeing behavior such as:

• A sender or domain was allowlisted, but the email still shows as phishing, malicious, suspicious, or spam.
• A user reported a message as safe, but the INKY banner did not clear.
• A vendor or customer email is still being flagged after being allowlisted.
• A message is still going to Junk or quarantine after an allow was added.
• A user can receive the message but still cannot click a link inside it.

Step 1: Check the INKY threat category

The first thing to confirm is the exact threat category shown on the INKY banner or in the INKY dashboard.

The threat category matters because allow list behavior is category specific. An allow created for one category may not apply to a message flagged under another category.

For example:

• An allow for Spam Content may not resolve a message flagged as Phishing Content.
• A personal allow may not resolve a team-level or admin-level classification.
• Reporting a message as safe may not clear every type of INKY classification.
• A sender allow may not resolve a blocked or rewritten URL.

Common INKY categories may include:

• Spam Content
• Graymail
• Phishing Content
• Sensitive Content
• Brand Impersonation
• Spoofed VIP
• Spoofed Internal Sender
• Possibly Misconfigured Service

Before changing any settings, check the banner or dashboard details and confirm the exact category.

Step 2: Confirm what was allowlisted

“Allowlisted” can mean several different things. Confirm exactly what was added.

Common allow types include:

• Sender address
• Sender domain
• Subdomain
• URL or link domain
• Message reported as safe from the INKY banner
• Personal/user-level allow
• Customer/team-level allow
• Organization-level allow

A few examples:

• If the sender was allowlisted, that may not unblock a URL inside the email.
• If the visible From domain was allowlisted, that may not match the actual sending domain.
• If the allow was created at the personal/user level, it may not apply to other users.
• If the message was flagged as phishing, sensitive content, brand impersonation, or spoofed VIP, user-level reporting may not be enough.
• If the allow was created for the wrong category, it may not match the classification on the message.

Step 3: Confirm where the allow was created

Allow list entries may apply at different levels depending on how your INKY environment is configured.

Common levels include:

• Personal/user level
• Customer or team level
• Organization level
• Global level

For MSP-managed customers, make sure the allow was created in the correct customer or team context. An allow created for one customer or team may not apply to another.

If only one user is affected, a personal allow may be appropriate. If multiple users are affected, review whether the allow should be created at the customer/team level instead.

Step 4: Make sure the allow matches the threat category

INKY allow entries are tied to classification behavior. If the allow entry does not match the category shown on the message, the message may continue to be flagged.

Examples:

Step 5: Check the DMARC setting on the allow entry

Some allow entries include this option:

Apply only to messages that pass DMARC authentication

If this option is enabled and the sender fails DMARC authentication, the allow entry may not match. This is a common reason an allowlisted sender or domain continues to be flagged.

This often happens with mail sent through third-party services such as:

• SendGrid
• Mailchimp
• Constant Contact
• Intuit
• Autotask
• CRM systems
• Billing systems
• Marketing platforms
• Ticketing platforms
• Other automated vendor mail systems

These services may send on behalf of a domain, but the message may not pass DMARC alignment for that domain.

Before changing this setting, review the risk. Requiring DMARC pass is safer because it helps prevent spoofed messages from matching the allow entry. Disabling the requirement may allow more messages to match, but it can also reduce protection against spoofing.

[Insert screenshot: 

Step 6: Compare the visible From domain to the actual sending domain

The sender shown in the email client is not always the same as the domain that actually sent the message.

For example:

• Visible From address: billing@vendor.com
• Actual sending service: SendGrid, Mailchimp, Constant Contact, or another platform

If only the visible from domain was allowlisted, the allow may not match the actual sending path or authentication results.

To verify the actual sender, review the message headers or EML file and check:

• Header From
• Envelope sender or Return-Path
• Sending IP address
• SPF result
• DKIM result
• DMARC result
• Third-party sending service indicators

If the message appears to come from your own domain but was sent by a third-party service, review whether a Trusted Third-Party Sender entry is needed instead of a standard allow list entry.

Step 7: Confirm when the allow was created

Many allow list changes to apply to future messages.

If the message was already processed before the allow entry was created, the original email may still show the previous INKY classification.

To test whether the allow is working, send a new message after the allow entry is created or updated.

If the issue is with a link inside an already-delivered email, a sender or domain allow may not change that already-delivered message. Link behavior is handled separately.

Step 8: Confirm whether another security system is blocking the message

INKY may not be the system taking the final action.

A message may be classified or bannered by INKY, but still be moved, quarantined, blocked, or rewritten by another service.

Check whether the message is affected by:

• Microsoft Defender
• Microsoft Safe Links
• Microsoft 365 quarantine
• Google Workspace quarantine
• Google routing or compliance rules
• Browser security
• Endpoint security
• Another email security product

Review where the message is currently located:

• Inbox with an INKY banner
• Junk
• Microsoft quarantine
• Google quarantine
• INKY quarantine
• Blocked only when clicking a link
• Rejected before delivery

If the message is in Microsoft 365 quarantine, release and allow actions may need to be performed in Microsoft 365 Defender.

If the message is in Google Workspace quarantine or rejected by a Google routing rule, review the Google Admin console and Email Log Search.

If the user can receive the message but cannot click a link, review link rewriting and URL to allow behavior.

Step 9: If the issue is a blocked link, review URL/link behavior

A sender or domain allow does not always unblock links inside a message.

If the email was delivered but the user cannot open a link, check:

• Is the block page from INKY, Microsoft Safe Links, the browser, or another tool?
• Is the link rewritten by INKY?
• Was the sender/domain allowed, or was the URL/domain allowed?
• Was the message already delivered before the allow was created?
• Is this a red/Danger banner or gray/Caution banner?

For link-specific issues, use the article for rewritten links or URL exceptions.

Common causes

Information to gather before contacting support

If the message is still flagged after reviewing the items above, gather one affected example before contacting support.

Include:

• Customer or team name
• Sender address
• Recipient address
• Subject line
• Date and time received, including time zone
• Screenshot of the INKY banner showing the threat category
• Screenshot of the allow list entry
• Whether the allow was created at the user, team/customer, organization, or global level
• Whether “Apply only to messages that pass DMARC authentication” is enabled
• Full message headers or EML, if available
• Microsoft 365 message trace or Google Workspace Email Log Search result, if available
• Current message location: Inbox, Junk, Microsoft quarantine, Google quarantine, INKY quarantine, or blocked link page