Skip to main content
PCI DSS 4.0.1

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

RequirementWordingEmail-auth control
Req 5.4.1Anti-phishing automated mechanismDMARC enforced + SPF + DKIM
Req 4.2.1.1Strong cryptography on cardholder-data transmissionMTA-STS enforce mode
Req 10.4.1Daily review of security event logsTLS-RPT (transport-failure telemetry)
Req 6.4.3Integrity of payment-page scriptsDNSSEC (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.

Get the full picture with DMARCguard

Continuous monitoring, aggregate report parsing, and actionable insights for all your email authentication protocols.

Start Free