PCI DSS compliance

PCI DSS 4.0 and DMARC: What Compliance Teams Need to Know [2026]

TL;DR. PCI DSS v4.0.1 Requirement 5.4.1 — anti-phishing technical controls — became mandatory on March 31, 2025. The requirement itself is a must. DMARC specifically is named in the Good Practice / Guidance column as an example of how to satisfy 5.4.1 — a should. In practice, experienced QSAs are treating DMARC as effectively required because the alternatives are hard to defend at audit. The honest answer is: 5.4.1 is binding, DMARC isn't literally mandated, and you should still implement DMARC at p=quarantine or stronger with active monitoring before your next assessment.

If you landed here, you're either scoping a PCI DSS 4.0 compliance project and trying to figure out whether DMARC is in scope, or you've got a QSA visit on the calendar and you need a documented answer for the email-authentication question. Both audiences need the same things: the actual text of the standard, an honest read of how it gets enforced, and a checklist that maps to what your auditor will ask.

We're a DMARC vendor — we'll say so at the bottom — but the credibility move on this page is regulatory honesty. Sites that tell you DMARC is a “PCI DSS hard requirement” are technically wrong, and your QSA will notice.

What PCI DSS 4.0 actually says about DMARC

PCI DSS v4.0 introduced a new family of anti-phishing requirements. The active version as of 2026 is PCI DSS v4.0.1, published by the PCI Security Standards Council in June 2024. The relevant control is Requirement 5.4, “Anti-phishing mechanisms protect users against phishing attacks,” and specifically sub-requirement 5.4.1.

The verbatim text from the Council's official document, pages 132–133:

Defined Approach Requirement 5.4.1: “Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.”

Defined Approach Testing Procedure 5.4.1: “Observe implemented processes and examine mechanisms to verify controls are in place to detect and protect personnel against phishing attacks.”

Customized Approach Objective: “Mechanisms are in place to protect against and mitigate risk posed by phishing attacks.”

Applicability Notes: “The focus of this requirement is on protecting personnel with access to system components in-scope for PCI DSS … 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.”

Good Practice (Guidance): “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.”

Source: Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0.1, PCI Security Standards Council, June 2024, pages 132–133.

Three things to notice. First, the requirement itself does not name DMARC. It says “processes and automated mechanisms … to detect and protect personnel against phishing attacks” — DMARC is one technology that satisfies this; so are link scrubbers, server-side anti-malware, and sandboxed link rewriting. Second, DMARC, SPF, and DKIM are explicitly named — together — in the Good Practice column as the canonical anti-spoofing example. The Council picked DMARC out of the universe of anti-phishing controls and named it. That is not nothing. Third, the requirement crossed from “best practice” to “required” on March 31, 2025. As of 2026, it is fully enforceable.

Should vs must — the audit reality

PCI DSS organizes every requirement into two implementation paths: the Defined Approach (the prescriptive control listed in the standard, implemented as written) and the Customized Approach (an alternative control that meets the same Customized Approach Objective, which the entity documents and the QSA must validate). Both are legitimate. The Defined Approach is faster to audit; the Customized Approach is slower because you have to convince the QSA that your alternative is at least as effective.

For 5.4.1, the Defined Approach Requirement is binding (must) as of March 31, 2025. DMARC specifically is not in the Defined Approach Requirement — it sits in the Good Practice column as an example. Reading the standard literally, you can satisfy 5.4.1 without DMARC if you have other technical controls that detect and protect personnel against phishing.

Reading the standard the way QSAs actually enforce it, two things matter. The Council named DMARC, SPF, and DKIM in Good Practice on purpose; when the standard names a specific technology there, QSAs use that as the default expectation. If you propose an alternative, you carry the Customized Approach burden — written rationale, threat model, and effectiveness measurement that your QSA has to accept. And the alternatives are hard to justify in isolation: server-side anti-malware and link scrubbers don't prevent an attacker from sending email as your domain to your CDE personnel. That's the scenario the Council is most worried about, and DMARC is the only widely deployed control that addresses it directly.

So the honest framing is: the requirement is must, DMARC is should, and in practice the should is being treated as a must. If you're building a 4.0.1 project plan, put DMARC in scope. If you're heading into an audit without it, expect to argue for your Customized Approach.

Which DMARC posture satisfies PCI DSS

The standard does not specify a DMARC policy value. It names DMARC as an example of an anti-spoofing control, which means the bare minimum reading is “you have a DMARC record.” Auditors don't read it that bare-minimum-ly. Here's the operating range we see in practice.

