The three usual culprits: INKY's own anti-spam scoring, Microsoft quarantining independently, and malicious-link/anti-phish policies (the latter tends to be DMARC-related).

• "Quarantined by transport rule" → This was INKY. One of our delivery rules fired based on our SCL banner result and the customer's delivery settings (a transport rule set the SCL to 8/9/10, which maps to quarantine per the customer's config).
• "Quarantined by anti-spam policy" → Ambiguous by design. Microsoft always lists the first policy on the tenant's list as "the" cause, regardless of which one actually matched — and INKY's policy is usually listed first. In practice this almost always means Microsoft quarantined it themselves, before the mail ever reached INKY.
  • Anti-spam policies are just a mapping ("if mail scores X, do Y") — a policy could send everything to inbox or everything to quarantine regardless of score, and it would still just show up as "anti-spam policy."

Rule of thumb: transport rule → it's us. Anti-spam policy → assume Microsoft, then verify.

How to verify: check the INKY dashboard's quarantine view — it explicitly shows "quarantined by INKY" vs "quarantined by Microsoft" (before ever reaching INKY), plus release status and sender/recipient filters. It's built from a Microsoft Graph API call, so it's easier to read than Microsoft's own quarantine UI. It's our best-guess analysis — notably more accurate recently, but still technically inferred. When unsure, transport-rule attribution is the reliable signal.

• To / From / Subject
• Original sender DKIM signature (intact)
• Received headers (server-to-server hop path)
• Authentication-Results — the first real pass/fail signal: SPF pass + IP, DKIM evaluation, DMARC evaluation plus the customer's configured DMARC action (none, quarantine, or reject), and Comp Auth — Microsoft's own composite determination layered on top of SPF/DKIM/DMARC.

A post-INKY header will typically show SPF/DKIM "fail" — INKY breaks the original DKIM signature by adding a banner — but Comp Auth should still show "pass." Reason code 130 = Microsoft's compound-auth code for "passed via ARC."

For the full mechanics of how SPF, DKIM, and DMARC are actually calculated — not just how they show up here — see the next three topics.

What it is: a DNS TXT record at the root of the sending domain, listing the hosts/IPs authorized to send mail as that domain. "As that domain" specifically means the domain in the visible From header — not the envelope-from, which can differ.

Example from session: merckconstruction.com

• v=spf1 at the start marks it as an SPF v1 record.
• An include: statement means "pull in everything defined in that other record" — each include counts as one DNS lookup, no matter how many IPs it ultimately resolves to.
• A clean, simple record might be nothing but include:spf.protection.outlook.com — meaning only Microsoft's published ranges are authorized senders for that domain.
• Ends in either -all (hard fail — unmatched senders are a failure) or ~all (soft fail — unmatched senders are a soft failure, not an outright reject). Most receiving systems mostly ignore this in isolation when a DMARC record is present, since DMARC's policy supersedes it.

• SPF allows a maximum of 10 DNS lookups — a hard limit, no exceptions. This is the single most common reason a record shows up invalid/red in MX Toolbox.
• Every include: = 1 lookup, regardless of how many IPs it returns. INKY's own exist: record is the same — 1 lookup no matter how many IPs it contains.
• Lookups nest: an include can point to a record that itself contains more includes, and all of those count toward the same ceiling. Example from session: inky.com's record has 6 top-level lookups, and one of those (an Amazon-related include) nests a 7th lookup inside it.
• Diagnostic approach when a record is red for "too many lookups": open the base record in MX Toolbox, count the top-level lookups, then open each include in turn and check whether it nests further. Watch especially for duplicates — two different includes that both resolve to the same nested record. include:salesforce.com is a common offender: it resolves to a record containing nothing but another lookup — pure overhead, no IPs of its own.

