Own-Domain Spoof Fails SPF, DKIM, and DMARC, Still Delivers

The credential-harvesting page at the end of this attack was branded for a company that had nothing to do with the victim. A manufacturer named POLYMOLDINGLLC owned the logo on the login modal. The target organization had never done business with them.

That single mismatch is the whole story. It means the attacker did not build a page for this victim. They reused a phishing kit, deployed it against unrelated targets, and never bothered to re-skin it.

Here is what makes the case worth studying: the email that carried it should have been trivially easy to stop. It spoofed the target's own domain and failed SPF, DKIM, and DMARC outright. No gateway-laundering trick, no compromised third party lending it reputation. It was a clean authentication failure that still reached an inbox.

The message spoofed the target's own domain and failed every check

The From address read "Account" . The To address was info@[the same domain]. Sender and recipient sat on the same domain, which is what makes this an own-domain spoof rather than third-party brand impersonation. The attacker was not pretending to be Microsoft or DocuSign. They were pretending to be the victim's own IT or account-management function.

Authentication told the truth. SPF returned a hard fail: the submitting IP, 194[.]99[.]104[.]233, was nowhere in the domain's authorized senders. DKIM was absent, with no signature at all. DMARC failed against a published policy of reject. On paper, this message had every reason to be rejected or quarantined before a human ever saw it.

An own-domain spoof against a domain publishing DMARC p=reject is the single easiest phishing pattern to block with authentication alone. When a message claims to come from your domain and cannot prove it, the answer is no. The fact that this one landed is a reminder that authentication only protects you when something is configured to enforce it.

A quarantine scare built entirely in HTML

The body impersonated a security notice. A banner warned the recipient that emails had been quarantined because of an "unusual sender IP," and pushed a single action: a button labeled "Verify me."

The banner was ordinary HTML rendered inside the message body. It was not a native client trust banner or a real Microsoft quarantine notice. It was a picture of one, drawn in the email to manufacture urgency. This is credential harvesting working the oldest lever there is. NIST defines phishing as tricking a user into revealing sensitive information, and here the sensitive information was the recipient's own mailbox password. Tell someone their access is at risk, then offer a one-click fix.

There was exactly one call to action, and every path led to the same place.

Why Google Cloud Storage made the payload harder to block

"Verify me" pointed to hxxps://storage[.]googleapis[.]com/bestnotifications/index[.]html. The credential page was hosted directly in a Google Cloud Storage bucket.

This is trusted-infrastructure abuse, and it works for a plain reason. storage.googleapis.com is a Google-owned domain with a spotless reputation. Domain and URL reputation filters that would flag a freshly registered attacker domain wave a googleapis.com link straight through. The attacker never needed to register or age a domain. They uploaded a static HTML file to a public bucket and let Google's reputation carry it.

CISA has repeatedly warned that attackers stage phishing content on legitimate cloud services precisely to slip past reputation-based controls, guidance published in its phishing guidance for stopping the attack cycle. The 2024 Microsoft Digital Defense Report documents the same shift toward abusing trusted hosting to defeat blocklists. Reputation is not a control when the attacker borrows someone else's.

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

The reused kit that gave the whole thing away

The landing page presented a simple email-and-password form. And it was branded for POLYMOLDINGLLC, a company with no connection to the target.

That mismatch is a durable signature. A phishing page whose branding does not match the lure that delivered it is almost never a coincidence. It is a kit template built for one victim and recycled against others, the operator too rushed or too indifferent to swap the logo. When the brand on the credential page and the brand in the email do not agree, you are looking at reused infrastructure, and near-certain phishing.

This is where behavior beats blocklists. Our Adaptive AI, Themis, flagged the message at 89% confidence and labeled it credential theft with impersonation. It did not need a prior sighting of the googleapis.com URL or the submitting IP. It read the combination: a same-domain sender that failed every authentication check, a manufactured urgency banner, a single credential-seeking link, and a destination whose reputation did not match its intent.

Two independent signals stacked here, and either one alone should raise an eyebrow. First, an own-domain spoof that fails SPF, DKIM, and DMARC with no gateway excuse. Second, a credential page on a trusted public bucket whose branding does not match the lure. Together they are as close to a certainty as email threat analysis offers.

The stakes behind that certainty are well documented. The 2024 Verizon Data Breach Investigations Report found stolen credentials involved in 38% of breaches, the single most common initial action, and the human element present in 68%. The same report clocked the median time to click a phishing link at 21 seconds and to submit data at 28 seconds. A convincing "Verify me" button does not need long to win.

Indicators of Compromise

MITRE ATT&CK mapping

Stop trusting the envelope, start enforcing the policy

The defensive takeaway is narrow and specific. If your domain publishes DMARC at p=reject and a message claiming to be from your domain still fails authentication, that message should never reach a mailbox. Own-domain spoofs are the one phishing class that authentication can defeat on its own, provided enforcement is actually turned on and the message is evaluated before delivery, not after.

Layer behavioral analysis on top for everything authentication cannot see. A DMARC verdict tells you the envelope lied. It cannot tell you the credential page lives on googleapis.com or that the login modal belongs to a company the victim has never heard of. IRONSCALES platform data shows SEGs miss an average of 67.5 phishing emails per 100 mailboxes each month, which is the gap behavioral detection is built to close. Across 35,000+ security professionals in 17,000+ organizations, the pattern is consistent: the attacks that get through are the ones a static rule never anticipated.