When the Email Passes Every Auth Check but Still Isn't Real

Passing every email authentication check is not the same as being trustworthy. An attacker who registers the right domain can make SPF, DKIM, and DMARC all return pass while sending a message that has nothing to do with the brand it impersonates. That is precisely what happened when a law firm received a membership-renewal notice purportedly from the International Bar Association (IBA).

The Setup: A Domain Built to Fool at a Glance

The International Bar Association runs its operations from ibanet.org. The attacker registered int-bar[.]org, three characters and a hyphen rearranged, plausible enough at a glance in a From header when the recipient is not actively scrutinizing the address.

The message arrived in the mailbox of an attorney at the firm. Subject line: "Action required: Your membership is due to expire." Sender display name: a generic "membership team" alias. From address: ibatest@int-bar[.]org.

Nothing in the header looked broken. That was the point.

Authentication: All Green, Zero Assurance

The authentication chain tells a precise story:

• SPF pass: int-bar[.]org had SPF records designating Mimecast's relay infrastructure as a permitted sender. The email arrived through eu-smtp-delivery-231[.]mimecast[.]com, which matched.
• DKIM pass: A valid DKIM signature was present with d=int-bar[.]org. The message was cryptographically signed and the signature verified.
• DMARC pass, action=none: The From header and the verified DKIM domain both said int-bar[.]org. Alignment confirmed. DMARC had no policy quarantine or reject configured, so even a failure would have been advisory only. As it was, the result was a clean pass.

What authentication proved: the sender controlled int-bar[.]org and had properly configured its mail infrastructure. What authentication did not prove: any relationship between int-bar[.]org and the IBA or its legitimate domain ibanet.org. DMARC is a domain-ownership verification protocol. It has no cross-domain brand-alignment mechanism. Owning a plausible lookalike domain, configuring it correctly, and clicking send is sufficient to pass it.

This is not a vulnerability in SPF, DKIM, or DMARC. It is a hard boundary on what those protocols were ever designed to check. Defenders who treat a DMARC pass as a trust signal are trusting the wrong thing.

The Body: Legitimate Links, Attacker Reply Path

The message body was a polished membership-renewal notice. It addressed the attorney by first name, referenced a December 31 expiration deadline, and displayed payment card logos from Visa, Mastercard, American Express, UnionPay, Discover, and others under a prominent "Auto-renew Membership" button.

Every link in the email resolved to pages on the real IBA website: www.ibanet[.]org/login, www.ibanet[.]org/my-account/adyen-payment-details/view, www.ibanet[.]org/privacy-policy. Screenshots captured at scan time confirmed each destination as the legitimate IBA site. Link scan verdicts across all seven URLs: clean.

This is a deliberate layering technique. Pointing links at the real brand site accomplishes two things: it defeats URL-reputation scanning (no malicious destination to flag) and it builds enough visual legitimacy that a recipient who hovers over the links sees nothing wrong. The intended fraud path runs through what happens after the recipient engages: replies routed back to ibatest@int-bar[.]org, payment disputes handled by the attacker's support contact, account actions taken in a conversation thread the attacker controls.

The attacker does not need a fake harvest page when the reply-to path is the hook.

Two tells broke the polish: the raw HTML contained an unrendered template variable (${ctx.headline} visible in the source), and the message body repeated an entire content block. The member-benefits list and CTA appeared twice. Neither flaw surfaces obviously in a rendered preview, but both signal a hurried or automated send from infrastructure the attacker assembled rather than a legitimate platform.

How It Was Caught

The attorney's organization ran IRONSCALES. Adaptive AI flagged the message not because authentication failed (all three checks passed) but because the combination of signals did not fit legitimate sender behavior:

• First-time sender. No prior sending relationship between int-bar[.]org and the organization existed.
• Brand-domain misalignment. The message claimed to be IBA but arrived from a domain with no relationship to ibanet.org.
• High-risk payment call-to-action. A membership-renewal prompt with payment card references from an unknown sender is a behavioral pattern associated with credential harvesting.
• Content scoring. Microsoft's own spam confidence level (SCL) scored the message at 5, suspicious but not conclusively blocked, and it landed in the junk folder. IRONSCALES' detection ran independently of that disposition.

The message was flagged as phishing with a credential theft label. It was moved to junk and later automatically resolved. The attorney was not prompted to enter payment details on a site the attacker controlled.

Is your gateway catching the authenticated lookalike attacks that are slipping through? Find out what your current setup is missing.

The Detection Gap

Security teams that anchor on "SPF/DKIM/DMARC passed" as a trust signal are the target audience for this technique. The attacker invested in legitimate infrastructure: a registered domain, proper DNS records, a Mimecast relay account. All of it was configured specifically to clear the authentication bar. The sophistication is not in the payload. It is in the setup that makes the payload invisible to authentication-dependent filters.

DMARC enforcement at the receiving organization will not help here. The sending domain passes DMARC on its own terms. The fix is not a stricter DMARC policy at the victim end. It is detection that treats authentication as one input among many, not as the final word on whether a sender is trustworthy.

A first-time sender claiming to be the membership team of a global professional association, bearing a payment call-to-action, arriving from a domain registered to look like that association's domain: each of those signals individually is weak. Combined, they constitute a pattern that behavioral analysis can catch even when the header stack is spotless.

That combination is what IRONSCALES is built to evaluate: not just whether an email authenticated, but whether it behaved like what it claimed to be.

Indicators of Compromise

MITRE ATT&CK: T1566.002 - Phishing: Spearphishing Link; T1566 - Phishing

References

• Verizon 2026 Data Breach Investigations Report - credentials involved in 39% of breaches; phishing as initial access in 16% of cases
• MITRE ATT&CK T1566.002 - Spearphishing Link
• MITRE ATT&CK T1566 - Phishing
• CISA: Phishing Guidance
• NIST Glossary: Phishing