Your Email Campaign Can’t Reach People If It Can’t Prove Who Sent It

Overview

At the end of August, an unsolicited email landed in one of our mailboxes advertising a range of counter-surveillance products. The sender introduced themselves as the CEO of Global TSCM Group, a specialist vendor selling eavesdropping detection systems, laser microphone countermeasures, and encrypted Bluetooth earbuds.

The campaign had clearly taken some work to put together. It included current product material, two catalogues, campaign tracking, and an unsubscribe mechanism. Microsoft Defender sent it to Junk, classified it as spoofed, and marked the visible catalogue links as malware.

We investigated the message because the details didn’t fit neatly into a conventional phishing campaign. The sender, company, products, and documents were consistent across several public sources. The two catalogue links we examined returned ordinary PowerPoint-exported PDFs, and our static review didn’t identify JavaScript, embedded files, launch actions, forms, or other active PDF features.

The clearest problem wasn’t the content, it was that the company’s email platform authenticated itself as DirectSend, while the message asked the recipient to trust Global TSCM Group.

This is where DMARC stops being an abstract security control and becomes a business communication problem. A legitimate organization can write the right message, send it to the right audience, and still make itself look like a spoof.

Why the message deserved a closer look

Global TSCM Group operates in Technical Surveillance Counter-Measures, or TSCM: the detection and prevention of hidden microphones, RF transmitters, laser audio surveillance, unauthorized mobile devices, and other forms of electronic eavesdropping.

The company’s public footprint is unusual but consistent. A New York corporate record shows a filing for Global TSCM Group, Inc. in 2007, with Gyo Seung An listed as the process contact. That’s the same name used in the email, shown in the company’s public materials, and embedded as an author in one of the catalogues. The CEO address used in the campaign is also published on the company’s website.

Its sites advertise the same products described in the message, including The Stealth 24/7 RF monitoring system, The Stealth TEAM transmitter-location system, laser surveillance countermeasures, and the newly promoted encrypted earbuds. The documents and websites use the same product names, claims, people, and contact details.

There were still reasons a recipient would hesitate. The company’s presence is spread across a main domain, separate U.S. and Korean sites, The Stealth Lab, The Stealth Mall, and other product properties. Some pages contain 2026 material while parts of the design and footer still say 2021. The catalogue includes both a corporate address and a Gmail account. It looks more like the accumulated web presence of a small specialist manufacturer than a centrally managed corporate identity.

That isn’t evidence of malicious activity, but it does mean the email had little margin for another trust failure.

SPF and DKIM passed. DMARC still failed.

DirectSend infrastructure appears in the sending headers, return path, DKIM signature, unsubscribe link, and catalogue download URLs.

SPF and DKIM did their individual jobs. SPF confirmed that the sending server was permitted to send for DirectSend’s envelope domain. DKIM confirmed that DirectSend signed the message and that the signed content hadn’t been changed in transit.

Neither result answered the question the recipient cared about: did Global TSCM Group authorize this email?

DMARC connects those checks to the address displayed in the From field. At least one authenticated domain must align with the visible sender’s domain. In this case, both successful results belonged to DirectSend, not Global TSCM Group.

Microsoft therefore categorized the message as spoofed and assigned it an SCL of 5, sending it to Junk. From the receiving side, that was a reasonable decision. The message claimed one identity and authenticated another.

The deliverability cost of incomplete setup

DMARC is normally introduced as a way to prevent attackers from spoofing a company’s domain. That’s an important reason to deploy it, but it can make the control sound relevant only when something malicious is happening.

Most organizations also have a more ordinary problem: many systems send mail on their behalf.

Each platform can produce a message that looks correct to the sender while authenticating a different technical identity underneath. When that identity isn’t aligned, the consequences are practical:

• A sales campaign is placed in Junk before a prospect sees it.
• A customer misses an invoice or payment notice.
• A password-reset or account notification looks like phishing.
• An operational alert is delayed because the receiving system distrusts it.
• Staff begin asking customers to allow-list mail instead of correcting the configuration.

This email we reviewed is a useful example because the mismatch is especially costly. A business was introducing security products to an unfamiliar recipient. The business needed the first message to establish credibility, but its mail configuration removed one of the strongest technical signals available to do that.

Shared infrastructure adds another reputation problem

The catalogue links didn’t point to files hosted on globaltscmgroup.com. They used DirectSend’s shared mail_report_api/filedownload path with campaign-specific identifiers.

Defender displayed eleven URLs in the message and marked the visible catalogue download links as malware. We retrieved those two objects in an isolated environment on September 11, 2026.

The files matched the products and identities published on the company’s websites. At the time of this post, we didn’t find evidence that the two retrieved PDFs were malicious.

We also can’t say exactly why Microsoft assigned the URL verdict. It may have involved the shared download path, reputation inherited from other activity on the platform, the retrieved objects, or other signals from the message. A URL hosted by a bulk-mail provider sits on infrastructure shared with customers the sender doesn’t know and can’t control.

This is a second reason to think about deliverability as part of platform selection. Authentication can be configured correctly and a sender can still inherit risk from shared tracking, redirect, image, or file-hosting domains. Wherever practical, organizations should use aligned branded domains and host important customer material on infrastructure tied clearly to their own identity.

What practitioners should verify

Setting up a third-party sender isn’t finished when the platform says the DNS record was accepted or a test message arrives in your own inbox. The final check has to happen from the recipient’s side.

Inventory every service sending as your domain

Start with the platforms people tend to remember—Microsoft 365, Google Workspace, and the primary marketing service—but include the quieter systems as well. Invoice platforms, support tools, CRM workflows, website forms, scanners, HR systems, security products, and line-of-business applications all send mail that affects the domain’s reputation.

Check alignment, not only pass or fail

Look at the domain that passed SPF and the d= domain in the DKIM signature. At least one should align with the domain displayed in the From address. A green SPF result for the vendor’s domain doesn’t authenticate your brand.

Confirm DMARC at the destination

Send controlled tests to the major environments your customers use and inspect the received headers. Microsoft 365 and Gmail are useful starting points. Confirm that DMARC passes after the full delivery path, not only inside the sending platform’s setup wizard.

Review the links the platform inserts

Campaign tools may replace otherwise clean URLs with tracking redirects, unsubscribe endpoints, image hosts, and download services. Check their reputation and decide whether branded tracking or file-hosting domains are available.

Monitor before enforcing

DMARC aggregate reporting can show which services send as the domain and which ones fail alignment. Use that visibility to correct legitimate senders before moving deliberately toward p=quarantine and then p=reject. Leaving the policy at p=none indefinitely provides reporting, but it doesn’t instruct recipients to block unauthorized use.

Don’t solve configuration problems with broad allow-lists

Allow-listing a shared sending service can suppress the symptom while trusting unrelated traffic from the same provider. Fix the authentication path first. Use narrowly scoped exceptions only when there’s a clear operational need and ownership around their review.

Sources

1. OpenGovNY New York corporation record for Global TSCM Group, Inc.
2. Microsoft Security Operations guide for email authentication in Microsoft 365
3. Microsoft Set up DMARC to validate email
4. Microsoft Email security with Threat Explorer and Real-time detections