PCI DSS 4.0 DMARC Requirement [2026]

PCI DSS v4.0.1 Section 5.4.1 requires anti-phishing controls — including DMARC, SPF, and DKIM — for every entity that stores, processes, or transmits cardholder data. This PCI DSS DMARC requirement became mandatory on March 31, 2025. The deadline has passed.

If your organization handles payment card data and you’re preparing for a PCI assessment, you need clear answers. What does Section 5.4.1 actually require? Which protocols satisfy it? What do Qualified Security Assessors (QSAs) expect to see during an audit? And what’s the difference between what the standard “recommends” versus what assessors treat as mandatory?

Most compliance guides paraphrase the standard loosely. This guide works directly from the PCI DSS v4.0.1 source text, maps each requirement to the specific email authentication protocols that address it, and includes DNS record examples at every step.

We also cover an angle most guides miss — how PCI DSS Requirement 4 (encryption of data in transit) relates to email transport security, and which additional protocols strengthen that compliance posture. Together, these make this the most complete reference for the PCI DSS email authentication mandate. Whether you’re implementing email authentication for the first time or tightening an existing deployment for audit readiness, this guide covers the full picture.

What Is PCI DSS v4.0?

PCI DSS stands for Payment Card Industry Data Security Standard. It’s maintained by the PCI Security Standards Council and applies to any organization that stores, processes, or transmits cardholder data — from global retailers to small businesses running a single payment terminal.

Version 4.0.1, released in June 2024, superseded v3.2.1, which was retired on March 31, 2025. The PCI DSS 4.0 requirements are organized into 12 principal requirements across 6 control objectives:

Requirements 4 and 5 are directly relevant to email security — Requirement 4 covers encryption of data in transit, and Requirement 5 covers anti-phishing controls. We’ll cover both.

One notable change in PCI DSS 4.0: the standard introduced a “customized approach” as an alternative to the “defined approach” for meeting requirements. Organizations can demonstrate compliance through controls that meet the stated objective, even if they differ from the prescribed method. For email authentication, this means you could theoretically satisfy Section 5.4.1 through alternative anti-phishing mechanisms — but in practice, auditors expect DMARC, SPF, and DKIM as the baseline.

PCI DSS applies regardless of organization size. Whether you process millions of transactions or handle a few hundred, the same PCI DSS 4.0 requirements apply if you touch cardholder data. The differences are in assessment methodology (Self-Assessment Questionnaire vs. on-site audit by a QSA), not in which requirements you must meet.

What Changed in v4.0: Section 5.4.1 Anti-Phishing Controls

Section 5.4.1 is entirely new in PCI DSS v4.0. It had no equivalent in v3.2.1 — meaning organizations that were compliant under the old standard may now have a gap to fill. The full requirement text reads:

“Processes and automated mechanisms are defined and implemented to detect and protect personnel against phishing attacks.”

— PCI DSS v4.0.1, Section 5.4.1

The accompanying guidance is where DMARC enters the picture. The standard explicitly names PCI DSS anti-phishing controls as a method to satisfy this requirement:

“Anti-spoofing controls may include a combination of DMARC (Domain-based Message Authentication, Reporting & Conformance), SPF (Sender Policy Framework), and DKIM (DomainKeys Identified Mail) to detect and prevent forged sender addresses.”

— PCI DSS v4.0.1, Section 5.4.1 Guidance

There’s an important nuance here. The guidance says “recommended,” not “required,” for specific protocols. PCI DSS sets the objective — anti-phishing controls — and lets organizations choose how to meet it. But the landscape has shifted since v4.0 was published. Most Qualified Security Assessors (QSAs) now treat DMARC as an expected baseline, not an optional extra.

If you can’t demonstrate email authentication controls during an assessment, expect pointed questions. The “customized approach” in v4.0 technically allows alternative controls, but you’d need to prove they achieve the same objective — detecting and preventing phishing attacks targeting your personnel. DMARC, SPF, and DKIM are the most direct, well-documented, and widely recognized controls for this purpose.

Timeline context: PCI SSC first published v4.0 in March 2022. Section 5.4.1 was classified as a “future-dated requirement” — a best practice that organizations should plan for but wouldn’t be assessed against immediately. In June 2024, v4.0.1 was released with minor clarifications. The transition period ended on March 31, 2025, when v3.2.1 was officially retired and all future-dated requirements (including 5.4.1) became mandatory for every assessment.

