2.0 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| reference-inky-outbound-breaks-dmarc | INKY/GuruProtect outbound re-injection breaks DMARC alignment; reverse-resolve DMARC report source IPs before attributing failures |
|
When analyzing DMARC aggregate (rua) reports, reverse-resolve every failing source IP before attributing a failure to a sender. Multiple ACG client failures (glaztech.com p=reject, cryoweave.com p=quarantine) traced not to the apps/websites first assumed, but to INKY (GuruProtect) outbound: PTRs ipw-outbound.inkyphishfence.com and us.cloud-sec-av.com (AWS IP pools 3.x / 34.210.x / 35.174.x / 100.2x.x).
Mechanism: INKY receives an already-signed message (M365 selector1 or cPanel default DKIM), modifies the body (GuruProtect banner / link rewrite), then re-sends from its own IPs. Body change breaks the original DKIM; INKY IPs aren't in the domain's SPF → SPF fails too → DMARC fails. So a domain can be 99% aligned and still show a steady trickle of INKY-origin fails.
INKY topology (per Mike, 2026-06-23): INKY is installed directly into M365 via connectors + transport rules per enrolled tenant — NOT an external-only relay. So check tenant enrollment. NOTE: cryoweave M365 is NOT enrolled in INKY, yet cryoweave.com mail still appeared from INKY outbound IPs — that traffic is the IX/cPanel website (WordPress, envelope=ix.azcomputerguru.com, cPanel default DKIM) whose hosting-level outbound routes through INKY, independent of the M365 tenant. Don't assume "INKY fail" == "tenant on INKY."
Fix is INKY-side, not DNS-blind: republishing cPanel DKIM or adding the web server to SPF will NOT fix it (INKY breaks the sig downstream and the mail comes from INKY's IP, not the web server's). Real options: enable INKY outbound DKIM signing per domain, add INKY's SPF include, or ARC — or route low-volume app/website mail through an authenticated M365 SMTP path so it aligns directly. See feedback-dmarc-rua-inky-onboarded-only.