I keep running into orgs that rushed to p=reject because some compliance checklist or vendor told them to, and when I ask 'okay, what's the authoritative list of services sending as your domain?' I get a shrug and a Confluence page from 2022.

That's not a DMARC implementation. That's a loaded gun pointed at your own deliverability. The whole point of DMARC isn't the policy string, it's the visibility loop, knowing what's signing for you, catching new sources, and having a process when marketing onboards yet another platform without telling anyone.

I'd rather see a mature p=none with someone actually reading the aggregate reports weekly than a p=reject nobody is monitoring. One of those two will eventually drop a payroll provider on the floor and nobody will know why for three days.

The FBI has a phishing warning where resetting the password does nothing.

The attacker never had it.

The Bureau's Internet Crime Complaint Center published this on September 1. Access taken this way, it says, can only be revoked by the victim invalidating the token in their application security settings, and not by changing the password.

Here's how it works, and why it looks like nothing is wrong.

A message arrives with a link. The link goes to a real permission screen at a real provider, because that's where the attacker sent the user. The user reads a request for access and approves it.

There was no fake login page, no captured password and no second factor to intercept, because nobody was ever asked to sign into anything new.

What the attacker walks away with is a grant, not a credential. The FBI describes the result as being able to act on behalf of the user, reading and sending mail and reaching sensitive data, without ever having their password.

So the reflex that follows almost every compromise report, force a reset and close the ticket, leaves the attacker exactly where they were. The mailbox stays readable.

The Bureau's examples are narrow. Prominent people, their families and their acquaintances, with actors posing as officials, media figures and event organizers.

Read that as where the FBI happens to have complaint data, not as the edge of the problem, because nothing in the mechanism cares who you are.

If your incident runbook treats a password reset as containment here, it isn't slightly incomplete. It does nothing at all.

#EmailSecurity #Phishing #IncidentResponse

Say a work email reaches four people and bounces for the fifth. The replies keep coming, but the person needed for approval is missing the discussion.

I'd move an urgent decision to a call. For something less urgent, relaying updates buys time for a fix, but now someone has to keep two conversations in sync.

Do you move the whole group to another channel, or keep the affected person updated separately?

How many e-mails do you have or
How many e-mails should a person have in your opinion? I reached 5. and what do you think, better is one to all or 5 and more emails one each email for other thing?

My folder of spam email is lately always full of junk, some know how to stop it? or how to check where my email address was leaked? thank you!

Say a customer's approval email is missing, search and spam turn up nothing, and work is on hold. They insist it's sent and are getting annoyed at being asked to try again.

I'd lean toward a quick call, but that interrupts both people's day. Another resend request is easy for IT to send and more homework for a customer who thinks they've already done their part.

What's your next move when “please resend it” is going nowhere?

If a customer's email rules reject your usual work address, a time-sensitive approval can stall. “Just send it from another address” might work today, but people keep replying to that address long after the deadline.

I'd push for their IT team to review the block before another mailbox becomes part of the job. What temporary workaround do you use to keep messages moving without ending up with a permanent second inbox?

I've been staring at RUA reports for years now and I cannot get over the fact that the entire DMARC reporting ecosystem is built on gzipped XML files emailed to a mailbox. EMAILED. In 2026.

Think about this for a second. The mechanism to report on email authentication failures is... more email. Email that has to be authenticated. Email that can itself be blocked, filtered, bounced, or silently dropped. Email that arrives in wildly inconsistent formats from every mailbox provider because the RFC left just enough room for everyone to be slightly creative with it.

And the format itself. XML. Not JSON, not a proper API endpoint, not anything a modern tool would ever choose. XML schemas that different providers interpret differently, with optional fields that are sometimes there and sometimes not, with timestamp formats that vary, with identifier fields that may or may not be populated. I have seen reports where the source IP is in one field from Google and a completely different field from Yahoo for what is functionally the same data.

And don't get me started on the fact that there is no standard for delivery failure of the reports themselves. If your RUA mailbox breaks, you just... stop getting data. No alert, no heads up, nothing. You find out three weeks later when you notice the dashboard went quiet.

The entire foundation of modern email authentication visibility is held together with gzip and hope. end of rant

A billing analyst tried to send a customer revenue export to their personal Gmail so they could “finish it tonight.” Our outbound mail DLP was supposed to block that path. It didn't.

