Troubleshooting: Entry Edited but Message Is Still Flagged
If you edit an Allow List entry and the message is still being flagged, review the items below.
Confirm the result type is correct
The result type cannot be changed when editing an entry. If the entry was created for the wrong result type, delete it and recreate it with the correct result type.
Example:
- An entry for Spam may not suppress a Phishing warning.
- An entry for First-Time Sender may not suppress a Brand Impersonation warning.
- An entry for one warning type may not apply to a different INKY classification.
- In some cases, multiple entries for the same specific email may be required to bypass more than one type of warning.
To confirm the correct result type, open the affected message in Observations or the Custom Dashboard and compare the message warning/result type to the Allow List entry.
Review the DMARC authentication requirement
Some Allow List entries include a DMARC authentication requirement. If this option is enabled, the entry only matches messages that pass DMARC authentication.
This is the safer option because it helps prevent spoofed messages from matching an allow entry. However, legitimate senders may fail DMARC when they send through third-party platforms, automated systems, or vendor services.
Examples may include:
- SendGrid
- Mailchimp
- Constant Contact
- Intuit
- Autotask
- CRM systems
- Billing platforms
- Marketing platforms
- Ticketing platforms
- Other automated notification systems
If the sender fails DMARC and the Allow List entry requires DMARC authentication, the message may continue to be flagged even though the sender, domain, or subdomain appears on the Allow List.
Before disabling the DMARC authentication requirement, review the risk. Disabling it may allow more messages to match the entry, but it can also reduce protection against spoofed mail.
Confirm the visible sender matches the actual sending service
The visible From address may not always match the service that actually sent the message.
For example:
- Visible From address: billing@trustedvendor.com
- Actual sending platform: SendGrid, Mailchimp, Constant Contact, or another third-party service
If the visible sender or 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 was sent by a third-party platform, a Trusted Third-Party Sender entry may be more appropriate than changing a standard Allow List entry.
Confirm whether subdomain matching is needed
If the entry is for a domain, confirm whether subdomain matching is needed.
Example:
- Existing entry: trustedvendor.com
- Message sender or link domain: mail.trustedvendor.com or secure.mail.trustedvendor.com
If subdomain matching is not enabled, the entry may not match subdomains as expected.
Before enabling broader subdomain matching, confirm that the parent domain and subdomains are trusted.
Confirm user-specific targeting
If the entry was converted to a user-level entry, it applies only to the user listed on the entry.
Review user-specific targeting if:
- Only one user should be affected.
- Multiple users are still seeing the warning.
- The entry was previously team-level and was converted to user-level.
- The affected user is different from the user listed on the entry.
If multiple users need the entry to apply, review whether a team-level or organization-level entry is more appropriate.
Confirm when the message was received
Allow List changes may not update messages that were already processed before the entry was created or edited.
If the affected message was received before the edit was saved, send a new test message after editing the entry to confirm whether future messages match.
Confirm the issue is not a blocked link
A sender or domain Allow List entry may not unblock links inside the email.
If the message is delivered but the user cannot click a link, review link rewriting, and URL behavior separately. The issue may be caused by INKY link rewriting, Microsoft Safe Links, browser protection, endpoint security, or another URL security tool.