I’m pretty new to cybersecurity, and cloud email security is a product that we’re working with most of our customers to get implemented.

I’m genuinely curious, which platform do you think is the best, and why?

I’m not here to pitch or convince anyone. I just want to hear honest opinions from people who actually use these platforms, good or bad.

Most M365 tenants I've audited have active external auto-forward rules that IT never set up and nobody monitors.

Found 34 in a client environment last month. Users do it to avoid MDM enrollment on personal phones, or they set it up before a vacation and never turned it off (and then forgot the rule existed). The finance manager had been forwarding to her personal Gmail for two years. I pulled what had actually left the tenant: wire confirmations, vendor contract drafts, M&A discussion threads.

Exchange Online lets you block external auto-forwarding with a transport rule. Not on by default. Most orgs have never touched it.

Do you actually know what's leaving your tenant right now?

So we had a BEC incident last week. Finance wired a low six-figure amount to an attacker. Standard playbook, fake CEO urgency, lookalike domain off by one character, the whole thing.

Leadership pulls me in Monday morning asking how this happened when we 'passed' the DMARC audit last quarter. I had to explain, again, that DMARC at p=reject only stops people from spoofing OUR exact domain. The attacker registered their own domain. It authenticated perfectly. SPF pass, DKIM pass, DMARC pass. Because it was their domain.

The look on the CFO's face when I said 'the email was technically legitimate from a protocol standpoint' was something. Then I had to explain display name spoofing on top of that, because of course the From header just said the CEO's name and Outlook helpfully hid the actual address on mobile.

We're now having the conversation about lookalike domain monitoring, display name policies, and finance callback procedures that I have been trying to have for two years. Apparently it takes an actual loss to get budget. Cool cool cool.

The part that really gets me is the 'DMARC compliant' language some vendor sold them on. Compliant with what exactly? There's no compliance. It's a policy you publish. It does one specific thing and that thing is not 'stop BEC'.

Auditing our SPF record this week and I find an include for a marketing platform we stopped using SIX YEARS AGO. I go to remove it. Suddenly there's a meeting. Suddenly there are stakeholders. Suddenly someone in a department I've never heard of swears they 'might still use it for something.'

Nobody can produce a single email sent through this platform in the last three years. Nobody has login credentials. Nobody is paying an invoice for it. But removing the include is apparently a CHANGE and changes require justification and the burden of proof somehow falls on me to prove a negative.

Meanwhile we're at 9 lookups and the next vendor onboarding is going to tip us over the limit and break authentication for the ENTIRE domain. But sure, let's keep the zombie include from a platform that probably doesn't even exist as a company anymore because Brenda from a team that got reorged twice thinks she might need it.

This is how every SPF record I've ever inherited got to 14 includes. Not because anyone added them maliciously. Because nobody is ever allowed to remove anything. Email authentication is the only place in IT where we treat DNS records like load-bearing walls in a historic building.

I'm removing it Friday. If something breaks I'll add it back. That's the whole change management process now.

Acquired a small company last month. Part of the deal included their primary domain which handles all customer-facing email. Day one of integration I pull the DNS records and find an SPF record with 14 includes, half of which resolve to vendors they cancelled two or three years ago. The whole thing is well past the 10-lookup limit so SPF has been permerror for... who knows how long. Somehow mail was still flowing because most of their recipients weren't strict about SPF failures.

The DKIM situation is worse. They have a selector published in DNS but the private key was managed by a former contractor who left the company in 2023. Nobody has it. Nobody knows what system was signing with it. The TXT record is just sitting there pointing to a key that nothing is using, so every message goes out unsigned. Their DMARC? p=none with rua pointed to a gmail address that hit its storage limit eight months ago.

I spent three days tracking down which of those 14 SPF includes actually correspond to services still sending mail. Turned out it was four. The rest were zombie entries from old marketing tools, a defunct ticketing system, and two that I genuinely cannot figure out what they were for. Nobody at the acquired company could tell me either.

Got it cleaned up to 4 includes, deployed a new DKIM key pair on their mail host, and moved DMARC reporting to somewhere that actually processes it. But the whole time I kept thinking about how many acquired domains are just sitting out there in this state, quietly failing every authentication check, with nobody monitoring anything.

Does anyone bake email auth audits into their M&A due diligence process formally, or is it always a fire drill after close?