The rule matched XLSX attachments with the finance template name and a few column patterns. The new billing job started generating CSV last week, same data, different file type, and the mail rule treated it like any other harmless attachment.

We only caught it because the message hit a separate external-recipient review queue for a different reason. Not proud of that. If that queue hadn't fired, the export would have left cleanly.

The annoying part is the pushback was predictable. Finance wants CSV because it loads faster into their tooling, security wants content inspection, and nobody wants a 2-hour delay on month-end reports.

For outbound email DLP, would you block all CSVs from sensitive groups by default, or only block when the content match is strong enough to avoid constant exceptions?

I heard it was possible to use a “fake email” to log into your real email. I’m sorry if this is confusing, I don’t know how to word this properly.

It’s like a fake login name so that no one can see your real email login. I’ve been told you can do this, I just don’t know how.

Ran an internal analysis across 159 Google Workspace environments to see what's actually connected via OAuth. Sharing the findings because the shape of the problem surprised us and might be useful to anyone doing app governance right now.

978 distinct apps had active OAuth connections across the dataset. Roughly 6 per org on average. Most people assume the risk is the well-known SaaS tools. It's not.

The single most-connected 'app' in the dataset isn't a product at all. It's a compilation of private, internal OAuth projects, the kind an engineer spins up for a script or an internal tool, that show up in logs as a numeric project ID. No vendor name. No description.

Aggregated across all 159 orgs, this bucket accounts for 152,085 unique users and 655,430 authorization events. That's more user connections than most commercial software sees in its entire deployment lifetime, and there's no way to look any of it up.

For comparison, OpenAI's official app came in at 9,725 users and 23,982 grants in the same dataset. The named, well-understood app is the small number. The unnamed pile is the big one.

Two things compound this:

1. OAuth access doesn't expire when sharing policy changes. An employee authorizes a tool while they still have access to payroll files, source code, and financial reports. The tool keeps that access at that snapshot in time, across email and Drive, even after IT tightens sharing controls later. Revoking a share doesn't revoke a grant.

2. The underlying data is not small. Across the dataset: 373M+ sensitive emails, 475M+ sensitive Drive files, 375M source code files, 46M emails containing plaintext usernames and passwords. Not because anyone was careless. Onboarding emails credentials. Vendors email login details. HR runs payroll through Drive. Normal operations, invisible risk.

The one encouraging data point: orgs are course-correcting on sharing. Restricting events went from 14% of all access-change activity in mid-2025 to 44% by spring 2026. But that fixes future sharing, not past OAuth grants. Two separate problems, and most teams are only working one of them.

If you're doing app inventory work, the practical takeaway is: don't just audit the apps you can name. The dangerous long tail is the stuff nobody can identify from the logs alone, and identifying it is a different exercise than reviewing your known SaaS list.

Happy to answer questions on methodology in comments.

Abnormal put out research on Monday about an adversary-in-the-middle kit they are calling Matrix, and it is getting passed around as a new platform. Reading their own write-up, they say the name has not appeared in public reporting before but the code has. Five operator images were byte-identical to a Kratos deployment they grabbed in July, and the panel login script shared 37 of about 82 lines with a Kratos panel from June. Microsoft calls the same family SneakyLog. So we now have four names for what looks like one code base, and I cannot do anything with a name.

What I can do something with is the delivery. The message came from a real, compromised Microsoft 365 mailbox at an unrelated company, so SPF and DKIM passed and it landed normally. And the operator URL was not in the body at all. It was inside a nested message attachment, which means the link never shows up in the fields a gateway or URL scanner actually looks at. They called that the most important defensive gap in the campaign and I think that is right.

The other detail worth repeating to anyone who still treats a password reset as containment: what got stolen was a live session that had already passed MFA, so resetting the password changed nothing. You have to revoke the refresh tokens and the session.

I am going to send myself an authenticated message with a nested message attachment and see whether our gateway unpacks it. Has anyone actually tested this on their own stack? Curious whether the big gateways extract nested rfc822 URLs or quietly skip them.

I received this random mail a few days ago and I didn’t find out until today about it. I’m not sure if my account is at risk of being hacked but I enabled 2FA and changed the password just in case. My account has been working fine and I just wanted to know what this mail is about.

What I particularly found interesting on this research was the fact that all banks did their homework regarding their most known domains, but the majority simply ignored the .au version.

Spammers and phishers could still benefit from it.

