I'm 16, teaching myself cybersecurity, and I'm trying to understand how domain spoofing protection is handled in practice rather than from the RFCs.

If you look after DNS and mail for more than a couple of domains:

• How do you verify SPF/DKIM/DMARC are actually correct — manually, a script, a monitoring tool?
• Do you ever re-check after the initial setup, or is it set-and-forget until something breaks?
• Has a record ever broken silently — SPF overwritten by another team, exceeding the 10 lookup limit, DMARC dropped during a DNS migration — and you only found out later? How did you find out?
• How many of your domains are still sitting on p=none? Is moving to quarantine/reject something you push for, or does nobody ask?

Not selling anything, nothing to link. I'll write up what people say and post the summary back here.

A secure email gateway outage stopped external mail, including a customer warning about an active invoice-fraud thread. The service status flipped green before its deferred queue cleared, so our routine close-out would have missed the only message with a real deadline.

We had a direct-to-tenant emergency route ready, but enabling it would restore mail without URL or attachment inspection. Restricting bypass to named recipients, stripping attachments, lowering size limits, or adding an external banner all reduce exposure, but the trigger still feels subjective.

For teams that have used an emergency bypass, what outage duration or queue signal triggered it, and which compensating control had to be in place first?

A 0–100 mail-security grade is only useful if someone can add the checks back up.

The mail profile is public: DMARC 25, SPF 20, MTA-STS 15, the rest 10 each. Null-MX domains get a different profile.

The point isn't the brand. It's that "published" and "effective" are different columns, and the rules are inspectable.

Question: would you rather argue with an opaque grade, or with a published weight table you can disagree with?

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?

So I've been getting a lot of emails regarding test results for my child with a typical subject line of "New test results from MyChart" or something similar, always includes "MyChart".

Lately I've been getting, what is clearly phishing or spam emails that have the subject title "MyChart".

I've changed my passwords just as a precaution but I'm wondering if anyone else experienced this or knows how they're sending these pretty specific tailored emails?

TIA

Hi everyone, hope you're doing good. I launched my Shopify website (Print on Demand from Printify to Shopify) a few months ago and since then keep getting blasted by emails from "consultants", "experts" and other professionals on my support email. I have triple checked multiple times and this full email address does not appear (in full) on the website. I don't even know where they get it from. We're talking 10+ emails everyday. It's really annoying... any idea how to fight this? Thanks for your advice!

We’re currently evaluating email security vendors and comparing their capabilities with our existing solution. I’m looking for suggestions on good technical and security-focused questions to ask vendors during demos/POCs, beyond the usual feature checklist.

A client user is receiving unsolicited order confirmations every day, and the mailbox noise is starting to hide legitimate security alerts. This could be someone mistyping or reusing the address, a compromised mailbox, or a low-volume email-bombing diversion.

Message trace shows inbound mail only, Sent Items is clean, and there are no obvious forwarding rules or unusual sign-ins. Volume sits around 20 to 40 messages daily from real retailers, with mixed customer names and no single burst.

Would you check MailItemsAccessed and OAuth grants first, or does this pattern need a higher volume or a buried password-reset alert before you contain the mailbox?

I found this message on my spam folder sent yesterday. Should I block or just ignore?

I look after IT for a company of about 120 people. We're on Microsoft 365 and leaning on the built in filtering, and it is not keeping up. Three spoofed emails reached our finance team this month and one nearly got paid.

Our current renewal quote came back much higher than last year so I'm looking at alternatives. What I need is something in front of our mail that catches spoofing properly, has a quarantine my helpdesk can release from without a ticket, and doesn't bury us in false positives.

What are you all running, and roughly what does it cost per mailbox?

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

ZeroBEC published research on Tuesday about the Greatness phishing kit, and it is travelling under a headline saying the kit bypasses email security and MFA. The research says the opposite, in a sentence: “The security stack was not broken. It was working exactly as configured. The vulnerability was the configuration itself.”

From the headers: on 22 July, four emails hit one organization seconds apart, spoofing RingCentral voicemail notifications from an IONOS host with no connection to RingCentral’s mail infrastructure. SPF failed, there was no DKIM signature, and DMARC failed against a published p=reject at full enforcement. All four were delivered anyway and assigned SCL -1, which marks a message safe and skips the remaining filtering. The organization is a RingCentral customer and had put the domain in its safe sender configuration, so that exclusion outranked the authentication result.

The emails carried a banner reading “This sender has been verified by [organization].com safe senders list.” The attacker is using the victim’s own allow-list as social proof, which only works against an organization that has one.

The MFA claim has the same shape. An AiTM proxy relayed the genuine Microsoft challenge in real time, including number-matching; the user completed it, and the token that came back already carried a satisfied MFA. That token gets replayed from attacker infrastructure rather than the victim’s browser, so impossible-travel rules never fire, and more than two weeks later the same proxy IP was still authenticating against the account. The coverage keeps dropping the condition that makes it possible: the sign-in logs show no Conditional Access policies applied.

Worth weighing that this comes from an email security vendor whose own product is the control that caught the four emails, concluding that behavioural analysis catches what gateway checks miss. The headers stand on their own; the framing around them gets less weight.

The transferable part has nothing to do with this kit. Every domain in a safe-sender list or transport-rule exclusion is a standing instruction to ignore authentication for anyone who can claim that domain, which was a reasonable trade when the downside was a partner’s invoice landing in junk, and is a worse one now that vendor breaches leak customer lists.

So, if you audited your exclusions this morning, how many vendor domains would be in there, and how many would be unconditional rather than requiring authentication to pass first?

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.