A Fake Ingersoll Rand Domain That Passed Every Auth Check

This email passed SPF. It passed DKIM. And Microsoft's DMARC best-guess waved it through. Every authentication signal a receiving mail server checks came back clean, and the message was still a fraud. The sending domain, ingersollrandcompany[.]com, had been registered eight days earlier.

That is the entire lesson in one line. Authentication tells you a message was not tampered with in transit and that the sender is permitted to use the domain in the From header. It says nothing about whether the domain deserves your trust. When an attacker owns the domain outright, they get to answer every authentication question honestly, and the answer is still a lie.

The setup: a payment-status request from a domain that is not the real one

The message landed in an accounts-payable-adjacent mailbox at a commercial mechanical contractor, the kind of firm that buys compressors and HVAC equipment from vendors like Ingersoll Rand. Subject line: "Pay Status Req." Priority: High. The body asked about the status of a payment and pointed the reply toward a remittance address, its_remittance@ingersollrandcompany[.]com, closing with a signature from an accounts receivable clerk and a phone number for realism.

The real Ingersoll Rand uses ingersollrand.com, registered in 2001. The domain in this message, ingersollrandcompany[.]com, was created on January 26, 2026, and the message went out on February 3. Eight days of tenure. Registrant details were redacted behind Cloudflare, there was no public A record, and the domain existed only to send mail. That profile, a fresh registration configured purely for email, is one of the cleanest tells in the business. This is masquerading (MITRE T1036.005) executed through impersonation (T1656), and the goal was payment diversion.

How authentication got played

Here is where the details matter, because the common shorthand ("the fake domain passed DMARC") is not quite what happened, and the truth is more instructive.

The attacker sent through Amazon SES. SES is legitimate infrastructure used by countless real businesses, which is exactly why attackers reach for it. Look at what each check actually evaluated:

• spf=pass on smtp.mailfrom=share.ingersollrandcompany[.]com. The attacker controlled the lookalike domain, so they published an SPF record authorizing the SES sending IP. Of course it passed.
• dkim=pass with header.d=amazonses.com. The signature verified, but it was keyed to Amazon's signing domain, not to the lookalike itself. SES handed the attacker a valid DKIM signature for free.
• dmarc=bestguesspass. This is the part people misread. The lookalike domain published no DMARC record at all. Microsoft's receiving stack applied a best-guess heuristic based on the SPF alignment and let it through. There was no enforced DMARC policy to satisfy, so the attacker did not even need one.

Read together, none of these signals says the sender is Ingersoll Rand. They say the sender is permitted to use a domain that resembles Ingersoll Rand. That distinction is invisible to a busy clerk and, more importantly, invisible to a control that stops at the authentication layer. This is why DMARC on your own domain, while worth doing, does nothing here. DMARC protects your domain from being spoofed. It has no jurisdiction over a completely separate domain that merely looks like a brand you trust. This is the mechanic behind most vendor email compromise and lookalike-domain fraud.

The links added a layer of fog

The visible link text pointed to a plausible-looking customer portal. The actual hyperlink was wrapped through a Microsoft SafeLinks rewrite and then through an awstrack[.]me tracking redirect before resolving to the displayed destination. Automated scanning returned a clean verdict on the final page, which is common. Redirect chains through legitimate tracking and rewrite services are not proof of malice on their own, but they do exactly one useful thing for the attacker: they obscure the true path and make click activity harder to inspect. Combine an opaque redirect chain with a newly registered remittance domain and an urgent payment ask, and the risk picture is unambiguous regardless of what a single page snapshot shows. The technique maps to phishing via link (T1566.002).

See Your Risk: Calculate how many threats your SEG is missing

What actually stopped it

Authentication was worthless here, so something else had to do the work. It did. Microsoft's own filtering assigned the message a spam confidence level of 5 and categorized it as PHISH before it reached the inbox proper. Layered on top, Themis, our Adaptive AI, scored the message at 78 percent confidence and labeled it invoice phishing, driven by three converging signals: the language and structure of the payment request, the newly registered return-path domain, and community resolution of similar incidents. Both affected mailboxes were quarantined within seconds of receipt.

The point is not that one engine beat another. Both the platform mail filter and the behavioral layer landed on the same verdict. The point is where the signal came from. Not from SPF, DKIM, or DMARC, all of which passed. It came from content and behavior: the anomaly of a remittance change, the tenure of the domain, and the shape of the ask.

The takeaway for accounts payable and email defense

Attackers have fully internalized that authentication is a solved problem for them. Register a lookalike, send through a reputable cloud provider, and you inherit a clean auth verdict. The Verizon 2026 Data Breach Investigations Report puts the human element in 62 percent of breaches, and the FBI's 2024 IC3 report continues to rank business email compromise among the costliest categories of cybercrime, precisely because these messages arrive looking legitimate. CISA's phishing guidance is blunt about the underlying problem: technical controls that stop at reputation and authentication leave the door open.

Two defenses actually move the needle. First, treat any bank-detail or remittance change as an out-of-band verification event. Call a known-good number, never the one in the email. Second, weight domain age and WHOIS context as first-class detection signals, not afterthoughts. A domain sending a payment request eight days after it was registered should never clear on authentication alone. That behavioral and reputational analysis is the core of effective business email compromise protection, and it is why IRONSCALES data shows legacy gateways still miss roughly 67.5 phishing emails per 100 mailboxes each month. The ones that pass authentication are exactly the ones a gateway is least equipped to stop.

Indicators of Compromise