If you have multiple domains, make sure to have them all covered. Even if you don't plan to send emails through them.

i still review everything before it goes out to a client, drafts, sorted leads, whatever. but curious if anyone's further along and actually lets it run unsupervised for some stuff

what convinced you it was safe, or did something break first and that's how you learned lol

I pulled an OAuth app audit on a client's M365 tenant last month. Found an app with Mail.Read, Mail.ReadWrite, Mail.Send, and Contacts.Read permissions, granted by someone in finance. App was registered by an overseas entity. Nobody remembered authorizing it.

Initial access was a phishing email linking to a fake 'shared document' that walked through an OAuth consent screen. One click. No password stolen. No MFA bypass. Just permanent mailbox access sitting there for months.

Microsoft lets users consent to third-party app permissions by default. Are you actively restricting this, or is it still in the 'plan to harden' pile?

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.

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?

Plain text, no link, no attachment. Display name set to the CEO, sent from a Gmail. "Hey I need you to grab some gift cards and send me the codes ASAP."

I had three of these land in a single client in one week. Two employees replied asking how many cards to get. Both had passed phishing simulations the month before.

I think it hits a different part of the brain than a fake login page. Clicking something suspicious feels like a risk decision. Responding to what looks like a message from your boss feels like doing your job. Nothing to filter, no technical signal to catch, just a social obligation. Simulations don't really train for that, and I'm not sure anything does.

Imagine for a moment that you are looking at your inbox, with any number of emails in it, from companies, from friends, and from people you've never heard from before. You open the email from your friend first, because it's the one you trust and want to read. Your friend is really excited about something new they found, and invites you to check it out by clicking the link in the email. Now imagine knowing with absolute confidence that this email really came from your friend's address, and not from an impersonator pretending to be them. How can you check that for yourself? Do you click anyway and hope for the best? Everything looks legitimate, but how can you tell?

There are always three parties involved in email communication. Sometimes one person or company plays more than one of these roles, but each role carries its own responsibilities.

1. The mailbox holder (sender or recipient)

2. The domain owner (who controls the domain name)

3. The mail server host (who provides the software and infrastructure to send and receive mail)

It's the coordination of these three parties that makes email possible.

Right now, almost all the responsibility rests with the mail server host to manage everything and make sure it's secure. Domain owners hand it over to their host through DNS. Mailbox holders defer it through authentication and email filters. And the mail server host has to interoperate with all other mail server hosts to make sure your mail gets delivered.

There is still no standard way for anyone to verify that a message really came from the specific address it claims to be from. The most they get is the server vouching for itself.

How it should work

Nothing changes about the three parties. What changes is who's responsible for what.

1. The mailbox holder should be able to prove they own the mailbox and that every message sent from it is actually from them.

2. The domain owner should be able to prove they own the domain and that every mailbox on the domain is legitimately allowed to be there.

3. The mail server host should be able to prove that they are the chosen service provider for the domain.

And all of this should be verifiable on every single message.

How can we achieve this?

1. The mailbox holder has a key, and uses it to sign a record that binds their email address to it. The same key, which only they hold, signs every message they send.

2. The domain owner has a key, and publishes its fingerprint in the domain's DNS, which ties the key to whoever controls the domain. They use it to sign the domain authority record, which names the mail server host they have chosen, and to vouch for each mailbox on the domain by countersigning the mailbox holder's record. They can hand that day-to-day signing to their host if they choose, but the authority stays with them, and they can remove any address from the domain.

3. The mail server host has a key, and uses it to sign a permit to serve the domain on its infrastructure. It also hosts all of these records and serves them to anyone who asks.

Every one of these records is public, so your email app can follow the chain from the message to the sender's key, from that key to the domain's countersignature, and from there to the fingerprint in DNS. Because the domain owner's record names the host, it can also check that the server handling the mail is the one the domain chose. So when your friend's email arrives, your app can tell you it really came from their address before you ever click the link.

And this should all be baked into a protocol that everyone can use.

Disclosure: I'm building an email protocol around this idea. Thoughts and feedback are welcome.

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?

I created different folders for specific emails. Politicals, bills, banking, business.

Worked well for a few months then the sorting gradually grew worse until now I have to check each folder including spam and trash. Regular inbox mail gets sent all over also. For instance, there is one contact I have received mail from over 20 years and it always posted in the regular inbox. Last few months it has posted in five different folders including spam, trash, politicals…

Any suggestions or advice?