p=none is unlikely to satisfy a well-prepared QSA. It publishes a DMARC record but instructs receivers to take no action on failures. It surfaces aggregate reports — useful, and the right starting place when you're discovering your sender ecosystem — but it does not stop spoofed email from reaching your personnel. The phrase that matters in 5.4.1 is “detect and protect.” p=none detects. It does not protect.

p=quarantine with rua= reporting and active monitoring is the floor. Receivers route unauthenticated mail claiming to be from your domain into the spam folder. Combined with aggregate reports flowing to a monitored destination, this is the minimum posture we'd defend at audit. Documentation needs to show reports are reviewed — not just received — and misalignment incidents are triaged.

p=reject with monitoring is the strongest defensible posture. Receivers drop unauthenticated mail outright. From a control-effectiveness standpoint, this is what 5.4.1 is gesturing at. From an audit standpoint, it's also the easiest to document.

The migration path most teams underestimate is the move from p=none to enforcement. We cover that — including the staged pct= ladder and the evidence to gather before each step — on /learn/p-quarantine-vs-p-reject.

Scope question: which domains are in PCI scope?

This is the question that derails the most compliance projects. PCI DSS 4.0 doesn't enumerate which domains belong in scope for 5.4.1; the scoping logic falls out of the broader Requirement 5 and CDE definitions. Here's the framing that survives audit:

Any domain that sends email referencing the cardholder data environment is in scope. Receipts, invoices, fraud alerts, payment confirmations, dispute notifications — anything that exists because cardholder data exists.

Any domain whose impersonation could enable phishing against personnel with CDE access is in scope. Your corporate domain — the one your CDE administrators read email at — is the highest-value impersonation target, even if no cardholder data ever flows through it. If accounts@yourcompany.com can be spoofed to your DBAs, that's a phishing pathway into the CDE.

In practice, most orgs end up with a scoped list that includes the primary corporate domain plus aliases, customer-facing transactional sending domains (receipts.example.com, notifications.example.com), marketing sending domains where they share brand identity, and the subdomains of all of the above.

Parked domains you own but never send from matter too. Publish p=reject and an empty SPF (v=spf1 -all) — it's an hour of work and it prevents attackers from using your inventory as spoof origins.

Implementation checklist

Use this as a yes/no walk-through before your assessment. If you can answer yes to all of these, you're in defensible shape for 5.4.1.

1. Have you published SPF, DKIM, and DMARC records on every in-scope domain? All three. SPF and DKIM alone are not DMARC. DMARC alone is not DMARC — it depends on SPF and/or DKIM passing and aligning.
2. Is your DMARC policy at p=quarantine or stronger on every in-scope domain? p=none will be flagged. If you're still at p=none for legitimate transition reasons, document them and have a calendar date for moving to enforcement.
3. Is rua= aggregate reporting flowing to a monitored destination? A reporting endpoint that nobody reads is worse than no reporting at all because you're carrying the audit liability without the operational value.
4. Do you have alerting for new unaligned senders? Aggregate reports surface new sending sources — legitimate or otherwise — that haven't been authorized. If a marketing tool gets onboarded without IT visibility, your reports will show it. You should be alerted within days, not at the next audit.
5. Do you have a documented process for triaging DMARC failures? “We monitor reports” is not enough. The process — who looks at what, how often, and what triggers action — needs to be written down.
6. Are you retaining DMARC reports for at least 12 months? PCI DSS requires audit log retention of at least 12 months across multiple control families, and DMARC reports become audit evidence the moment you cite them as your 5.4.1 mechanism. Same retention floor.
7. Is the sp= subdomain policy explicit on each parent domain? Default behavior when sp= is omitted is to inherit p=, but spelling it out removes ambiguity. We recommend explicit sp=reject on parent domains where you have full subdomain inventory.
8. Have you considered BIMI and MTA-STS as supplementary controls? Neither is a 5.4.1 requirement. Both reinforce the overall anti-spoofing story and show up well in QSA discussions about “comprehensive anti-phishing approach.”
9. Do you have a documented 5.4.1 control narrative? A one-page write-up: “Our 5.4.1 implementation is DMARC at p=reject across [domain list], with SPF and DKIM as prerequisites, monitored via [reporting service], reviewed [cadence]. Supplementary controls: [list].” Your QSA will ask for this. Have it ready.
10. Have you explicitly addressed the Requirement 12.6.3.1 / 5.4.1 distinction? The Council is emphatic that anti-phishing training (12.6.3.1) and anti-phishing technical controls (5.4.1) are separate requirements that do not satisfy each other. Don't let your training program be your only anti-phishing answer.

