When DMARC p=reject Delivers the Phish: A Fully Authenticated Remittance from Hershey's

The email arrived with the subject "Payment Advice Note" and a single instruction: open the attached PDF to view remittance details for a payment made to the recipient's organization. The greeting was "Dear Sir/Madam." No invoice number. No dollar amount. No purchase order reference. No named contact.

The sender address was questionsap@hersheys[.]com. SPF passed. DKIM passed with d=hersheys.com. DMARC passed under a p=reject policy. Microsoft compauth returned pass. The message originated from an internal Exchange host (USDWEST01EXCHYB[.]hersheys[.]com, IP 168[.]133[.]84[.]30) and was relayed through Microsoft 365 outbound protection (CY3PR05CU001[.]outbound[.]protection[.]outlook[.]com).

Every authentication mechanism designed to prevent email spoofing confirmed this message was legitimate. And that is precisely what made it dangerous.

The Authentication Paradox

DMARC with p=reject is the strongest sender authentication policy available. It instructs receiving mail servers to reject any message that fails SPF and DKIM alignment for the domain. Organizations that deploy it, correctly, have taken a significant step toward preventing domain spoofing. Hershey's has it deployed.

But DMARC answers one question: "Was this message sent by infrastructure authorized by the domain?" It does not answer: "Is the content of this message safe?" or "Was the person who sent this message acting with legitimate intent?"

When a message passes DMARC p=reject, compauth, SPF, and DKIM simultaneously, most email security stacks assign it a high trust score. Many organizations explicitly allow-list domains with strong authentication records. The message bypasses content inspection, skips quarantine, and lands directly in the inbox.

This is the gap that account compromise and insider abuse exploit. If an attacker gains access to a legitimately authorized mailbox, or if a misconfigured automated system (the X-Mailer header here reads SAP NetWeaver 758, consistent with ERP-generated messages) is abused, the resulting messages inherit the full authentication posture of the domain. No spoofing required. No domain look-alike needed. The real domain sends the real message through real infrastructure.

The body of this email had several characteristics that would flag it as suspicious in any context other than full authentication:

• Generic salutation with no personalization
• No transaction identifiers (invoice, PO, amount)
• A PDF attachment as the sole call to action
• AP contact addresses (QuestionsAP@hersheys[.]com, ConsultAP@hersheys[.]com, HBPManilaAP@hersheys[.]com) that could not be verified on Hershey's public contact pages

In isolation, each of these is a standard indicator of invoice phishing. Together, they describe a textbook remittance lure. The only thing that separates this from a typical phishing email is that the authentication was real.

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

The PDF and What Remains Unknown

The attached PDF, titled "Payment Advice Note," was approximately 11 KB with MD5 hash 5f77b54bf5550ff2582144ddda31d8fa. The automated scanner returned a clean verdict. However, the analysis sandbox was unable to access the file for deep inspection (PDF stream analysis, embedded object enumeration, JavaScript/OpenAction detection). The clean verdict is therefore low-confidence: absence of evidence is not evidence of absence.

The file pattern, a small PDF presented as a remittance document from a Fortune 500 company, is a common delivery vehicle for credential harvesting forms, embedded URLs pointing to phishing landing pages, or in more sophisticated campaigns, JavaScript that executes on open. Without full sandbox detonation, the precise risk of this specific PDF cannot be confirmed, but the delivery context makes it high-risk regardless of payload.

According to the 2024 Verizon DBIR, pretexting (establishing a plausible business context) has become the dominant social engineering technique, surpassing traditional bait-and-hook approaches. A remittance notice from a recognizable brand with perfect authentication is pretexting at its most effective.

Where Behavioral Analysis Fills the Gap

Themis flagged this message despite the perfect authentication stack. The signals that triggered the flag were behavioral, not protocol-based: the generic greeting in a context where legitimate AP communications are typically personalized, the absence of transaction-specific details, the first-time sender pattern to the recipient mailbox, and the attachment-only call to action with no supporting context in the body.

Community intelligence from the IRONSCALES network contributed additional confidence. Similar fully-authenticated remittance lures from compromised accounts at large enterprises have been observed across multiple organizations. The pattern is consistent: real domain, real authentication, generic body, PDF attachment. Across the network, 67.5 phishing emails per 100 mailboxes per month bypass traditional secure email gateways, and fully authenticated messages from compromised accounts are disproportionately represented in that number.

This attack maps to MITRE ATT&CK T1566.001 (Spearphishing Attachment) for the PDF delivery, T1078 (Valid Accounts) for the use of a legitimate, authenticated sending account, and T1199 (Trusted Relationship) for leveraging an established vendor relationship as a trust anchor.

The Uncomfortable Implication

If your security stack treats DMARC p=reject as a green light, this email reaches the inbox every time. The authentication is not broken. The authentication is working exactly as designed. The problem is that authentication was never meant to be a content safety guarantee, and treating it as one creates a blind spot that threat actors have learned to exploit.

Defenders should evaluate whether their gateway configurations implicitly trust fully authenticated senders. Domain reputation and authentication should inform scoring, not override content and behavioral analysis. And organizations that receive remittance notices from large vendors should have out-of-band verification procedures that do not rely on contact information provided in the email itself.

Indicators of Compromise