PCI DSS, the security standard every business that takes card payments must follow, does not name DMARC as a required control. But since 31 March 2025, version 4.0.1 of the standard has required automated anti-phishing measures, and the PCI Security Standards Council names DMARC, SPF, and DKIM in its guidance as approved ways to meet the anti-phishing requirement. So if you handle card payments, you should treat DMARC as expected, even though the standard never names it as mandatory.
Vendor blog posts routinely claim that PCI DSS "requires DMARC." That claim is not quite accurate, and the difference matters during a PCI audit. This article explains what requirement 5.4.1 says, where DMARC fits, and what the people who manage your DNS and compliance need to do. If you take card payments through a website, the work falls to your IT or security team, or to the agency that manages your domain.
Click the links to skip to a specific section.
Not by name. PCI DSS version 4.0.1, the current release of the standard, mandates that organizations put automated anti-phishing mechanisms in place. It does not name a specific technology in the requirement itself. The naming happens in the guidance, where the PCI Security Standards Council writes that anti-spoofing controls such as DMARC, SPF, and DKIM "can help stop phishers from spoofing the entity's domain and impersonating personnel."
So PCI's guidance recommends DMARC; it does not list DMARC as a required control. In practice, the difference between "recommended" and "required" is small here. SPF, DKIM, and DMARC are the standard, documented way to stop domain spoofing, so an assessor looking for automated anti-phishing mechanisms will expect to see them. The practical advice is simple: put DMARC in place, because the assessor will look for it. Do not claim the standard requires DMARC by name, because it does not, and the assessor will know the difference.
The relevant rule is requirement 5.4.1: processes and automated mechanisms must be in place to detect and protect personnel against phishing attacks. The key word here is "automated." Security-awareness training on its own does not satisfy the requirement, because the standard wants a technical control running, not just staff who have been warned.
5.4.1 was published as a future-dated requirement, which meant it was optional while organizations prepared. That grace period ended on 31 March 2025. Since then, the anti-phishing requirement has been mandatory: an assessor checks for it during a PCI DSS assessment, and you can no longer defer it as a best practice.
The guidance also recommends applying anti-phishing controls across your whole organization, not only the systems that store or process card data. DMARC does this by default: a single DMARC policy applies to every address on your domain, so you do not have to extend it system by system.
This is the obvious question, because the standard does not name DMARC. Requirement 5.4.1 is about protecting your people from phishing, so you can meet part of it with other tools: a secure email gateway, an anti-phishing filter, link and attachment scanning, or automated security-awareness training. Most businesses that take card payments already run some of these, and you should keep them.
But those tools only inspect mail as it arrives in your own inboxes. They do nothing to stop an attacker from forging your domain in the From address to phish your customers, partners, or staff. The only practical way to stop that kind of domain spoofing is email authentication: SPF, DKIM, and DMARC working together. There is no real substitute. That is why PCI's guidance names all three, and why an assessor expects to see them even though the requirement never spells them out.
Publishing a DMARC record is not the same as enforcing one, and this is where many businesses fall short of what the requirement is reaching for.
A DMARC record at p=none runs in monitor-only mode. It tells receiving servers to report on mail that fails authentication, then deliver it anyway. You get visibility, which is useful, but a spoofed message claiming to come from your domain still reaches the inbox. Nothing is blocked. As an anti-phishing control, a p=none record stops zero attacks.
To block spoofed mail, you need DMARC in an enforcement mode: p=quarantine sends failing messages to spam, and p=reject rejects them outright. Enforcement is what stops someone from spoofing your domain to phish your customers or staff. PCI does not name a required policy level, so this is our reading, not a line in the standard. But a DMARC record that blocks nothing is hard to defend to an assessor as an anti-phishing control.
This is where most domains are exposed. In DMARCeye's Q1 2026 industry report, of the domains that publish DMARC, 36.7% sit at p=none, 36.8% at p=quarantine, and 26.5% at p=reject. More than a third publish a DMARC record that blocks nothing, because it is set to monitor only. Our full enforcement-gap breakdown has the complete numbers on how many domains never move past monitoring.
Enter your domain to see your current DMARC policy and whether it is set to enforce:
First, identify who owns the DMARC work. Publishing and tightening a DMARC record is a DNS and email-authentication task, not a marketing one. In a larger company it sits with IT or security. In a small business it usually falls to whoever manages your domain: your IT contractor, your web host, or the agency that runs your email and DNS. If you are accountable for PCI compliance but do not manage DNS yourself, your job is to task the right person and confirm it is done before your assessment.
The technical steps, in order:
SPF and DKIM for every service that sends mail as your domain. DMARC depends on both.p=none to start collecting reports without affecting delivery.p=quarantine, then p=reject, once the reports show only senders you recognize. This is the setting that meets the anti-phishing intent.The trap to avoid is jumping to p=reject before you have mapped your senders. Flip enforcement too early and legitimate mail, including the payment receipts your customers are waiting on, starts getting blocked. Our complete DMARC implementation guide walks through the move to enforcement step by step.
PCI DSS is not the only force pushing businesses toward DMARC enforcement. Since 2024, Google and Yahoo have required bulk senders to publish DMARC, and Microsoft has since set the same expectation for high-volume senders into Outlook and Hotmail. The major mailbox providers and the payment standard now ask for the same thing: authenticate your mail, and stop others from spoofing your domain.
For a business that takes card payments and also sends marketing or transactional email, one project covers both obligations. The DMARC enforcement you put in place for PCI is the same control the inbox providers expect. Our guide to the Google and Yahoo sender requirements covers that side in detail.
PCI DSS v4.0.1 did not add DMARC to its list of required controls, and you should be wary of anyone who tells you it did. What it did do is make anti-phishing protection mandatory and point to DMARC, SPF, and DKIM as the way to provide it. What matters most is enforcement: a DMARC record at p=none documents the problem, while p=quarantine or p=reject solves it.
DMARCeye reads the DMARC reports your domain receives and shows you, in plain language, which senders are legitimate and when it is safe to move to enforcement, so the step from monitoring to compliance does not break the mail your customers depend on.