Common audit gotchas

Subdomain DMARC inheritance. A DMARC record on example.com does not automatically apply at the same policy strength to a subdomain that has its own record. The sp= tag controls inherited subdomain behavior; if absent, receivers infer it from p=. We've seen audits where a parent at p=reject and an unmonitored subdomain with its own p=none record became a finding. Inventory every subdomain you've published a DMARC record on.

Forensic ruf= reports and PII handling. Forensic reports include redacted message content, headers, and recipient information. Under PCI DSS, anything that surfaces cardholder data — even fragments — falls under broader data-handling requirements. We default to omitting ruf= for PCI environments. Aggregate rua= reports are the audit-relevant evidence stream; forensic reports are operational color.

12-month retention. If your DMARC reporting service deletes reports at 90 days, that's a problem the moment you cite those reports as 5.4.1 evidence. Retain at the service tier you're paying for, or export to your own log pipeline.

Sender drift between assessments. Your sender ecosystem changes. A QSA who saw p=reject at the last assessment will look for evidence that someone hasn't quietly downgraded to p=quarantine to stop the noise from a newly onboarded tool.

The “we don't send email” claim. Some teams argue CDE-related domains don't send email so 5.4.1 doesn't apply. The Applicability Note is unambiguous: the focus is on protecting personnel, not just outbound mail. Your personnel receive email. Their domains can be spoofed. Publishing DMARC on a non-sending domain is a one-hour task; arguing the carve-out is a multi-meeting expense. Just publish.

The DMARCit approach

We build DMARC monitoring and enforcement tooling for organizations that need to show their work at audit. The PCI-relevant pieces:

• Aggregate report retention beyond 12 months [VERIFY product reality]. The 12-month floor maps to PCI DSS audit-log retention. “Show me your DMARC reports from the assessment window” is a query, not an export-and-pray exercise.
• Alignment-rate dashboards. The audit question is rarely “do you have DMARC?” It's “how do we know it's working?” Dashboards surface alignment per domain, per sender, over time — in the format QSA conversations actually use.
• First-seen sender alerting. New unaligned senders surface in the aggregate report stream. We alert on first-seen, so a marketing-onboarded SaaS that started sending Tuesday doesn't become an alignment surprise next quarter.
• US-based founder access [VERIFY]. Adam (founder) is the technical contact. Compliance teams in QSA prep get direct answers from someone who built the product.
• $39/mo Pro tier [VERIFY domain count]. Pricing floor below the enterprise-DMARC market because most 4.0.1 compliance projects don't need the enterprise package; they need defensible reporting, retention, and alerting.

What we're not: we are not a QSA-certified vendor [VERIFY]. Our tooling produces evidence that QSAs accept; we are not a QSA. If you need a QSA-certified DMARC managed service — typically Tier 1 merchants or service providers with bespoke audit requirements — we're not the right fit, and the honest answer is to point you to one of the larger vendors that carries that certification. Most orgs don't need that level. Some do. The conversation is worth having explicitly.

We also don't claim “real-time” DMARC reporting. The underlying RFC 7489 aggregate mechanism isn't real-time — receivers send reports on a daily-or-longer cadence. What we deliver is first-seen detection and alignment-rate trending.

Cross-references — PCI isn't the only regime

PCI DSS 4.0 is one of several regulatory frames that touch DMARC in 2026:

• NIS2 (EU). The EU's Network and Information Security Directive 2 requires “essential” and “important” entities to implement appropriate technical measures; email security is named in supporting guidance, with DMARC as the canonical example. Member-state transposition varies.
• HIPAA (healthcare, US). HIPAA's Security Rule does not name DMARC. HHS cybersecurity performance goals and OCR audit protocols increasingly treat email authentication as a baseline expectation.
• SEC cybersecurity disclosure rules (US, public companies). The SEC's 2023 rules require public companies to describe cybersecurity risk management. The absence of email authentication in a 10-K cybersecurity narrative is increasingly a flag.
• UK NCSC Mail Check / mandate. The UK National Cyber Security Centre has progressively tightened the email authentication expectation for government and government-adjacent organizations.

If your compliance scope spans more than PCI DSS — most do — get in touch: sales@dmarcit.io.