Cloudflare Blocked the Page, But the Email Still Landed: A .vu TLD Phishing Domain That Slipped Through

The phishing page was dead on arrival. Cloudflare had already flagged the domain, slapping an HTTP 403 "Suspected Phishing" interstitial on every request. Anyone who clicked the link would hit a wall.

But the email carrying those links? It landed in the inbox without issue.

This is the gap that defenders need to internalize: blocking a phishing page at the web layer does nothing to prevent the phishing email from being delivered. The mail server never visits the URL. The Cloudflare block only fires when a human clicks, and by that point the social engineering has already done its work.

An Insurance Adjuster With a Vanuatu Domain

The message arrived from tjsclaims@gmail[.]com, claiming to represent "Public Insurance Adjuster LLC." The body invited the recipient to review a "Project Summary" and "Supporting Documentation" through two external links. No recipient name. No account reference. No personalization of any kind.

Both links pointed to ioloo[.]vu, a domain registered under the .vu country-code TLD for Vanuatu. The .vu namespace is one of several obscure ccTLDs that phishing operators have adopted because they fall outside the monitoring scope of most threat intelligence feeds. Blocklists are built from observed abuse patterns, and domains on rarely seen TLDs accumulate fewer reports. A .com hosting a phishing kit would likely be flagged within hours. A .vu domain has a longer runway.

WHOIS data for ioloo[.]vu returned nothing. No registrant, no organization, no contact information. The Anti-Phishing Working Group's Global Phishing Survey has documented the increasing use of non-traditional TLDs in phishing infrastructure, noting that attackers rotate through ccTLDs and new gTLDs to stay ahead of domain reputation systems.

Cloudflare Caught the Page, Not the Email

The first link, hxxps://ioloo[.]vu/sc/index.html, returned a Cloudflare HTTP 403 with a "Suspected Phishing" warning. The second, hxxps://ioloo[.]vu/inv/index.html, showed partial analysis results before the server cut off inspection. Cloudflare's phishing detection had done its job at the web layer: the page was flagged and blocked.

The problem is that web-layer blocking and email-layer blocking are separate systems with no coupling. Mail servers do not fetch every embedded URL and check whether the destination is live, blocked, or flagged. URL scanning at delivery time is an optional feature that some advanced email security tools provide, but it is not universal, and it depends on the engine's ability to follow the link, render the page, and evaluate the result before delivery.

In this case, the email passed through a Barracuda ESS gateway (outbound-ip77a.ess.barracuda[.]com at 209[.]222[.]82[.]241) and reached the recipient's mailbox. The Cloudflare block existed, but nothing in the email delivery path consulted it.

See Your Risk: Calculate how many threats your current gateway is missing

Authentication Failed Across the Board

The authentication results told a consistent story:

• SPF: softfail. The sending IP (209[.]222[.]82[.]241) was the Barracuda gateway, not a Google SMTP server. SPF softfail on a gateway relay is expected behavior when the relay is not included in the sender domain's SPF record.
• DKIM: fail. Specifically, a body hash mismatch. The message body that arrived at the recipient did not match the body hash in the DKIM signature. This can result from the Barracuda gateway modifying the message during processing (appending disclaimers, rewriting links, altering headers) or from deliberate body modification. Either way, the cryptographic integrity of the message content could not be verified.
• DMARC: fail. With both SPF and DKIM failing alignment, DMARC had no passing result to anchor on.

All three authentication mechanisms returned negative results. In a strict enforcement environment, this combination would quarantine or reject the message. In practice, many organizations run DMARC in monitoring mode (p=none) or apply relaxed policies that allow softfail-plus-fail combinations through, especially when gateway relays are involved.

The DKIM body hash mismatch deserves specific attention. A DKIM alignment failure (where the signing domain does not match the From domain) is common and often benign. A body hash mismatch is different: it means the content was altered after signing. Whether that was the Barracuda gateway adding a footer or deliberate modification, the recipient cannot trust that the body content is what the original sender wrote.

The Human Tells That Machines Miss

The attacker's corporate-style signature block claimed "Public Insurance Adjuster LLC" with a street address in Louisiana and a phone number with a Texas area code. Two different Gmail addresses appeared in the signature. These geographic and identity inconsistencies are signals that a human reviewer catches in seconds but that automated tools are not designed to evaluate.

No recipient personalization appeared anywhere in the message. The greeting was generic, the project references vague. For a legitimate insurance adjuster reaching out about a specific claim, the absence of any case number, policyholder name, or property reference would raise immediate suspicion.

Themis, the IRONSCALES Adaptive AI, flagged the message based on the convergence of behavioral signals: a free email provider claiming corporate identity, authentication failures across all three mechanisms, an unfamiliar obscure-TLD domain in the payload links, and the absence of any prior sender relationship with the recipient organization. The message was quarantined before anyone clicked through to the Cloudflare-blocked page.

MITRE ATT&CK Mapping

Indicators of Compromise

What Defenders Should Check This Week

1. Audit URL scanning coverage at the email layer. Determine whether your email security stack evaluates embedded URLs at delivery time or only at click time. Click-time-only scanning means Cloudflare or other web-layer blocks do not prevent the phishing email from reaching the inbox.

1. Review DMARC enforcement posture. This email failed SPF, DKIM, and DMARC. If your organization runs DMARC at p=none or applies broad relay-aware exceptions, messages with triple authentication failure will still reach inboxes.

1. Flag obscure ccTLDs in URL policies. Domains on rarely used country-code TLDs (.vu, .tk, .pw, .cc) appearing in business correspondence are anomalous. Add ccTLD-based heuristics to detection rules, especially when the domain has no WHOIS data and no prior communication history.

1. Train on signature block inconsistencies. A Louisiana address paired with a Texas phone number and two different Gmail addresses in a corporate signature is a cluster of red flags. Phishing simulations with geographic mismatches in sender signatures build the pattern recognition that catches these tells.