Anthem publishes a DMARC policy of p=reject with 100% enforcement. That policy exists for exactly this scenario: an email claiming to be from anthem[.]com that fails every authentication check should be blocked before it reaches an inbox.
SPF returned softfail. DKIM failed on body hash verification. DMARC returned FAIL. The email delivered anyway, because the receiving gateway applied action=oreject instead of a hard reject, overriding the sender's own published policy.
The From header showed Anthem-healthspendingaccounts@anthem[.]com. The Return-Path told a different story: bounces+168366_xrs-...@returnto.alegeus[.]com, pointing to Alegeus, a third-party benefits administration platform. The sending IP 35.174.145[.]124 was not authorized by Anthem's SPF record. The DKIM signature claimed anthem[.]com but the body hash did not verify, meaning the message body had been modified after signing or the signature was never valid.
Three authentication protocols, three failures. The gateway logged the DMARC reject policy and chose not to enforce it. This is the oreject gap: the policy is acknowledged in the headers but treated as advisory rather than mandatory. For any recipient who relies on their gateway to enforce published sender policies, this override is invisible.
The email body carried Anthem branding with a debit card transaction approval notification. Links displayed anthem[.]com as anchor text but every href pointed to secure.wealthcare[.]com/intranet/php/track_url.php with encoded tracking parameters. Avanan (Check Point) link-protection wrappers added another layer of URL rewriting between the displayed domain and the actual destination.
This creates a visual trust gap. The recipient sees anthem[.]com in the link text. The actual destination is a WealthCare tracking wrapper that scanners evaluate as legitimate because WealthCare is a real benefits platform. The HTML also contained duplicated content blocks and broken image references, artifacts of automated template assembly that a manually composed email would never carry.
The most revealing artifact was not in the body or the links. The Report-to mailto header pointed to helpdesk@mesquitegaming[.]com, a casino gaming operation. Delivery reports and feedback for this supposed health insurance notification would route to a gaming company's IT support desk.
This kind of impersonation infrastructure leak is a high-confidence phishing indicator. Legitimate transactional emails from Anthem would never route feedback to an unrelated gaming domain. The header reveals that the actual sending infrastructure belongs to an entirely different organization, and the attacker either reused or compromised that infrastructure without sanitizing the reporting headers.
Themis evaluated the full picture: triple authentication failure against a p=reject policy, a Return-Path pointing to third-party benefits infrastructure, link destinations mismatched from displayed URLs, duplicated HTML blocks, broken images, and a Report-to header pointing to an unrelated industry. No single one of these signals is conclusive. Together, they form a pattern that content scanning and authentication checks alone cannot assess.
The gateway had every signal it needed to block this message. The sender's own DMARC policy said reject. The enforcement decision said otherwise.
See Your Risk: Calculate how many threats your SEG is missing
| Type | Indicator | Context |
|---|---|---|
| From | Anthem-healthspendingaccounts@anthem[.]com | Spoofed Anthem sender |
| Return-Path | bounces+168366_xrs-...@returnto.alegeus[.]com | Alegeus benefits admin infrastructure |
| Sending IP | 35.174.145[.]124 | SPF softfail, not authorized for anthem.com |
| DKIM | Fail (body hash mismatch) | Signature invalid for anthem.com |
| DMARC | Fail, p=reject, action=oreject | Policy overridden at gateway |
| Link Display | anthem[.]com URLs | Anchor text spoofing |
| Link Destination | secure.wealthcare[.]com/intranet/php/track_url.php | WealthCare tracking wrappers |
| Link Protection | Avanan (Check Point) wrappers | Additional URL rewriting layer |
| Report-to | helpdesk@mesquitegaming[.]com | Casino gaming helpdesk, unrelated to health insurance |
| HTML Artifacts | Duplicated content blocks, broken images | Automated template assembly |
| Technique | ID | Relevance |
|---|---|---|
| Phishing: Spearphishing Link | T1566.002 | Links display anthem.com but resolve to tracking wrappers |
| Masquerading: Match Legitimate Name or Location | T1036.005 | Anthem health insurance brand impersonation |
| Phishing for Information: Spearphishing Link | T1598.003 | Debit card notification designed to elicit account interaction |
| Attack | What happened |
|---|---|
| How ARC Re-Signing and an IP Allow-List Turned Three Authentication Failures Into SCL -1 | A phishing email claiming to be a OneDrive share from an outlook.com address originated from a county government mail server. |
| The Phishing Link Lived on a Domain That Didn't Exist Nine Hours Earlier | A compromised university student account sent a phishing email that passed SPF, DKIM, and DMARC. |
| SafeLinks Wrapped the Phishing URL With the Recipient's Name on It | Microsoft SafeLinks rewrote a phishing URL and embedded the recipient's email address into the redirect chain. |
| The Zoho Sign Request That Passed Every Check Except the Reply-To: Government Impersonation via E-Sign Infrastructure | A Zoho Sign document request passed SPF, DKIM, DMARC, and ARC. |
| The Law Firm Name Looked Right Until You Checked the Unicode: Google Drive Debt Collection Phishing | A Google Drive sharing notification impersonated a major law firm using Cyrillic homoglyphs in the display name. |