• It has no effect on inbound mail — inbound mail never carries the customer's own domain as the authenticated sender, since it's coming from outside their organization.
• Why add it anyway: it keeps outbound headers clean of any visible SPF/DKIM failure. (1) Internal mail routed back out through INKY doesn't get a fresh Microsoft ARC seal on that hop — without INKY in SPF, a customer opening their own internal mail's headers could see a cosmetic fail that alarms admins even though nothing's wrong. (2) It's belt-and-suspenders against non-standards-based recipient systems (Topic 7) that reject on any "fail" string appearing anywhere in the headers, rather than validating only the most recent hop as the standard requires.

What it is: public-key cryptography (the same mechanism behind SSL/TLS certificates), used to create a checksum of the email so the recipient can confirm it wasn't altered in transit. Where SPF verifies the sending server, DKIM verifies the message content — an anti-man-in-the-middle mechanism.

Why INKY mail always shows a DKIM fail on the original signature: adding a banner changes the message body, so it no longer matches the original checksum. Expected — this is exactly why ARC (Topic 6) exists, to carry the original pass-state forward for Microsoft to trust.

• v= — version
• a= — algorithm, e.g. rsa-sha256
• c= — canonicalization type, almost always relaxed (tolerant of minor in-transit header reformatting; strict would break on nearly any hop)
• d= — the signing domain
• s= — the selector: the name of the DNS record that holds the public key
• h= — the headers included in the signature calculation (From, Date, Subject, Message-ID, Content-Type, MIME-Version, etc.)
• bh= — the body hash, calculated separately
• b= — the actual signature value, calculated from the listed headers + body hash using the sender's private key

Looking up a DKIM public key in MX Toolbox: run a DKIM lookup formatted as selector:domain (e.g., selector2:bpa.ca) — under the hood this just queries <selector>._domainkey.<domain> as a TXT record. MX Toolbox decodes it and confirms validity.

Why there are usually two selectors (commonly selector1/selector2, though the name is arbitrary): key rotation. Mail goes out signed under one selector while the other selector's DNS record is updated to a new key and given time to propagate; once propagated, signing switches over, freeing the first one to be rotated next. Keys rotate periodically without ever risking a mail going out signed by a key that isn't published yet.

What it's for: SPF and DKIM only report pass/fail — neither tells the recipient what to do about a failure. DMARC is the sender's published instruction set for exactly that, via a p= (policy) tag with three levels:

• p=none — take no special action on a DMARC failure; deliver as normal. Often used deliberately by senders who know their SPF/DKIM isn't fully locked down yet.
• p=quarantine — quarantine (don't reject) mail that fails DMARC — leaves room for the sender to vouch for a message and have it released.
• p=reject — reject/NDR mail that fails DMARC outright.

The alignment requirement — this is where most confusion comes from: a DMARC pass requires SPF or DKIM to align with the domain in the visible From header the end user sees — not the envelope-from, and not just whatever domain SPF/DKIM happen to validate against on their own.

Concrete example of a DMARC fail despite SPF and DKIM both passing: a marketing mail sent via SendGrid, addressed as From: joe@bpa.com. DKIM passes for sendgrid.com. SPF passes for sendgrid.com. DMARC still fails, because neither aligns with the visible From domain, bpa.com. This is exactly the pattern behind an INKY "spoofed internal sender" red banner: the metadata tab shows a DKIM pass / SPF pass for the actual sending service, but a DMARC fail because the customer hasn't aligned that service with their own domain.

• The fix, when the sending service is legitimate: add the service's sending IPs to the domain's SPF record, and ideally add a CNAME record pointing to the key the service uses to sign DKIM — full alignment, not just an SPF pass riding along.

Reminder for customer conversations: SPF/DKIM/DMARC passing only proves the message came from where it claims to have come from — it makes no guarantee about the legitimacy of the sender or the safety of the content. Increasingly sophisticated phishing uses a properly configured, legitimately registered lookalike domain that passes all three checks cleanly. That's exactly why INKY layers additional checks (like newly-registered-domain detection) on top of authentication instead of relying on it alone.

What it's for: preserving original authentication results when a mail is legitimately modified in transit (e.g., INKY adding a banner) — tells the recipient "trust the original results, not what you'd calculate now."

• ARC seal = a 3-part signature, added by each trusted intermediary that handles the mail.
• Includes INKY's domain (inkyfishfence.com), a selector, a body+header hash, and the preserved authentication results to trust.
• Public-key cryptography, same model as DKIM — INKY signs with a private key; the recipient validates with our public ARC key in DNS.
• Each handler adds its own seal (i=1, i=2, i=3…) on the way out — ARC forms a chain and, per spec, cannot be broken and restarted.
• Recipients validate backward from the highest i to i=1; if the whole chain validates, they trust the final preserved results.
• INKY is listed as a trusted ARC sealer in customer configs, so Microsoft trusts our seal.

• Outbound mail through multiple non-ARC-aware systems. Example: O365 → INKY (seal 2) → Microsoft (transport rules, seal 3) → a signature tool like Exclaimer that doesn't sign ARC but does modify the body → back to Microsoft → the next seal (4) fails because the intermediate hop wasn't sealed.
• Downstream ARC-aware systems (e.g., Zix) will decline to add their own seal once they see a broken chain — they'll still deliver normally, just without re-signing ARC.

Does a broken chain cause delivery problems? In theory, no — ARC is proof-of-custody inside a system, not something the recipient is meant to evaluate directly. In practice, some non-standard recipient systems don't follow spec and may still react to a fail.

Symptom: customer sends fine to most destinations, but one specific partner/domain rejects or bounces.

Spec-compliant behavior: the recipient should walk backward through Received headers from the top until it finds the first aligned DKIM pass, and treat that as sufficient for DMARC — regardless of what appears further down (e.g., an earlier broken signature).

What some home-grown gateways actually do: regex the raw headers for "DKIM fail" anywhere in the mail and reject on that match, even when a later valid signature exists.

The Aug 27 SPF/DKIM/DMARC deep dive confirmed the mechanism from the spec side: the standard says a recipient validating DMARC should start at the top of the headers (the most recent hop) and work backward only until it finds a passing SPF or DKIM result for the sending domain — it isn't supposed to keep auditing every hop behind that. Non-standards-based systems that instead regex-scan the entire header block for "fail" are the ones that break this. See Topic 3's note on adding INKY to the customer's SPF record — the direct mitigation for this exact failure mode on outbound mail.

• Check the recipient domain's MX record in MX Toolbox. Not Microsoft or Google → likely a private/on-prem server, a common source of non-standard handling.
• Look up who operates the MX — some are standards-following services (Proofpoint/Mimecast-type), others are ad hoc.
• Get the customer/partner to send you a test message directly; confirm DKIM/SPF/INKY processing all look correct.
• If our end checks out but delivery still fails to that one destination, the customer needs to contact that recipient — usually (a) they need an allowlist/config change, or (b) the sender has actually been flagged as spam there (more common than expected — be ready for a tough MSP conversation).

Yahoo and other providers (rolled out roughly 2024) require both SPF and DKIM to pass and be aligned — not just DMARC-via-SPF-alone. Even if SPF passes and DMARC technically passes on that basis, a broken/misaligned DKIM can still get the mail rejected by Yahoo/AOL/Hotmail-style providers.

If a customer reports mail failing specifically to personal Yahoo/AOL addresses (not domains they control), get a test message sent the same failing way and check whether DKIM is passing — that's usually the thread to pull.

• Symptom: mail passes SPF (so DMARC technically passes) but fails DKIM — and strict destinations like Yahoo/Gmail reject it because they want both aligned, not just one.
• Root cause: the customer has a Google-side disclaimer/footer rule in addition to INKY's signature service (or mail routes through Google Groups). Google signs DKIM, mail goes out, comes back through INKY, returns to Google — and Google re-adds its disclaimer a second time, after DKIM was already signed, breaking DKIM.
• Diagnostic tell: open the actual mail body (not just headers) and look for two identical disclaimers stacked — the signature of this failure mode.
• Fix: turn off the Google-side disclaimer entirely, use INKY's disclaimer field instead, and retest.

• When a user sends via a third-party client (Outlook, Thunderbird — not Gmail web/app) over authenticated IMAP/SMTP, Google Workspace does not treat the app/server IP as the sending IP. It stamps the user's personal client IP as the SPF-relevant sender, even though they authenticated normally.
• This almost always fails SPF, and can lead Google to skip signing DKIM entirely for that message, since the IP isn't in the trusted gateway range.
• There's an existing INKY KB article (Google section) on this — fix is generally identifying the client's IP (ideally static) and adding it to the customer's inbound gateway allowlist, same as INKY's own sending IPs.
• Isolation test: ask the customer to resend the same test via Gmail's web client. Different behavior confirms the third-party-client theory.

If a customer reports display/formatting issues (broken images, weird layout) specifically in Outlook, ask:

• What Outlook version — especially old vs. "new Outlook"? Microsoft changed the rendering engine, so behavior can differ purely by client version, unrelated to INKY.
• Does it render correctly in OWA (web access)? If yes, the issue is isolated to the desktop client's rendering engine.

Legitimate mail shouldn't rely solely on Outlook's proprietary conditional formatting — if a message renders poorly in INKY's quarantine preview (standard HTML rendering) because it used only Outlook-specific formatting, that's a poorly-formed message, not an INKY rendering bug.

Coming down the header block after a mail passes through INKY and O365, in order:

• Message-ID — one of the most valuable fields for troubleshooting/lookup.
• Group membership flags (e.g., whether the recipient is in a group that could trigger a banner).
• X-Microsoft-Antispam (Untrusted) — Microsoft's original analysis from before the mail reached INKY, preserved and marked "untrusted" (not necessarily bad — just "this was the earlier pass").
• INKY's own SCL score and disposition (e.g., SCL 10 → quarantine).
• Microsoft's Forefront Antispam Report headers — connecting IP, calculated SCL, category code (e.g., "H" = high confidence spam), directionality, and various undocumented internal codes.
  • Microsoft doesn't publish what most of these codes mean. Some are reverse-engineered by the community — no official list exists. Category and SCL are the most reliably useful fields.

SCL → Microsoft delivery mapping: INKY's O365 transport rules (the first four "delivery rules") read our X-INKY-SCL header and set Microsoft's own SCL accordingly, walking through tiers roughly: quarantine → high-confidence phish → high-confidence spam → spam → inbox. That SCL then combines with the tenant's anti-spam policy to determine final placement.

• MX Toolbox — roughly 3/4 of Peter's troubleshooting starts here. Use it to check the recipient/sender domain's MX record (Microsoft, Google, or private?), SPF record validity, and DMARC record/policy.
  • A large share of "why is mail being rejected" cases trace back to the other party having a broken or missing SPF/DKIM/DMARC setup — not an INKY issue. Real example: a partner domain ("Brandle Construction") had no SPF record, broken/unsigned DKIM, but did have a DMARC record — that combination alone explained a customer's quarantine complaints. Sender-side problem, not INKY's.
• Google search for MX ownership — identify who operates a given mail server hostname and whether it's a standards-compliant provider.
• Get a live test sample — when troubleshooting stalls, ask the customer or failing partner to send a test message directly to you, so you're reading real headers instead of secondhand NDR text.

• Counting SPF lookups: open the domain's base SPF record, count top-level include: statements, then open each one and check whether it nests further lookups — all nested lookups count toward the same 10-lookup ceiling. Watch for duplicate nested records (two different includes resolving to the same underlying lookup) as the usual culprit when a record is unexpectedly over the limit.
• DKIM lookups: query a DKIM public key directly with selector:domain (e.g., selector2:bpa.ca) to pull and validate the DNS TXT record — useful when a customer disputes whether their DKIM is actually configured correctly.

The INKY dashboard's Metadata / Observations tab shows what INKY calculated when it first received the mail from Microsoft/Google — origin (external vs. internal), and SPF/DKIM/DMARC pass/fail against the visible From domain. Usually the fastest first stop for a customer complaint:

• If SPF/DKIM/DMARC all show pass but the mail still got a red banner or looked suspicious, remember authentication only proves sender identity, not legitimacy — see Topic 5's phishing note.
• If SPF shows none, that's the cue to go check the sending domain's SPF record directly — commonly it's either missing entirely or invalid because it exceeds the 10-lookup limit (see the SPF counting technique above).

What it's for: catching "subscription bomb" / subscription attacks — where an attacker signs a target up for a flood of newsletters and confirmation emails (semi-legitimate sources, real unsubscribe links, so it doesn't look like classic spam). Two motives seen in practice: pure annoyance, or — more insidious — burying a phishing message in the flood so a fatigued user stops scrutinizing incoming mail closely.

