u/littleko

Had an M365 mailbox compromise this week where I was about ten minutes from calling email containment done. Password reset, MFA re-registered, sessions revoked, inbox rules checked, message trace reviewed, phishing cleanup done.

Then I checked consented apps because one sign-in trail still felt weird (not 100% sure I would have done this a year ago). The user had approved some sketchy PDF app with Graph Mail.Read and offline_access, and it was still pulling messages after the password reset.

That was the uncomfortable part. I was treating the credential as the incident, but email access had moved to an OAuth grant.

We removed the grant and started scoping with MailItemsAccessed, but I’m still annoyed at how close I got to closing it early. For people doing M365 mailbox IR regularly, is OAuth consent review mandatory for every compromised mailbox in your runbook, or only when the logs point that way?

A credential phish hit our shared ops@ inbox this week and one of the on-call folks treated it as less suspicious because it was in the shared queue. Same RFC5322 From, same link domain, same gateway verdict, but it felt like "company mail" because it was sitting next to real vendor tickets.

The annoying part is they probably would have reported it immediately if it landed in their own mailbox. Once it became a ticket, the mental model changed from "is this email legit?" to "is this ticket assigned to me?"

I'm not 100% sure if this is awareness training failing or the shared inbox UI laundering trust. Do you make users report suspicious mail from shared mailboxes the same way as personal inboxes, or do you treat those queues as needing a separate review step before anyone opens links?

support dropped a blocklist report in our abuse@ queue this morning with a HELO name nobody recognized and a bounce domain that existed for exactly one campaign.

The customer was real, the mail was bulk, and the complaint was probably fair. The annoying part was spending 40 minutes mapping mta-17-usw2-new and a one-off Return-Path domain back to the tenant that actually sent it.

I get why people rotate sending pools and bounce domains for campaign separation. But if every campaign invents new identifiers, abuse triage turns into archaeology and support starts guessing, which is how the wrong customer gets blamed or nothing gets paused.

I'm not 100% sure where to set the rule here. Would you require stable HELO or bounce-domain patterns before letting a bulk sender keep going, or is this just something abuse tooling should be expected to normalize?

A PM got a webinar sender approved in Slack 30 minutes before a campaign, then asked for SPF and DKIM records on the main company domain. The pushback I got was basically "it's just TXT records," which is exactly the problem.

SPF, DKIM, MX, and DMARC changes are production mail path changes. One bad include, stale selector, or vendor sending unauthenticated can mess with deliverability, reporting, and domain reputation way outside that one webinar.

I'm not saying every marketing sender needs a three-week CAB ritual. But at minimum I want a ticket, owner, sender purpose, DNS diff, rollback plan, and proof the vendor can sign aligned DKIM before anything touches the company domain.

Would you block the launch until that exists, or let it ship if the blast is time-sensitive and DKIM passes in a quick test?

Quarterly domain review turned up 7 old campaign mail subdomains still delegated to ESP accounts nobody on marketing owns anymore. Two had valid SPF/DKIM paths and one still had DMARC at p=none, all for campaigns that ended last year.

The annoying part is these were not "unknown" domains. They were approved once, used for a launch, then the business owner left and the offboarding process never touched DNS delegation.

I'm leaning toward putting an expiry date on every vendor mail delegation now, maybe 90 days unless someone re-attests it. Slight risk of breaking some forgotten nurture campaign, but leaving abandoned senders authenticated under our domain feels worse.

Would you kill the delegations after one missed review cycle, or give marketing/product a grace period to prove the sender is still owned?

An app team pinged me this week because a customer said our emails were “failing authentication.” Postfix only had a 550 5.7.1 back, and the human text after it changed depending on the receiver: SPF-looking wording in one case, spam policy in another, and one that read like relay denial.

I get that enhanced status codes leave room for local policy, but 5.7.1 feels almost too overloaded in practice. If I’m parsing DSNs for triage, the code alone is basically useless, and the text is not stable enough to trust without pattern matching receiver by receiver.

For people running mail ops at any real volume, what do you key off first when 5.7.1 shows up: the enhanced code, the SMTP text, prior receiver history, or do you just punt it into a manual queue until someone reads the headers/logs?

One of our support folks flagged a weird batch of DMARC failures from alumni forwarding addresses last week. Mail left our app clean, hit an alumni forwarder, then showed up at Gmail looking broken enough that the first instinct was to blame our DKIM setup.

SPF was dead because forwarding did forwarding things. DKIM was inconsistent because one path touched the body, but Gmail still had an ARC chain with the earlier auth results sealed in, so it didn't treat the whole thing like obvious spoofing.

I know ARC is not magic and I'm not 100% sure I love depending on receiver-specific trust decisions. But in this case it turned a messy indirect mail path into something debuggable instead of a false alarm and a pointless fight with the alumni mail admin.

For people running real domains at enforcement, do you treat ARC-passing forwarded mail as acceptable evidence when reviewing DMARC failures, or do you still make the forwarder fix the underlying break before you stop caring?

Emails seem to be legit, called customer support to let them know that I didn't initiate the change. The rep has confirmed that a lot of customers are receiving these emails, all within the past couple of hours. Do we know that it's not a security breach or a bot hammering their password reset endpoint and genuinely is a system error?

A phishing email made it through to two execs this week with the original URL still visible, which was not supposed to happen. Everyone assumed the Defender Safe Links policy covered the whole executive group because the group was in scope in the portal.

Message trace told a messier story. A 2021 transport rule for a vendor allow-list was stamping SCL -1 on mail to the old exec alias before delivery, and that path was skipping the policy behavior we expected.

The annoying part is the rule was technically doing what someone asked for years ago. It was created to stop false positives for calendar/invoice mail, then the alias got reused for actual executive distribution.

I'm leaning toward killing the SCL bypass entirely and replacing it with narrower allow entries, but the pushback is already starting because "exec mail can't get delayed." Where do you draw the line on old mail-flow bypass rules: hard expiration date, owner required, or delete on sight unless someone can prove the risk is worth it?

A product manager asked why an old acquisition domain still showed up in a SaaS login audit, and the weird part was email reset attempts were not bouncing. I checked DNS and the domain parking provider had published wildcard MX records pointing at their own mail infrastructure.

I had been treating "parked" as basically inert DNS. Bad assumption. If the domain exists, has MX, and has weak or missing DMARC, it is still part of your email risk surface.

My current cleanup order is pretty simple: dig mx domain.tld, check for wildcard subdomain MX, then check SPF/DMARC before calling a domain retired. For domains that should never send or receive mail, I'm leaning toward null MX plus SPF -all and DMARC p=reject; sp=reject.

The annoying tradeoff is some parking vendors make this harder than it should be, and business owners often want to keep domains parked for brand reasons. Would you force null MX on every retired domain, or allow parked MX if nobody can prove active mail use?

Support noticed password reset emails landing 90 minutes late, then the app team pulled me into Slack asking if SPF was broken again. SPF, DKIM, and DMARC were all passing. The vendor relay was just sitting on about 20k deferred messages and retrying like nothing was on fire.

The annoying part is that auth was the loudest theory because it is the only email thing most people can name. Meanwhile the useful evidence was in the boring stuff: DSNs, queue age, 421/4.7.x responses, and which receiving domains were slowing us down.

I'm not 100% sure where the clean handoff should be here. Do you treat a vendor relay queue like their outage until proven otherwise, or set your own deadline before routing around them?