It’s also worth distinguishing Section 5.4.1 from Requirement 12.6.3.1, which requires security awareness training that includes recognizing phishing attacks. PCI DSS 4.0 addresses phishing from both directions: technical controls (5.4.1) detect and block phishing emails before they reach personnel, while training (12.6.3.1) prepares personnel to recognize threats that bypass technical controls. DMARC satisfies the technical side; it doesn’t replace training. Both are required.

The PCI DSS anti-phishing requirement also extends beyond your primary domain. If your organization sends email from multiple domains or subdomains — payment confirmations from billing.example.com, support from help.example.com — each domain used in email communications should have SPF, DKIM, and DMARC configured.

Why Email Authentication Matters for PCI Compliance

Email spoofing enables business email compromise (BEC) attacks that target finance teams handling payment data. Without DMARC, an attacker can send emails that appear to come from your domain to customers, partners, and employees — requesting fraudulent payments, redirecting invoices, or harvesting credentials that lead to cardholder data exposure.

PCI DSS scope extends to any system connected to the cardholder data environment (CDE). Email infrastructure is often in scope because employees with CDE access use email to communicate about transactions, share reports, and coordinate with payment processors. If an attacker spoofs your domain to phish an employee with CDE access, the email system becomes the entry point to cardholder data.

PCI compliance for email has historically focused on encryption and access controls — not authentication. As our 2026 email authentication research shows, the compliance gap many organizations face is significant: they pass PCI audits on network segmentation, access controls, and data-at-rest encryption but have no email authentication in place. They’ve secured the database but left the front door unlocked. Section 5.4.1 closes this gap by requiring organizations to address the phishing vector directly.

Domain spoofing isn’t hypothetical. Attackers routinely impersonate payment processors, financial institutions, and vendor domains to target employees involved in cardholder data handling. They send invoices from look-alike addresses, request wire transfers from spoofed executive accounts, and harvest credentials through fake login pages. DMARC, SPF, and DKIM provide the technical foundation to prevent exact-domain spoofing and give your organization visibility into who is sending email as your domain.

The stakes are concrete: PCI DSS non-compliance can result in penalties ranging from $5,000 to $100,000 per month from payment card brands, increased transaction fees, and potential loss of card processing privileges (dmarcian, January 2026). Beyond penalties, a successful phishing attack that compromises cardholder data triggers breach notification requirements, forensic investigation costs, and reputational damage that compounds the financial impact.

For organizations that handle PCI compliance for email systems, the message is clear: email authentication isn’t a “nice to have” any longer. It’s a compliance control that auditors will check and that attackers will probe. The cost of implementing DMARC, SPF, and DKIM is measured in hours of DNS configuration. The cost of not implementing them is measured in audit findings, penalties, and breach risk.

How DMARC, SPF, and DKIM Help You Meet Section 5.4.1

Section 5.4.1 requires “automated mechanisms to detect and protect personnel against phishing attacks.” Here’s how each protocol maps to that requirement:

SPF (Sender Policy Framework, RFC 7208) authorizes which IP addresses can send email for your domain. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to verify the sending server is authorized. Unauthorized servers are flagged — directly addressing the “detect” component of 5.4.1.

v=spf1 include:_spf.google.com include:sendgrid.net ~all

DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to your outgoing emails. The receiving server verifies this signature against a public key in your DNS. If the message was modified in transit or sent by an unauthorized party, verification fails. This addresses both detection and protection — tampered messages are identified automatically.

default._domainkey.example.com  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."

DMARC (Domain-based Message Authentication, Reporting & Conformance, RFC 7489) ties SPF and DKIM together through alignment — the domain authenticated by SPF or DKIM must match the domain in the visible From header. DMARC adds enforcement policies (none, quarantine, reject) and reporting, so you can see who is sending email as your domain and take action.

_dmarc.example.com  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Together, these three protocols directly satisfy the “automated mechanisms to detect and protect personnel against phishing attacks” language in Section 5.4.1. Achieving DMARC compliance — specifically, moving to an enforcement policy — demonstrates that your organization has both the technical controls and the visibility required by the standard.

PCI DSS v4.0.1 covers email security through two requirements: Section 5.4.1 for anti-phishing (DMARC, SPF, DKIM) and Section 4.2.1 for encryption in transit (MTA-STS, TLS-RPT, DANE).

×

DMARC enforcement at p=quarantine or p=reject demonstrates the strongest PCI DSS compliance posture. A policy of p=none shows monitoring intent but doesn’t actively protect personnel — which is what the standard requires. For DMARC compliance with PCI DSS, enforcement is the goal.

