A mid-size manufacturing firm received an Italian-language email claiming their Nexi payment card had been disabled. The message opened with "Aggiornamento Importante sulla Sicurezza" (Important Security Update), addressed the reader as "Caro cliente" (Dear customer), and warned that card services had been temporarily restricted after an anomaly was detected. A single hyperlink -- labeled "Clicca qui e conferma i tuoi dati" (Click here and confirm your details) -- appeared as the only path to resolution. A boldfaced line at the bottom imposed a 24-hour deadline before the restriction would become permanent.
Nothing in the email pointed to the actual destination URL. The link resolved to hxxps://bbckenya[.]com/doc9voockj/e9dofiucv/xmnci8ud/ -- a domain with no connection to Nexi, Italian payment services, or any financial institution. IRONSCALES flagged it as credential theft within seconds. The receiving organization's gateway had already passed it.
Enterprise email pipelines run two primary automated checks against messages like this: sender authentication and URL reputation. On this email, both returned non-answers.
Authentication produced temperror at every hop. The envelope-from and visible From both showed nexi@assistenza[.]it. The official Nexi sending domains are nexi[.]it and nexigroup[.]com. Neither matches assistenza[.]it. But the authentication result was not a hard DMARC fail -- it was temperror at SPF, none at DKIM, and temperror at DMARC. Google's MX servers logged: "error in processing during lookup of nexi@assistenza[.]it: DNS error." Microsoft's gateway confirmed the same. The SPF record lookup for assistenza[.]it timed out rather than resolving to a pass or fail. Because neither receiver could complete the DNS query, neither produced a definitive authentication verdict. A temperror is not a pass, but many policy configurations treat it as one for delivery purposes, per RFC 9989's DMARC specification.
The URL reputation check returned clean. At the time of scanning, the destination URL served a Cloudflare-issued block page rather than the live credential form. The automated scanner saw no phishing content and logged a clean verdict. The underlying payload -- a minimal page copying Nexi imagery to collect personal and financial data, accessible to end users -- sat behind that layer, invisible to the scanner. This is a documented evasion technique: staging a live credential form behind infrastructure that blocks scanner traffic while passing regular browser requests.
That left one reliable signal: the destination domain had nothing to do with the brand being impersonated.
bbckenya[.]com has no public WHOIS registration data. Its DNS resolves to generic fast-deploy hosting infrastructure. It carries no DMARC record. None of that matches what a legitimate payment processor's notification would use.
More importantly, the URL path itself -- hxxps://bbckenya[.]com/doc9voockj/e9dofiucv/xmnci8ud/ -- contains randomized-looking path segments that serve no navigational purpose. They exist to make the URL appear unique per target and to complicate pattern matching on the base domain. The same structure appears across credential-harvesting campaigns that use compromised or freshly registered throwaway domains: the brand provides the subject line and the logos, while the actual hosting runs on infrastructure that has no connection to the brand at all.
The SOC analysis also surfaced a secondary domain in the infrastructure: nex-i-pal-css[.]com. The hyphenated structure mimics Nexi's brand while remaining visually distinct enough to pass casual inspection. Defanged for reference: nex-i-pal-css[.]com. Neither this domain nor bbckenya[.]com should be treated as the "sender infrastructure" -- the attacker controls the destination, while assistenza[.]it was used as the sending address.
The relay chain began at lasvegas-nv-datacenter.serverpoint[.]com (IP 216[.]108[.]229[.]29), passed through Google's unverified forwarding infrastructure, and entered the recipient tenant via a Cisco IronPort gateway. The IronPort gateway's DMARC check also returned temperror. Five independent authentication checks, five non-answers.
Nexi is Italy's largest payment network, processing card transactions for millions of cardholders. A card-disabled notification is credible, urgent, and triggers an action reflex: if I don't verify now, I lose access. MITRE ATT&CK T1566.002 documents this as a spearphishing link technique -- low-volume, targeted delivery designed to produce a single click from a single recipient.
The manufacturing firm was a corporate target. The lure was a consumer payment notification. That mismatch -- a personal banking alert arriving at a corporate inbox -- is itself a secondary signal. Legitimate payment processors do not send card-disabled alerts to corporate email addresses using a third-party domain. But that secondary signal is subtle and requires context about the recipient's role that automated filters do not have.
The Verizon 2026 Data Breach Investigations Report found credentials involved in 39 percent of breaches, with plain phishing comprising the dominant delivery method in gateway-visible attacks. Payment brand impersonation campaigns like this one operate in the volume tier that feeds that statistic. They do not need to be technically sophisticated -- they need only to survive long enough for one recipient to click.
If your gateway is passing emails with temperror authentication results and clean URL verdicts, you are exposing end users to this attack class. Run a missed attack calculator against your current gateway configuration to see the exposure quantified against real traffic.
IRONSCALES flagged this as credential theft at 88 percent confidence before any human reviewed it. The evidence Themis evaluated: the envelope-from domain does not match the claimed brand; authentication could not be verified on any hop; the destination URL resolves to infrastructure with no relationship to the claimed sender or brand; the content contains social-engineering markers (generic greeting, urgency, deadline, single action link); and the sending IP's reputation matches prior phishing infrastructure.
No single signal in that list would have been sufficient on its own. The temperror result alone might indicate a transient DNS issue. The URL verdict alone would have cleared the message. Even the domain mismatch alone requires context: assistenza[.]it could, in some scenarios, be a legitimate customer-service subdomain for an Italian brand. The combination is what makes the case.
Credential harvesting protection at the gateway layer requires resolving the brand-vs-destination gap even when auth signals are ambiguous. That means behavioral and visual analysis running in parallel with authentication checks -- not as a fallback when auth fails, but as a parallel signal that can override a non-answer. DMARC management helps close the temperror gap on your own sending domains, but the defense gap here is receiving-side: what does your gateway do when the inbound authentication simply does not complete?
The email body carried Nexi's logo, Nexi's copyright footer, and Nexi's service language. The link pointed to Kenya. That gap is detectable. The question is whether your gateway is doing the detection, or whether it is leaving it to the recipient. Per NIST's phishing guidance, user recognition remains an essential defense layer -- but it should not be the first one. The IRONSCALES platform applies multi-signal AI analysis to close the gap that authentication failures and evasion-aware URL staging intentionally create.
A temperror is not a pass. A clean URL verdict from a Cloudflare block page is not a clean URL. When both fail at once, brand-vs-destination mismatch is the tell.