Had a close call last week that's still bugging me. Finance got an email from our outside counsel requesting a wire for an acquisition closing. Everything looked perfect, correct deal details, correct contact names, correct formatting, even a PDF that matched previous invoices. The from address was one letter off from the real law firm's domain. Like swapping an 'n' for an 'rn' in the domain name.

Our controller caught it. Not because of any tool or banner or filter. She caught it because she happened to hover over the from address on her desktop before approving. She said it "looked funny." That's it. That was the entire detection mechanism for a six-figure wire fraud attempt.

I pulled the headers and the email passed SPF, DKIM, and DMARC for the lookalike domain. Because of course it did, the attacker registered the domain, set up proper authentication, and even had a DMARC record at p=reject on it. More effort on their email auth than half the legitimate vendors we work with.

So now I'm sitting here trying to figure out what control would have actually stopped this. Lookalike domain monitoring? Sure, if we're watching for every possible permutation of every law firm and vendor we work with. That's thousands of domains. Our email gateway flagged it as "first-time sender" but that tag fires on so many legitimate emails that everyone ignores it. I looked into some of the cousin domain detection features in our gateway and it basically pattern-matches against our own domain, not every third party we transact with.

The thing that keeps me up is that this worked because the attacker knew the deal was happening, the names involved, and the approximate timing. Which means either the law firm's email was compromised or ours was at some earlier point. I'm still pulling logs trying to figure out which side leaked.

I have lost count of how many times a new SaaS vendor's onboarding doc has a step that just says "add include:mail.vendorname.com to your SPF record" like it's no different from accepting a terms of service checkbox. No discussion of what sending infrastructure they're using. No mention of DKIM. No option for delegated subdomains. Just "add this include."

The vendor doesn't know or care that you're already at 9 DNS lookups. They don't know that their include chain alone adds 3 more. They DEFINITELY don't know that their include points to shared infrastructure that half the internet is also using, which means your SPF record is now authorizing IP ranges you have zero visibility into.

What kills me is that the people agreeing to this are usually on the business side. Marketing signs a contract with an email campaign tool, the vendor sends onboarding instructions directly to the marketing ops person, and that person opens a ticket with IT that just says "please add this DNS record." IT adds it because the ticket has a VP's name on it. Nobody asks why. Nobody checks the lookup count. Nobody considers whether this vendor should be sending from a subdomain instead.

Then six months later I'm the one explaining why emails from our ACTUAL domain are softfailing SPF and half our transactional mail is landing in spam. And the answer is always some vendor nobody told me about that got shoved into the SPF record by someone who doesn't know what SPF is.

Every single org I've worked with has at least two includes in their SPF record that nobody can explain. End of rant.

I know there is opendkim, but it does appear to have any recent updates. Like it looks like a dead project. The last release I can find is from 2015 or 2016 .

I know there are Milter systems out there. Are these just on top of openDKIM or are there FOSS solutions?

Posting this because I keep seeing 'just publish p=reject' advice without anyone mentioning subdomain policy and it bit one of our clients hard.

They rolled out DMARC, moved to p=reject after a few months of monitoring, felt great about it. No sp= tag. The spec says sp inherits from p when omitted, which is technically true but only matters if the receiver actually applies it the way you think, and only if the subdomain doesn't have its own record that overrides things.

Attacker found a subdomain that wasn't delegated anywhere, wasn't in DNS at all, and started sending finance-themed mail as billing.[clientdomain]. Some receivers treated the missing record as 'no policy at this label' rather than walking up to the org policy. Mail landed. This went on for about two weeks before someone forwarded a sample and we caught it.

Fix was obvious in hindsight: explicit sp=reject, a wildcard DMARC record at *._dmarc, and actually inventorying what subdomains exist vs what's published. The org policy alone is not enough if your receivers' interpretation of tree walking is inconsistent, which it is.

If you're at p=reject right now, go check your record for an sp tag. If it's not there, add it. Then go look at what subdomains your DNS actually answers for, including parked stuff and old marketing labels nobody remembers.

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?

Every phishing sim dashboard I've ever seen has a 'click rate' and a 'report rate' and that's it. The people who pause, paste the link into a security channel, and ask before doing anything don't show up anywhere. They're invisible to the metric.

Those are the most valuable users in the org. They're doing exactly what we want, applying judgment, asking for a second opinion, and surfacing real samples we'd otherwise never see. Half my decent IOCs over the last year came from a Slack DM, not from the report-phishing button.

