PCI DSS DMARC Requirement: What Section 5.4.1 Requires (and What It Doesn’t)

The PCI DSS DMARC requirement is the question every IT admin asks before a payment audit — and the honest answer is more precise than most vendor pages admit. Most vendor pages round the standard up to “PCI requires DMARC”; the standard says something narrower, and the difference decides what your assessor can and cannot demand of you. So does PCI DSS require DMARC? Not by name. In practice, it is the control your assessor expects you to point to, because it is the example the standard itself gives.

This guide is for the IT manager, DevOps lead, or compliance owner staring down a PCI assessment and trying to separate what the standard says from what vendor blogs claim it says. It answers three questions in order: what Requirement 5.4.1 says, verbatim; what your Qualified Security Assessor (QSA) will accept as evidence; and what to do in the next 30 days if the assessment is already on the calendar. Everything here is quoted from the standard itself — not a paraphrase — and keeps the example-versus-mandate distinction straight, because that distinction is exactly what competitor guidance overstates. For the protocol-by-protocol reference with a DNS record at every step, start with our PCI DSS protocol reference.

Does PCI DSS require DMARC? What Requirement 5.4.1 says, verbatim

Not by name. Section 5.4.1 is new in v4.0 and has no equivalent in v3.2.1 — it is one of the headline PCI DSS 4.0 changes. The §5.4 heading reads: “Anti-phishing mechanisms protect users against phishing attacks.” The requirement itself is short and binding:

“Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.”

— PCI DSS v4.0.1, Requirement 5.4.1 (Defined Approach)

That is the entire binding text, sourced directly from the PCI DSS v4.0.1 standard in the PCI SSC Document Library. Notice what it does not say: it names no protocol, no vendor, and no policy level. The anti-phishing mandate is written as an outcome — automated mechanisms that detect and protect — and the choice of mechanism is left to you.

DMARC enters only in the Guidance column that accompanies the requirement:

“When developing anti-phishing controls, entities are encouraged to consider a combination of approaches. For example, using anti-spoofing controls such as Domain-based Message Authentication, Reporting & Conformance (DMARC), Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM) will help stop phishers from spoofing the entity’s domain and impersonating personnel.”

— PCI DSS v4.0.1, Requirement 5.4.1 Guidance

The timeline is the other half of the answer. Section 5.4.1 was classified as a best practice until 31 March 2025; the applicability note in the standard reads: “This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.” It was one of the future-dated requirements introduced in v4.0 that became mandatory on that date. v4.0.1 did not move it: the PCI SSC’s v4.0.1 release announcement confirms that the limited revision added no requirements and left the 31 March 2025 effective date unchanged.

Two neighboring controls get conflated with 5.4.1. Requirement 12.6.3.1 is the security-awareness training that teaches personnel to recognize phishing; PCI DSS 4.0 requires both, and the standard is explicit that 5.4.1 is not satisfied by awareness training alone — DMARC and its peers address the technical side, training the human side. The general “PCI DSS Requirement 5” anti-malware controls are the other source of confusion; 5.4.1 is the distinct sub-requirement that governs phishing and email spoofing.

What will your QSA accept as DMARC evidence for 5.4.1?

Start with the version, because it decides which text your assessor holds you to. PCI DSS v4.0.1, published 11 June 2024 by the PCI Security Standards Council (PCI SSC), is the only active version: v3.2.1 was retired on 31 March 2024, v4.0 on 31 December 2024, and v4.0.1 itself added and deleted no requirements and changed no effective dates. Scope follows the cardholder data environment (CDE) — the systems that store, process, or transmit payment card data, plus anything connected to them. How the 12 principal requirements and 6 control objectives fit together, and where Requirements 4 and 5 sit among them, is mapped on the learn page’s v4.0 overview.

The standard then gives you two routes to compliance. Under the defined approach you implement the control as written, and your assessor confirms that automated anti-phishing mechanisms exist and function. Under the customized approach you meet the stated security objective with controls of your own design, backed by a documented targeted risk analysis that your QSA validates. Either path is valid; neither requires DMARC by name. In practice, the named example controls are what auditors expect to see.