• Burst interval — the sliding time window considered for a burst. Default 300 seconds (5 minutes).
• Message threshold — how many messages within that window trigger burst mode. This is the setting to tune carefully: too low and normal traffic trips it; too high and it won't catch a real attack.
• Burst cache duration — how long burst mode stays active after triggering, before reverting to normal. Default 300 seconds (5 minutes).

Recommendation: don't enable this in a customer's first couple of weeks unless there's already a good understanding of their normal mail volume — a large customer with an unfamiliar traffic pattern is the main risk case for false positives. Small teams/MSPs with few users are generally safe to enable early, and can often run tighter thresholds.

• Sender ignore list — exclude specific senders from burst counting entirely (e.g., a monitoring tool like Datadog that can legitimately fire a burst of alert emails during an incident). Messages from an ignored sender are delivered normally during a burst and don't count toward the threshold calculation at all.
• Recipient ignore list — the reverse: exclude a specific mailbox that naturally receives high volume (e.g., a shared support/ticketing inbox) from burst detection, so you don't have to raise the threshold for the whole organization just to accommodate one high-traffic mailbox.

What happens during a burst: messages get marked according to the configured action — default is spam (routed to junk), but can instead be set to caution non-spam (yellow "suspicious burst detected" banner) or high confidence spam. Delivery then follows the normal routing rules for whatever classification was chosen, unless overridden to force a specific location (e.g., force junk folder regardless of classification, so the user can go check it once things calm down).

