Home · Whitepapers · PCI DSS

Whitepaper · PCI DSS 4.0 · 5.4.1

PCI DSS 4.0 Requirement 5.4.1: anti-phishing and DMARC for payment domains

22 October 2026

PCI DSS 4.0 Requirement 5.4.1 focuses on automated mechanisms that detect and protect against phishing. Payment brands are also judged by whether customers can trust mail that claims the brand. Domain authentication does not replace MFA or training—it removes a cheap impersonation channel and produces evidence assessors can file.

How 5.4.1 touches email

• Reduce successful phishing that leads to cardholder-data compromise.
• Protect personnel and customers from forged corporate identity on payment and support domains.
• Show that anti-phishing controls are operated (reports reviewed, policy staged), not only documented.

Mail-authentication control set

• SPF with -all once includes are complete and under the lookup cap.
• DKIM on every production stream (acquirer notices, customer statements, OTP mail if applicable).
• DMARC at p=reject for the organizational domain after report-driven remediation—including payment and support subdomains.
• MTA-STS / TLS-RPT where transport security for MX hosts matters to your risk assessment (deploy guide).
• BIMI optional after enforcement, as a customer-visible authenticity cue—not a PCI control by itself.

Evidence from Sender Identity

1. Static audit findings and score as a point-in-time DNS reading.
2. Hosted DMARC aggregate-derived sender lists (raw XML discarded after the list is saved).
3. Staged policy approvals with named reviewers for quarantine and reject.
4. Compliance PDF from the current static audit for assessor packets.
5. Webhook or mailbox alerts when new or failing sources appear.

Map these artifacts into your ROC / SAQ narrative as supporting technical evidence for anti-spoofing under 5.4.1 themes—not as a claim that DMARC alone satisfies every 4.0 requirement.

Executive wire fraud still needs isolation beyond brand DMARC; see BEC and Finmail.