How do practitioners read it? Jeremy Simon — a PCI QSA (CISSP, CISA) and PCI compliance practice lead at HALOCK Security Labs — reproduces the 5.4.1 Guidance verbatim and cautions that passing an SAQ checkbox is not the same as full DSS compliance: the DSS itself is what every organization ultimately has to meet. That is the closest thing to a primary-adjacent assessor voice on the question.

Vendors who sell DMARC tooling go a step further, and their advice is worth reading as directional opinion rather than as the standard. Skysnag and Proofpoint both advise demonstrating an enforcement policy — p=quarantine or p=reject — on the reasoning that a monitoring-only record does not actively protect personnel. They are vendors with a commercial interest in DMARC adoption, so treat “auditors expect enforcement” as an expectation, not a clause. Notably, even PowerDMARC’s own guidance concedes the legal position: DMARC “is not mandated or otherwise required by the PCI DSS.” Achieving DMARC compliance, then, is about meeting the anti-phishing objective with controls you can evidence — not about satisfying a named mandate.

This is the correctness differentiator. Several competitor pages frame Section 5.4.1 as “DMARC is required” or “you must move to p=reject.” The primary text supports neither claim. DMARCguard aligns with what the standard actually says, and the table below separates the three layers — what is required, what is expected, and what is overstated:

The evidence request is consistent from one assessment to the next. Have these four artifacts ready and the example-versus-mandate debate becomes academic — you can show the mechanism works:

• The SPF, DKIM, and DMARC DNS records for every in-scope domain.
• The enforcement policy in effect, with the dates you moved between policy levels.
• The aggregate and forensic reporting you collect.
• Proof that someone reviews those reports and acts on them — ongoing monitoring, not an unread mailbox.

Is email in scope, and what does non-compliance cost?

Email is usually in scope, and the penalty figures you have read are less precise than they look. Take scope first. Email is the primary delivery vector for the phishing and business-email-compromise (BEC) attacks Section 5.4.1 targets. Without sender authentication, an attacker can spoof your exact domain to phish the employees who touch the cardholder data environment — requesting fraudulent payments, redirecting invoices, or harvesting credentials. The financial scale is documented: the FBI’s Internet Crime Complaint Center (IC3) attributed $2.77 billion in reported losses to BEC in 2024.

PCI compliance for email systems is in scope more often than teams expect. PCI DSS scope extends to any system connected to the CDE, and email infrastructure usually qualifies because employees with CDE access use email to coordinate transactions, share reports, and communicate with payment processors. If an attacker spoofs your domain to phish one of those employees, the mailbox becomes the entry point to cardholder data — which is precisely the threat 5.4.1 asks you to detect and protect against.

The common compliance gap is structural: organizations pass their PCI assessment on network segmentation, access control, and encryption, yet publish no email authentication at all. That gap is the norm, not the exception.

In the same February 2026 scan of 5,499,028 domains, only 30.4% published a DMARC record at all, and 40.8% had no email authentication of any kind — no SPF, no DKIM, no DMARC. For an auditor, a p=none record is the relevant trap: it shows intent to monitor but does not actively protect personnel, which is the verb the requirement uses. The majority of domains that have adopted DMARC are sitting in exactly that incomplete state.

A word on penalties, because the figures get repeated loosely. PCI DSS is a contractual obligation, not statutory law, and the PCI SSC levies no fines itself. The card brands set the rules and fine the acquiring bank, which passes the cost to the merchant by contract. Advisory and vendor sources widely cite a range of $5,000 to $100,000 per month for non-compliance, but that figure cannot be traced to any published Visa or Mastercard operating regulation — the actual amounts are contractual and non-public, and they vary by acquirer. Just as important: no fine attaches to Requirement 5.4.1 or to email authentication specifically. Penalties follow overall non-compliance status or a breach event, never a single requirement. The often-cited Target, British Airways, TJX, and Equifax figures are breach settlements and regulatory actions, not PCI 5.4.1 fines. Treat any “fail DMARC and pay $X” claim as inference, not established fact.

Which protocols satisfy Section 5.4.1? DMARC, SPF, and DKIM

