# Does PCI DSS 4.0 require DMARC? What requirement 5.4.1 means > PCI DSS 4.0 never names DMARC, but requirement 5.4.1 mandates automated anti-phishing controls — and DMARC, SPF, and DKIM are how most domains meet it. PCI DSS 4.0 does not require DMARC by name. The word "DMARC" appears nowhere in the requirement text. What it does require, in requirement 5.4.1, is that "processes and automated mechanisms are in place to detect and protect personnel against phishing attacks." DMARC, SPF, and DKIM show up only in the standard's guidance as *examples* of anti-spoofing controls that help. So the accurate answer is: DMARC is strongly expected and is the standard way to satisfy the anti-spoofing side of the requirement, but it is neither named nor sufficient on its own. This became a mandatory assessment item on March 31, 2025. ## Quick takeaways - Requirement 5.4.1 is the relevant clause; it mandates automated mechanisms to detect and protect personnel from phishing — it never mentions DMARC. - DMARC, SPF, and DKIM appear in the *guidance column* as example anti-spoofing controls, not as a named mandate. - 5.4.1 was a future-dated requirement that became mandatory for every assessment on **March 31, 2025**. - 5.4.1 protects your *own people* from inbound phishing; DMARC mainly stops others from spoofing *your* domain — related but not identical goals. - Deploying DMARC at enforcement plus SPF and DKIM is the practical, auditor-recognized way to evidence the anti-spoofing part of 5.4.1. ## What does PCI DSS requirement 5.4.1 actually say? Requirement 5.4.1 sits under section 5.4, headed "Anti-phishing mechanisms protect users against phishing attacks." The requirement itself reads: *"Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks."* You can read the wording in the official [PCI DSS v4.0 standard](https://www.pcisecuritystandards.org/documents/PCI-DSS-v4_0.pdf) published by the PCI Security Standards Council. Two words carry most of the weight. **"Automated"** means awareness training alone is not enough — the control has to be a technical mechanism, not just a policy or a quarterly phishing quiz. **"Personnel"** means the requirement is pointed inward: it is about protecting the people who work for the entity handling cardholder data from receiving and acting on phishing, not about protecting your customers or your brand. That inward focus matters, and it is where a lot of the "PCI requires DMARC" shorthand gets loose. DMARC is an outbound-facing control at heart — it stops attackers from putting *your* domain in the From line of mail sent to other people. The overlap with 5.4.1 is real but partial, which is why the standard lists DMARC as an example rather than a mandate. ## Where does DMARC fit if it is not named? DMARC, SPF, and DKIM appear in the *guidance* and examples accompanying requirement 5.4, not in the testable requirement text. PCI DSS separates the requirement (what you must achieve) from guidance (how you might achieve it), and anti-spoofing email authentication is offered as one recognized way to reduce phishing that impersonates trusted domains. The connection is straightforward. A large share of phishing that reaches personnel spoofs a domain the recipient trusts — often the recipient's own employer or a known vendor. [DMARC](/learning/what-is-dmarc) at an enforcement policy (`p=quarantine` or `p=reject`) tells receiving mail servers to reject or quarantine mail that forges your domain, so exact-domain impersonation of your organization stops landing in your own people's inboxes. [SPF](/learning/what-is-spf) and [DKIM](/learning/what-is-dkim) are the authentication checks DMARC builds on. So for the anti-spoofing dimension of 5.4.1, email authentication is the obvious, auditor-familiar answer. The PCI SSC even publishes a [phishing resource guide](https://www.pcisecuritystandards.org/documents/PCI_SSC_Phishing_Resource_Guide_v05.pdf) that walks through email-authentication controls alongside training and reporting. If you want to confirm your own posture first, the [Email Security Score](/tools/email-security-score) checks whether SPF, DKIM, and DMARC are present and at enforcement. ## Is DMARC enough to satisfy 5.4.1 on its own? No. DMARC covers one failure mode — forgery of a domain you control — and 5.4.1 is broader than that. Because the requirement is about protecting personnel from phishing generally, an assessor will expect layered controls that also catch the phishing DMARC structurally cannot see. That gap is the same one that makes email authentication necessary but not sufficient everywhere it appears. DMARC does nothing about lookalike domains the attacker owns, display-name spoofing, or [phishing that passes SPF and DKIM](/learning/why-do-phishing-emails-pass-spf-and-dkim) because it was sent from the attacker's own authenticated domain. A domain at `p=reject` still lets a `yourcompany-invoices.com` message through, since the receiver checks *that* domain's policy, not yours — the same limit covered in [does DMARC stop phishing](/learning/does-dmarc-stop-phishing). To meet 5.4.1 in full, most entities pair email authentication with inbound filtering that scans links and attachments, a reporting path so staff can flag suspicious mail, and — because the requirement says *automated* — technical anti-phishing at the gateway rather than relying on training alone. Automated protection and awareness training are complementary, not interchangeable. ## Who has to comply, and by when? Requirement 5.4.1 applies to any entity in scope for PCI DSS — anyone who stores, processes, or transmits cardholder data, including service providers and, in practice, the [MSPs](/learning/how-do-msps-run-an-email-security-assessment-for-a-new-client) who manage those environments for merchants. Scope follows the cardholder data environment, so if your systems or your client's systems touch card data, the control is in play. On timing: 5.4.1 was one of the requirements marked as a future-dated best practice when PCI DSS v4.0 was published, which meant it was optional during the transition. That grace period ended on **March 31, 2025** — since then it has been a mandatory, testable item in every PCI DSS v4.0 (and v4.0.1) assessment. If your last assessment predates that date, this is a control to close before your next one. Entities using PCI DSS's *customized approach* can meet the objective with alternate controls that a qualified assessor validates against the requirement's stated objective, rather than the defined-approach checklist. That flexibility exists, but for most organizations deploying DMARC, SPF, and DKIM alongside gateway filtering is the least surprising route. ## Common misunderstandings about PCI DSS and DMARC ### "PCI DSS mandates DMARC at p=reject." It does not say that. The requirement mandates automated anti-phishing mechanisms; it does not specify DMARC, a policy value, or any single vendor. Enforcement (`p=quarantine` or `p=reject`) is what makes DMARC actually block spoofing, so it is the sensible target — but that is best practice, not the literal text of 5.4.1. ### "We do annual security awareness training, so we are covered." Training is valuable but does not satisfy the "automated mechanisms" wording on its own. 5.4.1 asks for a technical control that detects and protects against phishing, which training is not. Pair the training with authentication and gateway filtering. ### "DMARC protects our staff from phishing, so 5.4.1 is done." DMARC mainly protects *other people* from mail forging your domain, and it protects your staff only from spoofing of domains you own and enforce. It does not catch lookalike domains, display-name fraud, or attacker-owned domains — so it is one layer of the 5.4.1 answer, not the whole thing. ### "This only matters at our formal assessment." Anti-phishing exposure is continuous, and forged-domain abuse of your brand happens whether or not an auditor is looking. Treat 5.4.1 as an always-on control, not a point-in-time checkbox. ## Frequently asked questions ### Does PCI DSS name a specific DMARC policy value? No. Neither the requirement nor its guidance specifies `p=none`, `quarantine`, or `reject`. Because only `quarantine` and `reject` actually stop spoofed mail, enforcement is the practical target, but the standard leaves the choice to you and your assessor. ### Is SPF or DKIM alone enough for the anti-spoofing part? SPF and DKIM authenticate mail but do not, by themselves, tell receivers what to do with failures — that is DMARC's job. Deploying all three, with DMARC at enforcement, is the configuration that demonstrably reduces exact-domain spoofing. ### Does 5.4.1 apply if we use a customized approach? Yes. The objective still applies; the customized approach only changes how you evidence it. You document alternate controls that meet the requirement's objective, and a qualified assessor validates them. ### Where can I read the exact requirement text? The official PCI DSS v4.0 document is published free by the PCI Security Standards Council. Requirement 5.4.1 sits under section 5.4 in the requirement listing, with DMARC, SPF, and DKIM referenced in the accompanying guidance. Getting your own domains to enforcement is the part Palisade automates: it deploys SPF, DKIM, and DMARC, moves your domains to `p=reject`, and reads the aggregate reports so exact-domain spoofing of your brand is closed and evidenced. It does not replace gateway filtering or training, but it removes the email-authentication uncertainty from a 5.4.1 conversation. Start by checking posture with the [Email Security Score](/tools/email-security-score) or the [DMARC checker](/tools/dmarc). ## Related reading - [Does DMARC stop phishing?](/learning/does-dmarc-stop-phishing) - [Why do phishing emails pass SPF and DKIM checks?](/learning/why-do-phishing-emails-pass-spf-and-dkim) - [How do MSPs run an email security assessment for a new client?](/learning/how-do-msps-run-an-email-security-assessment-for-a-new-client)