Beyond Section 5.4.1: Email Encryption Under Requirement 4

PCI DSS email security requirements extend beyond anti-phishing. Requirement 4 addresses data in transit — and it has direct implications for how your organization handles email encryption.

Requirement 4.2.1 states:

“Strong cryptography is used whenever cardholder data is sent via end-user messaging technologies.”

— PCI DSS v4.0.1, Requirement 4.2.1

This applies to email systems that transmit, reference, or include cardholder data. TLS 1.2 or higher is required for data in transit over public networks. Standard SMTP doesn’t guarantee encryption — it’s opportunistic by default, meaning an attacker can force a downgrade to plain text.

Three protocols address this gap:

MTA-STS (RFC 8461) publishes a policy that forces sending servers to use encrypted TLS connections when delivering to your domain. It prevents TLS downgrade attacks by declaring: “Always use TLS, or reject the message.” This directly supports Requirement 4’s encryption mandate for email transport.

TLS-RPT (RFC 8460) provides reporting on TLS delivery failures. When a sending server can’t establish a TLS connection to your domain, TLS-RPT sends you a report explaining what went wrong. This gives visibility into whether your email encryption is actually working — critical for demonstrating compliance during assessments.

DANE (RFC 6698) uses DNSSEC to authenticate mail server certificates directly through DNS, providing certificate pinning for SMTP connections. It eliminates reliance on the certificate authority (CA) system and prevents man-in-the-middle attacks on email delivery.

For organizations where email systems handle or reference cardholder data, deploying both sets of protocols strengthens your compliance posture across two PCI DSS requirements, not just one. Most PCI compliance guides focus exclusively on Section 5.4.1 — addressing Requirement 4 with email transport security gives your organization coverage that auditors will recognize as thorough.

While not every organization sends cardholder data via email, many reference it — sending payment confirmation emails, transaction notifications, or internal communications about payment processing. If your email systems touch cardholder data in any form, Requirement 4.2.1 applies, and these transport security protocols provide the evidence that your email encryption meets the standard.

Step-by-Step: PCI DSS Email Authentication Compliance

Here’s how to implement email authentication that satisfies PCI DSS Section 5.4.1 — and optionally, Requirement 4.

Step 1: Audit your current email authentication

Check your existing SPF, DKIM, and DMARC records for every domain your organization uses. Use a DMARC checker to look for missing records, syntax errors, and SPF records that exceed the 10 DNS lookup limit.

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

Step 2: Publish DMARC with p=none and reporting

If you don’t have a DMARC record, start with monitoring mode. Set the rua tag to a reporting address where you’ll receive aggregate reports.

_dmarc.example.com  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Step 3: Identify all legitimate sending sources

Review your aggregate reports after 2–4 weeks. They’ll show every IP address and domain sending email as your domain. Identify all legitimate sources: your mail server, marketing platforms, CRM systems, support tools, and transaction notification services.

Step 4: Fix SPF and DKIM for each sending source

Add each legitimate sending source to your SPF record and configure DKIM signing. Every third-party service that sends on your behalf needs to authenticate properly.

v=spf1 include:_spf.google.com include:sendgrid.net include:amazonses.com ~all

Step 5: Move to enforcement

Once your aggregate reports show 95%+ pass rates across all legitimate sources, move to enforcement:

1. Set p=quarantine with pct=10 — applies the policy to 10% of traffic
2. Monitor for problems over 1–2 weeks
3. Increase pct to 50, then 100
4. Move to p=reject with pct=10, then gradually increase to 100

_dmarc.example.com  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

Step 6: Set subdomain policy

Prevent subdomain spoofing by adding the sp tag:

_dmarc.example.com  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]"

Step 7: Document your implementation for audit evidence

QSAs will ask for evidence of your anti-phishing controls. Prepare:

• Screenshots of your DNS records (SPF, DKIM, DMARC)
• DMARC aggregate report summaries showing authentication pass rates
• A list of all authorized sending sources
• Your DMARC enforcement timeline (when you moved from none → quarantine → reject)
• Evidence of ongoing monitoring (reports are being collected and reviewed)

Step 8 (optional): Deploy MTA-STS and TLS-RPT for Requirement 4

If your email systems handle cardholder data, strengthen your Requirement 4 posture:

_mta-sts.example.com  IN  TXT  "v=STSv1; id=20260304"
_smtp._tls.example.com  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

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