SPF authorizes the servers that may send for your domain, DKIM cryptographically signs each message, and DMARC ties both to the visible From domain and sets an enforcement policy — together they are the example anti-spoofing stack the 5.4.1 Guidance names. SPF (Sender Policy Framework, RFC 7208) publishes in DNS the hosts authorized to use the domain in the MAIL FROM identity (RFC 7208 §1.1.3), so an unauthorized sender fails the check — the detect half of the requirement. DKIM (DomainKeys Identified Mail, RFC 6376) attaches a signature via the DKIM-Signature header (RFC 6376 §3.5) that fails verification if the message was altered in transit or sent by an unauthorized party. DMARC (Domain-based Message Authentication, Reporting & Conformance, RFC 9989) requires an SPF- or DKIM-authenticated identifier to align with the visible From domain (RFC 9989 §4.4), applies a published policy of none, quarantine, or reject (RFC 9989 §4.7), and emits aggregate and forensic reports. Alignment plus enforcement is what turns “we publish records” into “spoofed mail is rejected.”

DMARC enforcement at p=quarantine or p=reject demonstrates the strongest posture for an assessor, because it actively protects personnel. A policy of p=none shows monitoring intent only — useful while you ramp, but, as the data above shows, the state most domains never move past. The DNS record for each protocol, with a worked example, is in the learn page’s protocol mapping.

Does PCI DSS regulate email encryption too? Requirement 4.2.2

Yes — and it is the requirement most DMARC guides skip entirely. PCI DSS also governs cardholder data in transit: Requirement 4.2.2 requires that primary account numbers (PAN) be secured with strong cryptography whenever they are sent via end-user messaging technologies like email, which is squarely relevant to any organization whose mailboxes touch payment data.

The §4.2 heading reads: “PAN is protected with strong cryptography during transmission.” The specific messaging clause is 4.2.2:

“PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.”

— PCI DSS v4.0.1, Requirement 4.2.2

The standard defines end-user messaging technologies as email, instant messaging, SMS, chat, and the like, and its testing procedure expects PAN to be rendered unreadable or secured with strong cryptography whenever it is sent that way. (Requirement 4.2.1 is the adjacent control: it governs strong cryptography for transmission over open, public networks generally, including a certificate-validity bullet that was itself a best practice until 31 March 2025.)

Email transport is where this gets technical. Standard SMTP encryption is opportunistic by default — if a TLS handshake fails, mail often falls back to plaintext, and an active attacker can force that downgrade. Three protocols close the gap:

• MTA-STS (RFC 8461) publishes a policy that tells sending servers to require TLS when delivering to your domain and to refuse cleartext fallback, defeating downgrade attacks.
• TLS-RPT (RFC 8460) delivers reports when a sending server cannot establish a TLS connection, giving you the visibility to prove encrypted delivery is actually working.
• DANE (RFC 6698 / 7672) uses DNSSEC to pin mail-server certificates directly in DNS, removing sole reliance on the public certificate-authority system.

If your email systems handle, reference, or transmit cardholder data, deploying both sets of protocols strengthens your posture across two requirements rather than one — and it closes a gap most assessments never even probe. Two DNS records start the Requirement 4 coverage:

_mta-sts.example.com    IN  TXT  "v=STSv1; id=20260723"
_smtp._tls.example.com  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Host the policy file at https://mta-sts.example.com/.well-known/mta-sts.txt with mode: enforce.

What should you do in the next 30 days?

If the assessment is already on the calendar, aim to walk in with four things: published SPF, DKIM, and DMARC records on every in-scope domain; a sender inventory; an enforcement ramp that has demonstrably started; and an evidence pack. A clean run at p=reject is the strongest position, but a deliberate, dated ramp is what the “detect and protect” language asks you to show, and each of the four is reachable inside 30 days from a standing start. The DNS record for every step below, including the Requirement 4 records, is in the learn page’s step-by-step walkthrough. Start with the records themselves:

dig TXT _dmarc.example.com
dig TXT example.com                      # SPF record
dig TXT default._domainkey.example.com   # DKIM record

Under DMARCbis (RFC 9989), the pct tag is removed from the specification and listed as historic (Appendix A.6), so the staged-percentage rollout older guides describe no longer applies. Ramp by policy level instead; the testing tag t=y tells receivers to apply the policy one level below the one you publish while you validate.