Defaults worth knowing: burst detection ignores internal senders, trusted third-party senders, and known-external senders by default (recommended to leave this on) — mail from anyone already vetted in the dashboard keeps flowing normally even during an active burst.

Real example from session: an MSP complained a customer's mailbox "got flooded" — 2,000 messages arrived in ~25 minutes. Their threshold was 100 messages/5 minutes. What actually happened: the first 100 messages delivered normally, then burst mode kicked in and the remaining ~1,900 went to junk for the ~25–30 minute burst window — the user never saw the flood in their inbox. The Observations tab in the dashboard was how this was confirmed.

Pairs with Gray Mail protection: in that same example, gray mail detection was on (default: caution non-spam), but the customer hadn't set up the actual gray mail rules (create a gray mail folder + auto-move matching messages) — so of the first 100 delivered messages, 90 were tagged gray mail but still landed in the inbox since nothing moved them out. Had the move-rule been configured, the user would only have seen about 10 extra messages total instead of 100. Recommended combo when troubleshooting a subscription-attack complaint: check burst detection settings first, then check whether gray mail detection and the folder-move rule are both actually configured — used together they nearly eliminate the visible impact of a subscription attack.

What it's for: detecting a compromised account by watching for abnormal outbound sending bursts — newer than inbound burst detection, still being actively refined by the product team.