Common Mistakes That Fail PCI DSS Email Audits

Mistake 1: DMARC at p=none without a plan to enforce. Monitoring mode shows intent but doesn’t actively protect personnel — which is what Section 5.4.1 requires. Auditors view indefinite p=none as incomplete implementation.

Mistake 2: Missing subdomain policy. If your main domain has p=reject but subdomains have no policy, attackers can spoof billing.yourdomain.com or payments.yourdomain.com. Always set sp=reject.

Mistake 3: SPF record exceeding the 10 DNS lookup limit. SPF allows a maximum of 10 DNS lookups (RFC 7208). Exceeding this limit causes SPF to return a permanent error (permerror), effectively breaking authentication for all your email.

Mistake 4: No DKIM signing on third-party senders. If your marketing platform or CRM sends email as your domain but doesn’t sign with DKIM, those messages will fail DMARC alignment when SPF also fails — which happens whenever the sending IP isn’t in your SPF record. See our DMARC failure troubleshooting guide for step-by-step fixes.

Mistake 5: No aggregate report monitoring. You can’t prove to an auditor that you’re reviewing authentication results if you’re not collecting and analyzing DMARC reports. The rua tag in your DMARC record isn’t optional for compliance.

Mistake 6: Treating 5.4.1 as optional because the guidance says “recommended.” The requirement itself — anti-phishing controls — is mandatory. The guidance recommends specific protocols. Assessors increasingly expect DMARC as the baseline anti-spoofing control.

Mistake 7: Ignoring email encryption (Requirement 4) while focusing only on anti-phishing (Requirement 5). If your organization sends cardholder data or payment notifications via email, Requirement 4.2.1 applies. MTA-STS and TLS-RPT address this — and most organizations overlook them entirely.

Frequently Asked Questions

Does PCI DSS require DMARC?

PCI DSS v4.0.1 Section 5.4.1 requires processes and automated mechanisms to detect and protect personnel against phishing attacks. The guidance explicitly names DMARC, SPF, and DKIM as recommended anti-spoofing controls. This became mandatory for all assessments after March 31, 2025. Most Qualified Security Assessors treat DMARC as an expected baseline.

What is PCI DSS Section 5.4.1?

Section 5.4.1 requires processes and automated mechanisms to detect and protect personnel against phishing attacks. The guidance specifically names DMARC, SPF, and DKIM as recommended anti-spoofing controls. It was added in PCI DSS v4.0 and had no equivalent in v3.2.1.

What happens if I don’t comply with PCI DSS DMARC requirements?

Non-compliance with PCI DSS can result in penalties ranging from $5,000 to $100,000 per month from payment card brands, increased transaction fees, and potential loss of card processing privileges (dmarcian, January 2026).

Is DMARC alone enough for PCI DSS compliance?

DMARC is one component of Section 5.4.1. Full compliance requires a combination of technical controls (DMARC, SPF, DKIM), email filtering, link scrubbers, and security awareness training under Requirement 12.6.3.1. No single protocol satisfies the requirement on its own.

Which DMARC policy does PCI DSS require?

PCI DSS does not specify a particular DMARC policy. However, enforcement policies (p=quarantine or p=reject) provide stronger anti-phishing protection and demonstrate a more robust compliance posture to auditors than p=none.

How does PCI DSS relate to email encryption?

Requirement 4.2.1 mandates strong cryptography for cardholder data in transit over public networks. For email systems handling payment data, this means TLS 1.2+ enforcement. MTA-STS and TLS-RPT help monitor and enforce encrypted email delivery.

When did PCI DSS DMARC requirements take effect?

Section 5.4.1 was a best practice until March 31, 2025, after which it became mandatory for all PCI DSS assessments. The deadline has passed — compliance is required now.

Related Protocols

The PCI DSS DMARC requirement under Section 5.4.1 is no longer a best practice — it’s a compliance control that auditors assess. Start with monitoring, identify your sending sources, move to enforcement, and document everything. For organizations where email touches cardholder data, extend your compliance posture with transport security protocols under Requirement 4. This email authentication mandate applies now.

• DMARC — Domain-based email authentication, reporting, and policy enforcement
• SPF — Authorizes which servers can send email for your domain
• DKIM — Cryptographic signatures that prove message integrity
• MTA-STS — Forces encrypted TLS connections for email delivery
• TLS-RPT — Reports on TLS delivery failures between mail servers
• DANE — DNS-based certificate authentication for SMTP