PCI DSS 4.0.1 § 5.4.1 Anti-Phishing Checker
Requirement 5.4.1 has been mandatory since 31 March 2025. Check your domain's DMARC, SPF, MTA-STS, TLS-RPT, and DNSSEC posture against the QSA-facing rubric for PCI's anti-phishing automated mechanism.
Why this matters
Requirement 5.4.1 in PCI DSS 4.0.1 was a future-dated requirement from 4.0 that became mandatory on 31 March 2025. The text:
"Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks."
The Council's April 2024 Information Supplement Best Practices for Email Protocol Security spells out the automated mechanism a QSA will look for: DMARC at enforcement, SPF with a hard or soft fail, and DKIM. MTA-STS and TLS-RPT support the transport-side controls under Req 4.2.1.1 and Req 10.4.1. The DMARC Record Checker is the fastest way to confirm your enforcement state before QSA review.
What the QSA tests
QSAs are not required to test technical configurations themselves — they may rely on a control owner's evidence. The standard evidence pack is (a) a screenshot or text export of the DMARC, SPF, and DKIM records, (b) a brief showing the policy at enforcement, and (c) a paragraph on the monitoring process. This tool produces (a) and (b); the paid tier produces (c) on a weekly cadence with the email-gated PDF report.
PCI 4.0.1 requirement cross-walk
| Requirement | Wording | Email-auth control |
|---|---|---|
Req 5.4.1 | Anti-phishing automated mechanism | DMARC enforced + SPF + DKIM |
Req 4.2.1.1 | Strong cryptography on cardholder-data transmission | MTA-STS enforce mode |
Req 10.4.1 | Daily review of security event logs | TLS-RPT (transport-failure telemetry) |
Req 6.4.3 | Integrity of payment-page scripts | DNSSEC (integrity of identity records) |
Scope check — does this apply to you?
Every entity that stores, processes, or transmits cardholder data is in PCI DSS scope. Req 5.4.1 applies to all personnel, not just those with system access — so the anti-phishing mechanism must protect every mailbox in the organisation, not only the CDE. The DNS-borne controls above apply to the domain on which your personnel receive mail, which is usually wider than the CDE itself.
Service-provider and shared-responsibility
If you use a third-party email provider (Google Workspace, Microsoft 365, etc.), Req 12.8 puts third-party DMARC / SPF / DKIM posture under your shared responsibility. Use the SPF flattener to walk the provider's include chain and the DMARC report analyzer to confirm each provider signs the messages they send on your behalf.
What this tool does not cover
Requirement 5.4.1 also calls for "processes" to detect and protect against phishing — security awareness training, sandbox URL inspection, attachment scanning, and reporting mechanisms. Those are organisational and gateway controls outside the scope of this DNS check. Use the scorecard as evidence for the automated-mechanism half of the requirement, not the full Req 5.4.1 control.
Read the complete PCI DSS 4.0.1 guide to learn more.
Get the full picture with DMARCguard
Continuous monitoring, aggregate report parsing, and actionable insights for all your email authentication protocols.
Start Free