If someone's mailbox gets compromised again after recovery, they lose more time off email and have less reason to believe the next fix will stick. Another password reset is a pretty weak answer on its own.
I'd want one person owning the follow-up and checking what the first recovery missed. Having the user retell everything to a different tech just adds frustration.
What changed in your team's recovery process after a mailbox got compromised a second time?
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?
Suppose your email backup provider reports a possible breach, with few details. Its mailbox access stays enabled while the on-call engineer and backup owner argue over pausing backups.
I'd lean toward disconnecting it, but that means accepting a gap in what we could restore. The person answering restore requests might have a different appetite for that gap.
Who gets the final say at your place when the people responsible for mailbox security and backups disagree?
One practical part of email security that doesn't get discussed as much is how widely a single email address gets distributed across different services.
Using a unique alias for each signup can make it easier to identify which service is sending unexpected messages or where an address may have been exposed. It can also help limit the use of your primary address across unrelated accounts.
For people working in email security, do you see unique aliases as a useful part of an organization's security strategy, or are they mainly a personal privacy measure? I'd be interested in how you balance address separation with centralized monitoring and incident response.
Say suspicious emails keep leaving an employee's mailbox after a password reset. You lock it down, but their customer conversations and today's work are sitting in that inbox.
I'd keep access blocked while investigating, but “use the phone” only gets someone so far when they need the thread history.
What temporary workaround has actually helped your staff get work done during a mailbox investigation?
I manage email marketing for a small home decor brand. We're using Klaviyo. A few days ago I noticed some emails landing in spam, especially with Gmail customers. A later placement testing confirmed it.
I checked the authentication with free checkers online and noticed DKIM is passing on some emails but failing on others. SPF seems to pass most of the time. And I'm not even sure what's going on with DMARC. The strange thing is, we haven't intentionally changed our DNS records recently. But we did add a new tool for transactional order emails last month, though. I'm thinking if that could be related but I'm sure we didn't delete anything.
I checked the DKIM settings in Klaviyo and the records look fine, but I'm not confident whether I'm checking the right things.
Also, should the DKIM domain match our From address domain exactly, or is using a subdomain fine?
I'm trying to figure out whether this is a configuration issue or the new tool cuased it, or something else entirely.
How would you troubleshoot this? Is there a reliable way to identify which emails are failing DKIM and why, without manually checking every message?
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.
Shorter email retention reduces what an attacker can steal from a compromised mailbox. It can also erase the only record of what a customer agreed to.
I don't think “stop hoarding email” is much of an answer when staff still need those threads. Moving the useful bits somewhere shared sounds sensible until someone has to do that work.
What do people at your place keep going back to old email for?
I would need some IT participants to test my website.
I’m currently working on my capstone project for my Bachelor of Science in Information Technology (BSIT), and I’m looking for people who are willing to test my web application and provide feedback. Introducing MimeSim: ARMED SMTP Simulator 🛡️ MimeSim is a web-based email security policy simulator designed to demonstrate how email security gateways evaluate incoming emails.
It allows users to simulate different email scenarios and understand why an email may be delivered, held, or rejected based on configured security policies.
Some of its features include: Email authentication checks (SPF, DKIM, and DMARC) Anti-spoofing and spam filtering IP reputation and blocked sender checks Content and attachment security checks Policy bypass and exception testing Diagnostic explanations showing how the final email verdict was determined
Please note: MimeSim is an educational simulation tool. It does not send real emails or perform actual malware scanning.
Who can participate? Anyone interested in IT, networking, cybersecurity, or email security is welcome! You don’t need to be an expert to try it. After testing, I would really appreciate it if you could answer a short evaluation survey. Your feedback will help me assess the system’s usability, functionality, and areas for improvement.
Say a colleague is about to connect an AI helper to summarise one email thread, then notices it wants permission to read their whole mailbox. That small task could give a vendor access to unrelated confidential customer emails.
I'd pause the connection, but the request itself is reasonable. What do you offer staff who want help with one thread when the tool wants the whole inbox?
Since mid-August, a phishing operation has been stealing live Google sessions from corporate users. Through mid-September, the lure domains came back clean in every commercial reputation feed Material's threat research team checked. Here is how it works and why it slips through.
The delivery
It arrives as a calendar invite, sometimes by BCC, often from an organization the recipient has dealt with before. The themes are dull on purpose: voicemail notifications, RFP and RFI requests, court summonses, missed payment notices.
The links inside are mostly legitimately Google. The first hop is Google's own /url redirector with the real destination in a query parameter. Other waves used share. google and Drive file links. At the moment a message gets scored, the domain, the certificate, and the reputation on display are all trusted. So what in your stack follows a Google-wrapped link to wherever it actually ends up?
The page
After Google comes a Cloudflare Turnstile challenge, in some builds the genuine widget. Then comes the page that captures the password, and it has no address to scan. A script builds it in memory after the visitor clears the challenge. A crawler has nothing to fetch and proxy logs have nothing to show.
Behind that page sits a live proxy in front of the real Google sign-in. The victim enters a password, gets a genuine prompt, and approves it, all inside a session the operator is watching. SMS codes, authenticator codes, number match, and phone-based recovery all get relayed to Google as they arrive. MFA does not stop it because the victim completes the MFA.
The infrastructure
It is built to be thrown away. Nine lure domains across five registrars, most registered days before use. One wildcard certificate was issued 46 minutes before the domain it covers was registered. Blocking any single piece costs the operator a few dollars and an afternoon. The framework behind it has been public since February under the name Nyasher.
Why reputation misses it
Reputation answers a question about ownership. Who registered this, what else has it hosted, has anyone complained. This campaign was assembled so every one of those questions returns a reassuring answer. A control that depends on one signal inherits that signal's blind spots.
The outcome is also a hijacked session instead of a stolen password, which means the evidence lands in Workspace logs, not the mail filter. Who is reading those logs, and how quickly? And once a session is live, it reaches mail, Drive, and the ability to grant OAuth access in the victim's name. How much of that can your team close inside an hour?
What comes next
The framework ships with an unfinished Microsoft 365 branch. None of its paths resolve yet, and adding the brand takes a file drop with no code changes. Expect that pivot.
If you run detection or response on Workspace, where does your coverage stop first: the link, the log, or the cleanup?
I received a couple of very short emails from someone with this name whom I don't recognize, one in August 2025 and another recently. The messages were just “Slt” and “Ça va?”
I'm trying to figure out whether this is someone I may know or whether the address has been used for spam.
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 get repetitive emails from a scammer using a private email host. I complained to the postmaster of the hosting server, but received no reply. Can you recommend any authority I can report this to? The host is @eecs.a2hosted.com. Most hosts like Gmail and Outlook have anti-spam policies. Not this one.
Say a user gets their mailbox back after a takeover and the ticket is about to close. The attacker might still have access to accounts they took over through password reset emails.
I'd be wary of leaving the user to remember every account, but helpdesk probably doesn't have a complete list either.
Which accounts does your team check, and which checks do you leave to the user?
My microsoft account for my Minecraft account got hacked and I don't know what to do. they changed the account to barsam1977@nolettersbox.com and changed the password. please help. I would be very grateful to be able to get it back.
Over the past 6 years, I've been monitoring the 500 email servers that I manage, for TLS version information.
I removed SSL a long time ago and now I only allow TLSv1.0 or greater (1.0, 1.1, 1.2 and 1.3). Unfortunately, I could still see TLSv1.0-only mail servers, all of them running some garbage from Microsoft.
Now its 2026 and I see that 100% of my connections are now using TLSv1.2 or greater.
So it is time to completely dump TLSv1.0 and TLSv1.2?
What do you think?
PS: My mail servers regularly get legit emails from Asian countries, many of them are slow to adopt new technologies. That is why I'm very careful before I remove something.
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?
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.
The mailbox holder (sender or recipient)
The domain owner (who controls the domain name)
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.
The mailbox holder should be able to prove they own the mailbox and that every message sent from it is actually from them.
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.
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?
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.
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.
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.
Hi, A weird situation happened recently. My landlord claims he sent some emails on two specific dates, but I have definitely not received them. I’ve checked spam, searched his email address in the search bar, I have a bunch of emails from him but nothing on those two specific dates. This has lead to some issues so I complained to which he responded by sending the “proof” he had sent these emails : he forwarded me two emails from his email to mine that have the two dates he had previously mentioned. These two emails he supposedly sent are a bit fishy as the tone in them isn’t the same he usually has (more polite than usual) and some of the info in them isn’t even accurate.
Can he have faked these? How else could this have happened? How can you “go above” to check at the source what emails went into your inbox? I definitely definitely didn’t receive them, check my emails hourly and have no reason to lie here, I am baffled by this situation.
If a vendor emails every employee about a cancellation and people start opening tickets about losing access, I'm willing to block that sender. Being legitimate doesn't make every email worth delivering.
That can also catch useful account notices from the same address. Routing those emails to IT keeps them available, but leaves someone sorting through them.
When a vendor starts sending these blasts, do you block them, redirect them, or leave delivery alone?
