Confirming INKY actually processed a message: look for message trace hops and headers such as X-Rerouted-To-Inky and X-IPW-Processed. If those indicators are present, INKY was in the path.

If a rule fired but INKY indicators are absent: the problem is upstream of INKY. Check inbound connectors, disabled rules, custom rule order, and third-party routing before assuming INKY is involved at all.

Attributing a failure after INKY finished: if INKY completed processing cleanly and Exchange then fails during mailbox delivery, treat Microsoft as the likely owner of the issue, not INKY. Week 1's examples included ticket EX1464935 and poison-message errors.

• Don't change INKY-created connectors without evidence that the connector configuration itself is wrong.
• Different "From" values can be normal: the metadata Mail From is the envelope sender, while the visible From is the header sender. A mismatch can also indicate spoofing — don't assume either way without checking.
• If a third-party system sends as the customer's own users or domains, working authentication for that traffic matters. If it instead sends from its own domain, Known External Sender may be the more appropriate classification.

Bulk Safe Senders: no supported CSV or bulk-import workflow currently exists — this came up with a request for roughly 1,000 Safe Senders at once. Manual paste may work as a workaround; otherwise, submit a feature request for a real bulk-import path.

Allow-list and link-rewrite changes are not retroactive: they don't cause previously delivered mail to be reprocessed. A confirmed Safe report can still affect click-time protection going forward, but it won't reach back and change what already landed.

Classic Outlook flagging grammar in the banner: traced to Microsoft Editor (Classic Outlook's newer grammar engine) evaluating the banner and quoted text as if it were the user's own writing, rather than skipping it.

• Have recipients report questionable messages through the banner — reviewing the reported variations is how detection actually improves over time.
• Allow lists can suppress detections outright. If a suspicious message comes back with a weaker verdict than expected, review existing allow rules before looking anywhere else.
• Link Rewrite Exceptions only affect in-flight mail — they can't "un-rewrite" a link that was already delivered, and subdomains may need their own explicit entries.
• Learning Mode does not remove the banner. What it actually does is suppress the First Time Sender warning specifically — worth clarifying with customers who expect it to turn banners off entirely.

Compromised internal senders: treat as an account-takeover scenario. Reset the account, strengthen MFA, enable ATO (Account Takeover) detection where appropriate, and make sure affected messages get reported through the banner so the sample feeds back into detection.

Known gap — "Potential Fake Conversation": this detection did not trigger on a fabricated invoice thread in week 1. It remains an open Engineering/Product review item and a possible real detection gap, not just a one-off miss.

• For a new simulation provider, report several sample messages and include raw data so engineering can determine the provider's identifying signals — one sample usually isn't enough to build a reliable pattern.
• A recognized phishing simulation should not be blocked by Link Protection. If it is, capture the exact Observation URL and verify settings at the time of analysis — don't assume it's expected behavior.
• Whether a provider can get a reusable, standing exception depends on whether its identification is consistent across customers; tenant-specific IPs or on-prem appliances may need custom, per-tenant setup instead.

KaseyaOne identity-provider login errors: resolved in several cases in week 1 simply by clearing cached authentication data and retesting — worth trying before escalating.

Partner IDs are permanent: they're fixed internal identifiers and cannot be renamed once provisioned. (Consistent with how INKY org IDs work more broadly — see the SMTP field guide's Kaseya One topic.)

.onmicrosoft.com license failures: can trace back to missing MX records, incomplete Exchange Online setup, or simply a new tenant that's still propagating. Don't assume the license itself is broken before checking those three.

Releasing inactive-team domains: can be done after validation, so the domain can then be onboarded to the correct team cleanly.

• Team IDs cannot be reused or edited once provisioned; the team name, by contrast, remains customizable at any time.
• When moving a domain off an inactive team: confirm the domain has actually been removed in Microsoft first, then release it from the old INKY team before onboarding it elsewhere — order matters here.
• For a fully defunct team, the preferred approach is the partner's built-in self-service reset/offboarding flow, with backend cleanup only when needed on top of that.
• A newly verified domain may still be missing Exchange service setup, or may simply still be propagating — don't treat either as a failure yet.

Autotask mappings that save and then revert: should be escalated for development review. Confirmed in week 1: the integration itself does not determine the destination queue, so a reverting mapping points to a bug, not a config mistake.

Bullhorn false positives: require checking authentication, source/origin, auto-forwarding behavior, and the INKY result together — no single field tells the whole story.

INKY Setup & Maintenance app permissions: needs elevated access during initial setup. If a customer's security team raises audit questions about this, point them to the documented enterprise-app purpose and the approved post-setup permission guidance rather than improvising an answer.

• Did the message actually traverse INKY?
• Are connectors and transport rules enabled and ordered correctly?
• Did Microsoft fail after INKY returned the message?
• Is the behavior future-only, rather than retroactive?
• Is this documentation, configuration, a backend action, product behavior, or a potential bug?

What to capture for fast triage, every time: the exact tenant/team, message ID or Observation URL, trace, authentication results, screenshots, and the raw sample. Having these ready up front is what turns a slow back-and-forth into a same-day answer.

Escalation package — what L2/engineering will ask for: ticket summary, tenant/team, exact symptom, expected vs. actual behavior, timestamps, message ID, Observation URL, trace, screenshots, raw message, and the steps already completed. See also the Escalation Evidence Checklist under "Before You Post" above.

• For detection or analysis issues, get a reported message or the specific Observation URL before doing anything else — it makes the investigation materially faster than working from a description alone.
• Ask for the exact INKY team, time period, and message ID before concluding whether encryption, routing, or analysis was actually involved.
• Use Microsoft message trace to determine where a failure happened: before INKY, during INKY processing, or after Microsoft accepted the message. This single check resolves most "whose fault is it" questions.

• Document troubleshooting and evidence in the ticket before requesting an L2 or engineering swarm — see the Start Here format above.
• A partner request alone does not guarantee an immediate L2 call. Set expectations with the partner and route follow-up through the original ticket.
• When Microsoft trace shows INKY completed processing and Microsoft failed at delivery, avoid presenting the issue to the customer as an INKY outage without further evidence — that framing is usually wrong and hard to walk back.