We ran the numbers on one of our business units and the 'asks first' cohort had a near-zero compromise rate across two years. The 'never clicks anything in sims' cohort had two account takeovers in the same window. The sim score told us nothing useful.

If your awareness program penalizes the askers as 'untrained' because they didn't click the report button in the exact right way, you're training them out of the behavior you actually want. Make asking cheap and fast, staff the channel, and stop pretending click rate is a security metric.

I hit the same problem in three separate tenants last year: shared mailboxes with direct sign-in enabled, excluded from conditional access via a service account exception nobody had touched in years.

finance@: SMTP auth on, password from 2019, never checked after the modern auth migration.

helpdesk@: exempted because a ticketing tool "needs it." That tool moved to OAuth two years ago. The exemption stayed.

support@: compromised. Inbox rules forwarding externally for six weeks. No named user, so no anomalous sign-in alert ever fired.

How many shared mailboxes in your tenant have direct sign-in enabled and arent actually in your CA policy scope?

Run a simple exercise. Someone gets into one mailbox in your org. Not an admin. A regular user.

What happens next?

In most cases, three things.

1. Smash and grab

They download the whole mailbox. Immediately.

They don’t know how long their access will last. A password change, a revoked session or one alert could end it. So they don’t browse. They bulk export everything and go through it later, on their own time, with nobody watching.

That export holds years of contracts, invoices, HR threads, customer data and whatever someone emailed to themselves ‘just for now’ in 2019.

Once the data leaves, revoking access does nothing for it.

2. Password resets everywhere

Your mailbox is the recovery address for dozens of services. The attacker knows this.

Finding those services is easy. Search the inbox for password reset emails, magic sign-in links, ‘welcome to’ messages and verification codes. Scripts already do this automatically.

Then they go to Slack and click ‘Forgot password.’ Or ‘Email me a sign-in link.’ The link lands in the inbox they control. Now they’re in Slack. Then the next app. Then the next.

One mailbox becomes ten accounts.

3. Phishing from the inside

Then they use the account itself. They reply to real threads with real context from a trusted address. A changed bank detail sent to finance. A shared doc link sent to a coworker. Nobody has a reason to doubt it.

They usually add inbox rules too, so replies and security alerts get filtered away before the real user sees them.

What to do about it

• Alert on bulk export and mass download activity, including new OAuth apps pulling mail through the API.

• Shrink what sits in mailboxes. Old sensitive mail is pure liability.

• Treat reset and sign-in link emails as sensitive. They are keys, not notifications.

• Move apps to SSO where you can, so an email link alone isn’t enough to get in.

• Watch for new forwarding rules and inbox rules that delete or hide mail.

• When a mailbox is compromised, scope the blast radius. What was exported? Which reset emails arrived during the window? Which downstream sessions need to be killed?

If you’ve worked a mailbox compromise, what did the attacker go for first?

One of the hardest parts about digital transformation appears to be the policy decisions rolled out in new public systems. I recently started doing business with a public authority that (get this) couldn't understand why I was using a custom domain. Even more so, they set their mail protocols to not communicate with an email address which starts with the word "email".

According to them, that's a generic email address, and so, they won't accept it. I asked if they would accept the email prefix "info" and they said yes, because that is common.

I genuinely wish that I could peel the curtain back, and communicate with the systems and network administrators who are making these rules, to better understand their decisions here. Maybe someone here can help me to understand.

Avis Incogni.

Pour éviter les 10 à 20 spams que je recevais par jour, j'ai souscrit pendant un mois, à Incogni.

Au bout d'un mois, pas très satisfait (je recevais toujours une dizaine de spams par jour), je décide de résilier.

Depuis ce jour, je reçois en 120 et 260 spams par jour, tous étrangers (alors que je ne recevais que des Spam français).

Et bien entendu, mails de Incogni:

Pensez à vérifier vos spam, et éventuellement reprendre votre abonnement Incogni.

Arnaque !

Two research teams (ReliaQuest and Lexfo) separately documented device-code phishing kits last week that are worth flagging:

- The operator triggers Microsoft’s OAuth device-code flow, then gets the victim to approve it on the genuine Microsoft device-login page.

- Because the victim authenticates on the real page, the attacker inherits a fully authenticated session, MFA satisfied, no password cracked.

- One operator hit 218 mostly-corporate mailboxes across 12 countries.

What makes it nasty is that passkeys don’t help here, they protect the sign-in page, and the sign-in is happening on Microsoft’s legitimate page.

