u/shokzee

Workspace will happily send outbound mail through your gateway, but Gmail does not magically make that relay part of your domain's authentication story. The next hop still has to pass SPF or DKIM in a way that lines up with DMARC.

The common failure is SPF alignment. Workspace hands mail to the relay, the relay rewrites MAIL FROM to its own bounce domain, and now your From: domain has no aligned SPF pass unless DKIM survives.

DKIM is usually the cleaner path. Sign in Workspace before the relay, then make sure the relay does not break the body or headers you signed. If it adds footers, rewrites links, or mangles MIME, expect DMARC failures.

For gateways in front of Workspace, I treat this as a mail flow test, not an admin checkbox. Send to a mailbox you can inspect, read the Authentication-Results header, and verify alignment from the final receiver's point of view.

OWA XSS bugs are ugly because the blast radius is mailbox access, not just a browser pop-up. If you still publish Exchange directly, tighten exposure and watch auth/OWA logs until there’s a fix.

https://www.darkreading.com/vulnerabilities-threats/microsoft-exchange-zero-day-no-patch

Found this during a mail-flow cleanup, not during an alert. An old Exchange Online transport rule set SCL -1 for one supplier domain because invoices kept hitting quarantine in 2021.

Last week that supplier got compromised and a threaded invoice reply delivered a malicious ISO into three AP mailboxes. Message trace made the ugly part obvious: the allow rule hit before Defender for Office had done anything useful.

I am done with domain-level allow lists in Exchange transport rules. If a supplier cannot send clean mail, they get scoped remediation or quarantine release, not a permanent bypass stapled to mail flow.

Customer forwarded a phish to abuse@ with all the right headers. SPF, DKIM, and DMARC passed because it came from a still-active Mailchimp account tied to our domain.

The account belonged to someone who left nine months ago. Marketing had killed the obvious access, but the external sender login was still alive.

The annoying part is abuse@ caught it before any internal control did. Our offboarding list had laptops, IdP, GitHub, payroll, all the usual stuff. It did not have bulk email platforms that can still send authenticated mail as us.

If a service can send as your domain, it needs an owner and a shutdown path. Otherwise abuse@ becomes your asset inventory, which is a stupid way to run email security.

> detect and contain entire phishing campaigns instead of responding to individual emails.

https://cofense.com/blog/vision-ai-phishing-remediation

This is where remediation has to go, because chasing single reported messages after users see them is already too late.