• Threshold — works exactly like inbound burst detection: a fixed interval (default 300s, though the session's example used 360s) plus a fixed recipient-count threshold (session example: 10 recipients within the interval) plus a cooldown period.
• Adaptive — builds a per-sender baseline of normal recipient-sending behavior over a sliding window, and triggers when a specific user significantly exceeds their own normal pattern. Includes a configurable minimum message-count floor (session example: 20 messages/5 minutes) so low-volume users aren't hyper-sensitively flagged the moment they send anything unusual.
• Threshold + Adaptive (recommended default) — additive: whichever condition trips first fires the burst. Tuning tip: keep the threshold relatively high in this combined mode, so it doesn't clash with legitimate high-volume senders (e.g., a sales team's Salesforce-to-O365 integration that legitimately blasts 100 recipients at a scheduled time) — let adaptive mode do the fine-grained per-user work instead.

Exceptions (in progress): rule-based exclusions are being refined — e.g., "don't count bursts from payroll@example.com" for a sender that legitimately blasts the whole company biweekly and would otherwise trip adaptive mode every pay cycle. Planned future refinement: using INKY's API access to identify a customer's actual mailing lists and automatically exclude mail sent to those lists from burst counting.

• Low risk — admins get notified only; mail delivery is unaffected.
• Medium risk — the account's mail is quarantined.
• High risk — the account's mail is discarded outright.

Notifications: who gets notified is defined by the customer's Outbound Protection rules, specifically the ATO enforcement group (falls back to the tenant's default admin/approval group if no dedicated ATO enforcement group is configured). Notified approvers can approve, reject, or release the affected user directly from the notification email — they do not need to be an INKY admin to do this.

Threat Center: shows the full event log for Outbound Protection triggers (ATO bursts, dangerous links, etc.) — subject, recipient, risk level, and the resulting status (e.g., "delivered because approved"). Viewing and acting in the Threat Center itself (beyond just the notification email) requires Policy Admin or higher — an Analyst-level user can see it but can't take action.

Outbound Protection also scans for dangerous links and spam/phishing indicators in outbound mail, independent of burst detection. Both support the same ignore-list pattern as burst detection (specific senders/addresses that should be excluded from that particular scan) — configured per-scanner in the Outbound Protection settings.

Symptom: partners get a "could not be configured" error, or a user-account error, when trying to set up the AutoTask integration.

Root cause (the overwhelming majority of cases): the AutoTask integration must be configured at the root organization level, by a user who is an admin at the root level — not at the "dash customer" (individual customer) level, and not by a user with only an Analyst role. Most failures trace back to someone attempting setup from the wrong org level or without sufficient permissions there.

Status: the product team is aware this is confusing and is working on UI improvements — e.g., redirecting users away from the integration screen when they're in a dash-customer org, with clearer messaging that it must be done at the root level.

• The organization ID is unique, auto-provisioned (pulled directly from Kaseya/Salesforce during account creation), and permanently fixed once set — it cannot be changed, even if the team/license is deleted and recreated from scratch. Once an ID string (e.g., "customer1") has been used, it's retired for good — a recreated license would need a different ID.
• The organization label (display name), by contrast, can be changed anytime — e.g., after a customer rename or merger — with no restriction.
• You can search the org selector by either label or ID; searching by ID is more reliable since it's guaranteed unique (labels can be ambiguous or visually truncated — see Topic 16's diagnostic trap).
• If a Kaseya One org ID was provisioned incorrectly, it can be manually overridden/corrected in the dashboard — that's a distinct action from the permanent-uniqueness rule above (correcting a wrong ID is fine; reusing a retired ID is not possible).
• Mental model Peter used: think of the ID like a serial number or GUID — a fixed internal identity, not a friendly editable label.