If an Allowed Sender or Domain Is Still Flagged
If a sender, domain, or subdomain is still being flagged after it was added to the Allow List, review the items below before creating additional allow entries.
Confirm the result type matches the INKY warning
Allow List entries suppress specific INKY warnings. If the entry was created for one result type, it may not suppress a different warning type.
Example:
- An allow entry for Spam Content may not suppress a Phishing Content warning.
- An allow entry for First-Time Sender may not suppress Brand Impersonation.
- If you want an allow list entry for two types of banners you will have to add two separate allowlist entries .
- A sender/domain allow may not resolve a blocked or rewritten link.
Open the message in Observations or the Custom Dashboard and confirm the warning/result type shown on the message matches the result type selected on the Allow List entry.
Confirm the entry is matching the actual sender
The visible From address may not always match the system or domain that actually sent the message. This is common when trusted vendors use third-party platforms for billing, marketing, ticketing, or notifications.
Examples of third-party sending platforms may include SendGrid, Mailchimp, Constant Contact, Intuit, Autotask, CRM systems, billing systems, marketing tools, or ticketing platforms.
If the visible From domain was allowed but the message is still flagged, review the message headers or EML to confirm:
- Header From
- Envelope sender or Return-Path
- SPF result
- DKIM result
- DMARC result
- Actual sending service or platform
If the message appears to come from your own domain but is sent by a third-party platform, a Trusted Third-Party Sender entry may be more appropriate than a standard Allow List entry.
Review the DMARC authentication option
If DMARC authentication is enabled on the Allow List entry, the entry only matches when the sender passes DMARC.
This is the safer option and helps prevent spoofed messages from matching your allow list. However, some legitimate third-party or automated senders may fail DMARC alignment. If the sender fails DMARC and the allow entry requires DMARC pass, the message may continue to be flagged even though the sender or domain appears on the Allow List.
Before disabling DMARC authentication, review the risk. Disabling this requirement may allow more messages to match the entry, but it can also reduce protection against spoofed mail.
Confirm the entry was created at the correct level
Make sure the Allow List entry applies to the affected user, team, customer, or organization.
If only one user is affected, a user-level allow may be enough. If multiple users are affected, review whether the allow should be created at the team/customer or organization level.
For MSP-managed customers, confirm that the entry was created in the correct customer or team context.
Confirm the message was received after the entry was created
Allow List changes may not update messages that were already processed before the entry was created.
If the message was received before the Allow List entry was added or edited, send a new test message after the change to confirm whether future messages match the entry.
Confirm another system is not taking the final action
INKY may not be the system taking the final action on the message.
Check whether the message is:
- Delivered to the Inbox with an INKY banner
- Delivered to Junk
- Held in Microsoft 365 quarantine
- Held in Google Workspace quarantine
- Held in INKY quarantine
- Rejected before delivery
- Delivered, but blocked only when clicking a link
If Microsoft 365, Google Workspace, Microsoft Safe Links, browser security, endpoint protection, or another security tool is blocking the message, additional review may be needed in that system.