A message landed in an inbox claiming to be from BSE India, the Bombay Stock Exchange. The subject read "Account Alert: Confirmation Required," and the body warned that the recipient's account information needed confirming to continue normal service. The interesting part was not the bait. It was the headers. SPF passed. DKIM passed. DMARC passed. Every automated trust signal an email client could show was green — and the message was still a trap.
This is a teardown of that email, because it is a tidy lesson in a thing defenders and users both get wrong: "all authentication checks passed" is not the same as "this email is safe."
What the victim sees
Stripped of its tidy HTML card, the body is deliberately bland. It opens with a generic "Hello," states that the system detected your account information requires confirmation, and offers a single button: "Confirm Account Information." There are no spelling mistakes, no garish logos, no promise of a lottery win. Modern phishing has mostly abandoned the comedy-of-errors look. This one is trying to be boring, because boring does not get a second glance.
The headers all checked out
The authentication results were the whole story:
- SPF passed because the sending IP, 202.162.239[.]146, is genuinely authorized to send for bseindia.com. The sending host announced itself as pmta2.in-239146.ncm14[.]com — a PowerMTA bulk-mail server run by an email service provider under the domain ncm14[.]com. The From-domain's published SPF record includes this provider, so mail leaving its servers is treated as legitimate.
- DKIM passed, but the signature was applied by the provider's domain, ncm14[.]com, not by bseindia.com directly. That is ordinary third-party signing — the same arrangement countless brands use for marketing and transactional mail.
- DMARC needs only one aligned, passing mechanism. Because the envelope sender aligned with the visible From address and SPF passed, DMARC was satisfied too.
Here is the lesson worth keeping. SPF, DKIM, and DMARC answer exactly one question: was this message sent through infrastructure the From-domain authorized, without being tampered with in transit? They say nothing about whether the content is honest or where the links lead. An email can be one hundred percent authenticated and one hundred percent malicious at the same time.
How it still passed
From a single captured message you cannot prove root cause, so be precise. The most likely explanation is abuse of a legitimate sending account on a shared bulk-mail platform. Large providers host many senders on shared address ranges, and if an attacker gains access to a sending account — or if the From-domain's SPF entry trusts the whole platform — phishing mail can ride out on genuinely authorized infrastructure and inherit its good reputation.
What the evidence does not support is the lazy conclusion that the exchange's core systems were breached. The headers show abuse of an email-sending pathway, not a hack of the stock exchange. The opposite reflex is just as wrong: "authentication passed, therefore it is real." The truth sits in the uncomfortable middle, and the payload settles it.
The link gives it away
Intent becomes undeniable in the link. The visible button reads "Confirm Account Information," and its destination is wrapped in a Microsoft SafeLinks URL — the kind Outlook generates so it can scan a link at click time. A SafeLinks wrapper is not an endorsement; it only means the message passed through a mailbox with that protection enabled. The anchor also carried an originalsrc attribute that preserved the true, pre-rewrite target: hxxps://elearn.kagayakibaby[.]org/coin/.
That destination is incoherent with the brand. The sender claims to be a stock exchange, the body talks vaguely about account services, and the landing page is the e-learning subdomain of an unrelated website, with the kit sitting under a /coin/ path. Legitimate exchange mail does not send you to a random third-party e-learning domain. This mismatch between brand, content, and destination is the signature of a phishing kit dropped onto a compromised website — a cheap, disposable host whose only value to the attacker is borrowed reputation. If you ever need to inspect a SafeLinks URL safely, decode its url parameter and read it. Never load it.
Indicators of compromise
Defanged, and not to be visited:
- Spoofed sender: alert@bseindia[.]com
- Subject: BSE India - Account Alert: Confirmation Required
- Sending IP: 202.162.239[.]146
- Sending host (HELO): pmta2.in-239146.ncm14[.]com
- DKIM signing domain: ncm14[.]com
- Payload URL (true target, from the link's originalsrc): hxxps://elearn.kagayakibaby[.]org/coin/
- The na01.safelinks.protection.outlook[.]com wrapper is a benign rewriter; the indicator is the target inside it.
How to protect yourself
Judge the destination, not the sender name. Hover a link, or long-press it on mobile, and read where it actually goes. A stock-exchange alert that points to a random .org/coin/ page is the end of the conversation. Remember that the absence of a spoofing warning is not a clean bill of health; it only means the envelope was not forged. If you think an account genuinely needs attention, type the official address yourself or open the app — never use the link in the email. The combination of a generic greeting, manufactured urgency, and a single link is the phishing fingerprint.
For defenders: treat SafeLinks wrappers as opaque in triage and always decode the real target before you verdict. Audit how broad your SPF includes are — authorizing an entire shared bulk-mail platform means any tenant on it can pass as your domain. Push toward DKIM alignment on your own domain plus DMARC at enforcement, and never let an auth-pass auto-allow content; layer URL reputation, brand-impersonation logic, and payload detonation on top.
The takeaway
Email authentication proves provenance, not honesty. In this case SPF, DKIM, and DMARC did their jobs perfectly: the mail really did leave an authorized sending path without tampering, and it was still a trap. The forgery was not in the envelope. It was in the story and the link.
Sita walked through fire so the truth could be seen for what it was. A green checkmark is the opposite kind of proof — it certifies only that the letter was not opened in transit. It never promised the letter was telling the truth. Read the link, not the seal.
No comments yet