The OTP Lure That Passed Auth and Still Hit Junk

Four mailboxes at an engineering and construction consulting firm received the same message, and it cleared every authentication check a mail system can apply. SPF passed. DKIM passed. DMARC returned a pass verdict. The message came off Amazon SES, some of the most reputable bulk-sending infrastructure on the internet, and the receiving edge logged composite authentication as pass with a perfect reason code. On the strength of those signals alone, a great many gateways would wave it through.

The receiving stack did not. It scored the message as spam on content grounds and dropped all four copies in Junk. That gap, between a flawless authentication result and a message the same platform judged hostile, is the whole lesson of this teardown. Authentication compliance and content legitimacy are two different problems, and this email passed the first while failing the second.

Authenticated by Amazon SES, Sent by a Stranger

The sending domain, boydrealestatevt[.]com, is not a throwaway. It is a small real-estate business domain registered more than a decade before this email was sent, privacy-protected at the registrar, with no connection whatsoever to the brands the message impersonated. Whether it was compromised or simply repurposed as a relay, the effect is the same: the attacker inherited a clean, aged reputation and a valid authentication posture for free.

Because the send went through Amazon SES out of an EU region, SPF passed on Amazon's published sending IPs, DKIM passed with a signature aligned to both the sender domain and amazonses[.]com, and DMARC recorded a pass under the domain's published policy. Every one of those checks did its job correctly. That is the uncomfortable part. Authentication proves a server was allowed to send and that the body was not tampered with in flight. It proves nothing about intent. Send through shared, trusted infrastructure and you borrow its reputation, no matter what you put in the envelope.

A Fifteen-Minute Countdown

The body dropped the real-estate identity entirely and dressed itself as a security notification, borrowing the visual language of an Okta and Microsoft 365 task prompt. Its centerpiece was a one-time code presented as time sensitive, stated to expire in fifteen minutes, above a single call-to-action button labeled to look like a link into a pending task queue.

The countdown is the engine. A code that dies in minutes is designed to collapse the window for scrutiny, to move a reader from reading to clicking before the mismatch between a real-estate sending domain and an Okta-styled security prompt has time to register. The 2024 Verizon Data Breach Investigations Report puts numbers on why that works: the median time for a person to click a phishing link is about 21 seconds, and to hand over data on the page behind it, about 28 seconds. A fifteen-minute timer is not a real constraint. It is theater engineered to beat the few seconds of doubt that would otherwise save the target. Stolen credentials, the payoff this lure was fishing for, were involved in 38 percent of breaches in that same report.

A Redirect Chain That Borrows Trust

The single button did not point at an attacker page directly. It pointed at a link rewritten by Egress Defend, a legitimate email security gateway, on the domain hxxps://links[.]us1[.]defend[.]egress[.]com/Warning. At the first hop, a scanner sees a trusted security vendor, exactly the outcome the attacker wanted.

The mismatch lives in the parameters carried inside that rewrite. Its @OriginalLink value pointed at hxxps://us-west-2[.]protection[.]sophos[.]com, a second unrelated security-vendor reference, and a Domain parameter named michaelsaunders[.]com, a real-estate brand with no relationship to the sender, the impersonated Okta prompt, or the recipient. The result is a nested, multi-hop chain in which each layer points somewhere the previous one did not, and none of them line up with the security brand the message claimed to be. A URL scanner that clears the visible first hop never reaches the contradiction stacked behind it. This is textbook link-based delivery, mapped by MITRE ATT&CK as T1566.002 Spearphishing Link, and it only pays off if the reader clicks it, the user-execution step tracked as T1204.001.

Mapping to MITRE ATT&CK

• T1566.002 Spearphishing Link covers the core delivery: a socially engineered message whose payload is a link routed through a rewriter.
• T1204.001 User Execution: Malicious Link covers the reliance on the reader clicking the button under time pressure.
• T1585.001 Establish Accounts covers standing up and exploiting the sending identity used to launder the campaign onto trusted infrastructure.

Indicators of Compromise

Why It Still Scored as Spam

Static, authentication-first defenses were always going to struggle with this one. The infrastructure was legitimate, the authentication was genuinely clean, and the first link hop landed on a real security-gateway domain. What flagged the message was not a header failure but its content and behavior: a sending domain that had no business impersonating an Okta security prompt, a one-time-code urgency device, and a link-rewrite chain whose own parameters pointed at domains unrelated to one another and to the claimed brand. Those signals drove a spam score high enough to junk all four copies.

That behavioral read is what the IRONSCALES platform is built to do consistently rather than by luck. Themis, our Adaptive AI analyst, weighs the relationship between the claimed brand, the real sending identity, and the full redirect chain the way a trained analyst would, and flags hostile intent even when SPF, DKIM, and DMARC all pass. That is how credential-harvesting lures that lead to account takeover get caught on trusted infrastructure. If you want to know how many of these your current gateway is waving through on a clean authentication verdict, the SEG gap calculator is a blunt place to start. CISA's guidance on recognizing and stopping phishing early is a solid team reference for building the reflex: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one

The Takeaway

A clean SPF, DKIM, and DMARC result tells you a server was allowed to send and the body was not altered in flight. It does not tell you the sender is honest, and an attacker sending through Amazon SES from an aged, reputable domain knows exactly how little that verdict costs them to obtain. The defense is to treat authentication as one input among many, to trace every link past its first trusted hop, and to distrust any security prompt whose sending identity and redirect path wander off the brand it claims to be. This message passed every check the envelope could offer and was still, on its content, a fake.