What do assessors flag most often on 5.4.1?

Four findings account for most 5.4.1 write-ups: DMARC left at p=none indefinitely (monitoring intent is not the “protect” the requirement asks for); no sp= subdomain policy, which leaves payments.example.com spoofable behind a p=reject organizational domain; SPF broken past the 10-DNS-lookup limit of RFC 7208 §4.6.4, where a permerror fails authentication for all your mail; and the requirement treated as optional because the Guidance says “for example” — the inverse of the vendor overstatement, and one that will not survive an assessment. Third-party senders without DKIM signing, reports emitted into an unread mailbox, and Requirement 4 ignored entirely round out the list. The 30-day plan above prevents all seven; the full list with fixes is in the learn page’s common audit mistakes.

Frequently asked questions before your PCI assessment

Does PCI DSS 5.4.1 name DMARC as a required control?

Not specifically. Requirement 5.4.1 mandates automated anti-phishing mechanisms, and its Guidance column names DMARC, SPF, and DKIM as example anti-spoofing controls — not required technologies. The mechanisms became mandatory on March 31, 2025, but the standard names no single required protocol, and a customized approach is permitted.

Is DMARC mandatory for PCI DSS 4.0?

Anti-phishing controls became mandatory on March 31, 2025, but PCI DSS names no single required technology. DMARC, SPF, and DKIM are cited only as examples in the 5.4.1 Guidance column. Some vendor pages overstate this as DMARC being required; the primary standard does not.

What does Requirement 5.4.1 actually say?

Section 5.4.1 requires processes and automated mechanisms to detect and protect personnel against phishing attacks. New in v4.0, it has no v3.2.1 equivalent and is explicitly not satisfied by security-awareness training alone — that is a separate requirement, 12.6.3.1.

When did the PCI DSS anti-phishing requirement take effect?

Section 5.4.1 was a best practice until March 31, 2025, after which it became required and must be fully considered during every assessment. PCI DSS v4.0.1, published June 2024, did not change that effective date.

Is DMARC alone enough for PCI compliance?

No. The standard expects a combination of approaches — anti-spoofing controls plus malware and URL protection and awareness training. DMARC is one component of 5.4.1 and does not, by itself, satisfy the requirement or the broader anti-phishing program.

What DMARC policy do I need for PCI?

The standard specifies no policy level. QSAs and vendors recommend an enforcement policy (p=quarantine or p=reject) over p=none because it actively protects personnel, but p=reject is not a PCI requirement. Choose enforcement to demonstrate a stronger posture.

Can I send credit card numbers (PAN) by email?

Not unprotected. Under Requirement 4.2.2, PAN sent via end-user messaging must be rendered unreadable or secured with strong cryptography. The best practice is a policy banning PAN over email, instant messaging, SMS, and chat entirely.

What happens if I don’t comply, and who enforces fines?

PCI DSS is contractual, not statutory. The PCI SSC issues no fines; card brands penalize your acquiring bank, which bills you. Advisory sources widely cite $5,000–$100,000 per month, but no primary card-brand document publishes that range, and no fine attaches to 5.4.1 specifically — amounts are contractual and non-public.

PCI DSS Email Authentication: The Bottom Line

The PCI DSS DMARC requirement is best understood as an outcome, not a checkbox:

• Section 5.4.1 mandates automated anti-phishing mechanisms — in force for every assessment since March 31, 2025.
• DMARC, SPF, and DKIM are the named examples, living in the Guidance column, not the binding requirement. No protocol and no policy level is mandated.
• Enforcement plus documentation is what assessors want — p=quarantine or p=reject, an aggregate-report trail, and a sender inventory.
• Requirement 4.2.2 covers PAN over email — pair MTA-STS and TLS-RPT with your anti-phishing stack if mailboxes touch cardholder data.

The same technology-neutral pattern shows up across every modern compliance regime: a mandate states an outcome, and email authentication is how you meet it. See the NIS2 email-security control map for the EU essential-and-important-entity angle, HIPAA email authentication for the US healthcare §164.312 mapping, and DORA email authentication for the EU financial sector — one control stack, cited three ways.