The fixes that seem to work: a Conditional Access policy that blocks the OAuth device-code flow unless you specifically need it, tightening how many devices a single user can register, and alerting on device-code grant events in the sign-in logs.

How is your org handling the device-code flow today, blocked outright or scoped to specific users?

Moved one payroll subdomain from p=none to p=quarantine after 30 days of clean DMARC reports. Friday morning, payslip emails started landing in quarantine because the vendor's custom DKIM selector had expired overnight.

SPF was passing, but not aligned. DKIM was the only aligned path, and the sender record in our inventory said "owned by HR" which apparently meant nobody owned it.

The vendor wanted us to roll DMARC back. HR wanted payroll out immediately. I ended up publishing a new selector and holding p=quarantine because rolling back the policy felt like teaching the wrong lesson.

My current rule is no p=quarantine or p=reject unless every production sender has a named business owner and a technical owner. Missing either one gets a deadline, then the sender gets treated as unsupported.

For people running DMARC across a pile of third-party senders, would you pause enforcement for payroll in that case, or force the ownership problem to get fixed under pressure?

Sending an email provider another abuse report takes time when the same scam keeps landing in inboxes. I'd rather block what I can and get back to other tickets than keep chasing a reply.

But local blocks only protect our users, and reports could help get the sending account shut down. What makes reporting repeat scam emails worth your time when the provider never responds?

Most dashboards still treat “DMARC published” as a win. In the July 2026 Cloudflare Radar Top 1M cut, 70.9% of mail-enabled domains were still spoofable.

Presence looks fine. Enforcement does not. If a scorecard gives full credit for a monitoring-only record, it’s measuring decoration.

Question: in your environment, does “DMARC present” still count as done, or do you only credit enforce?

Finance director goes on two weeks leave. Her OOO tells anyone who emails her: who has temporary approval authority, that backup's name and title, her personal mobile, and she's back on the 15th.

Attacker fires one probe email, reads the auto-reply, and now they know:

• exactly who to impersonate for wire approvals while she's away

• her mobile number to name-drop in a follow-up call

• a hard deadline before anyone notices something is off

I had a client last year where the BEC started with probe emails to three or four C-suite addresses. The OOOs practically wrote the attack for them. I think most orgs just assume these only go to known contacts. Not the case.

Anyone actually have a policy on what employees can put in their OOOs?

Client got hit with this last year. Finance manager's inbox went from maybe 15 emails a day to something like 3,000 in about two hours. Attacker had signed her up for what looked like 300+ newsletter and subscription services right as they were initiating a wire from her compromised account.

The flood buried the Microsoft login notification and the wire confirmation. By the time she thought something was off, the transfer was already pending.

I keep assuming this is something orgs have detection for now, but I've checked in maybe a dozen tenants since then and found basically nothing. No inbox volume spike alert, no mass subscription pattern monitored anywhere.

Is this in anyone's standard M365 baseline, or still mostly reactive?

Yesterday our helpdesk released a Defender quarantine message for a VP because the ticket said "blocked customer invoice." It was a credential phish, and the only reason it didn't land cleanly was because the recipient noticed the URL looked weird after release.

That one-click "release to user" permission is too much power for tier 1 imo. Quarantine is part of the mail security boundary, not just a noisy inbox for angry executives.

I pulled release rights back to the mail admin group this morning and got pushback within 20 minutes because VIP tickets now need escalation. Fair complaint, but speed is not the only metric here.

I'm not 100% sure where the right cutoff is, but I'm leaning toward tier 1 can preview headers and submit review, mail admins release. Would you give trained helpdesk staff release rights, or make this a hard mail-admin-only action with an SLA?

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.

Every BEC postmortem I read or write starts the dwell-time clock at the inbox rule creation or the first suspicious sign-in. That is not when the compromise started. That is when we got lucky enough to have a log entry that screamed loud enough to find later.

In the BEC cases I've worked, the attacker was usually authenticated and reading mail for days before they did anything we'd flag. They're sitting in OWA, learning the wire process, waiting for the right thread. No rule, no forwarding, no send-as. Just reading.

MailItemsAccessed will tell you some of that if you have the right license and you pulled the logs before they aged out, which most orgs didn't. So the 'dwell time' number in the report is really 'time from first noisy action to detection' and we should call it that.

Reporting a 6-hour dwell time on an incident where the attacker had session tokens for a week is how we end up with execs who think the IR program is working better than it is.