If you process card data, PCI 5.4.1 expects anti-phishing controls that actually enforce or quarantine. Monitor-only DMARC is visibility, not protection.
PCI DSS 4.0.1 turned the future-dated anti-phishing requirement into an active control on 31 March 2025. Requirement 5.4.1 is short: processes and automated mechanisms must be in place to detect and protect personnel against phishing attacks.
The important part is the guidance underneath it. The standard expects automated mechanisms that detect and prevent or quarantine phishing attempts, and it names DMARC, SPF, and DKIM as examples. That does not make a single DNS record the whole control. It makes sender authentication one of the mechanisms an assessor can reasonably ask to observe.
What 5.4.1 is protecting
This control is aimed at the people inside the cardholder data environment, not just at customers receiving mail from your brand. The scenario is straightforward: an attacker impersonates a finance leader, a help-desk workflow, or a trusted vendor, and someone with access to cardholder-data systems follows the instruction.
In practice, the control splits into two halves:
- Inbound protection - the mail systems that deliver to personnel detect, quarantine, rewrite, sandbox, or otherwise handle phishing attempts.
- Outbound non-spoofability - domains your organization owns cannot be cheaply impersonated because SPF, DKIM, and DMARC are aligned and enforced.
The second half is where most PCI evidence packages are thin. A gateway screenshot proves one thing. It does not prove that an attacker cannot spoof a forgotten domain you registered for an old campaign.
What assessors usually ask to see
The testing procedure is observation-heavy: documented policies, procedures, and implemented anti-phishing mechanisms. For the email-authentication side, that usually means evidence that the domain estate is known, monitored, and moving toward enforcement where mail is legitimate.
- An inventory of every owned sending and non-sending domain.
- DMARC records at p=quarantine or p=reject on production domains.
- A subdomain policy that does not leave a broad sp=none loophole.
- DKIM signing for authorized senders, with 2048-bit keys where supported.
- SPF records that stay within the 10-DNS-lookup limit.
- Aggregate DMARC reports collected, reviewed, and tied to sender decisions.
The last point is the one that changes the conversation. The DNS record is configuration. The report stream is operating evidence. It shows which systems are sending, which ones align, and what changed after a vendor or business unit connected a new mail source.
Two common gaps
Monitor-only forever. A domain at p=none can be useful during discovery, but it is not preventing or quarantining spoofed mail. If the organization has lived there for months, the likely finding is simple: there is visibility, but not much protection.
Legacy domains outside the inventory. Most card-processing organizations have domains from acquisitions, defensive registrations, regional campaigns, or abandoned product names. Attackers do not need the main domain if a related domain has no DMARC record. The evidence package has to cover the estate, not just the primary sender.
The package that avoids follow-up questions
A clean package has three artifacts: a current-state domain inventory, a change log for DNS and sender updates, and an exception register for authorized services. The exception register matters because it turns "SendGrid appeared in the reports" into a decision: owned sender, vendor to fix, or unauthorized source.
- Who owns each sender and each DNS change?
- Which domains are intentionally non-sending?
- What is the rollback path if enforcement catches a legitimate sender?
- What happens when a new unaligned source appears in rua data?
That is also where DMARC reporting becomes more than a compliance checkbox. It gives the assessor a defensible trail: the organization saw the source, classified it, fixed alignment or blocked it, and kept watching.
What 5.4.1 does not require
- BIMI. Useful for brand display once DMARC is enforced, but not a PCI requirement.
- MTA-STS or TLS-RPT. Important for transport security, but a different control problem.
- A specific vendor. PCI is outcome-focused. Tooling helps, but the control is the implemented mechanism and the evidence behind it.
Where DMARCify fits
DMARCify is not a PCI consultancy. It is the system that turns raw aggregate reports into the inventory, source classification, change history, and enforcement path that the email side of 5.4.1 depends on. For teams heading into an assessment, the work is usually practical: collect reports, fix alignment for known senders, lock down parked domains, and move policy through the same ramp described in the p=reject playbook.