DMARC and PCI DSS 4.0: New Email Authentication Requirements

If your organization handles payment card data -- particularly ecommerce businesses -- PCI DSS 4.0 introduced a requirement that directly affects your email setup. Requirement 5.4.1 mandates anti-phishing mechanisms for organizations in scope, and DMARC is one of the key technologies that satisfies it. This became mandatory in March 2025, and auditors are now checking for it.

This guide explains what PCI DSS 4.0 requires, how DMARC helps you meet those requirements, and what configuration auditors expect to see.

What PCI DSS 4.0 Requires

PCI DSS (Payment Card Industry Data Security Standard) version 4.0 replaced the previous version 3.2.1 with updated security requirements. Among the changes, requirement 5.4.1 stands out for email administrators:

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

This requirement specifically calls for anti-phishing controls that go beyond user training. It requires technical mechanisms — automated systems that prevent phishing emails from reaching employees. DMARC, combined with SPF and DKIM, is the most widely recognized technical control for preventing domain-based phishing.

The requirement became effective on March 31, 2025, after a transition period that gave organizations time to implement the new controls. If you are undergoing a PCI DSS assessment now, your assessor will ask about your anti-phishing mechanisms and DMARC is likely at the top of the list.

How DMARC Satisfies the Anti-Phishing Requirement

DMARC prevents domain spoofing — one of the most common phishing techniques. When an attacker sends an email that appears to come from your domain (for example, mimicking your CFO to trick an employee into wiring money), DMARC enforcement blocks or quarantines that message before it reaches the recipient's inbox.

Here is how the three layers work together:

SPF verifies that the sending server is authorized to send email for your domain. You publish a list of authorized IP addresses in your DNS, and receiving servers check incoming messages against that list.

DKIM attaches a cryptographic signature to your emails. Receiving servers verify the signature against a public key in your DNS, confirming the message has not been tampered with and was authorized by your domain.

DMARC ties it all together. It checks that at least one of SPF or DKIM passes and that the authenticated domain aligns with the visible "From" domain. Critically, DMARC also specifies what happens to messages that fail: p=quarantine sends them to spam, and p=reject blocks them entirely.

For PCI compliance purposes, DMARC provides the automated, technical mechanism that requirement 5.4.1 demands. It does not rely on employees recognizing phishing — it prevents the spoofed messages from arriving in the first place.

Recommended DMARC Configuration for PCI Compliance

While PCI DSS 4.0 does not prescribe a specific DMARC policy level, the intent of the requirement is to prevent phishing emails from reaching personnel. A p=none policy, which only monitors and takes no action, does not actively protect anyone. To demonstrate compliance, you should aim for an enforcement policy.

The Ideal Configuration

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

p=reject is the strongest policy and provides the clearest compliance posture. It tells receiving servers to block any email that fails DMARC authentication. An auditor seeing p=reject knows your domain is actively protected. For a detailed breakdown of the practical differences, see DMARC quarantine vs reject.

rua reporting shows you are monitoring the results, not just setting and forgetting. Aggregate reports provide evidence that you are actively managing your email authentication.

fo=1 requests failure reports for any authentication failure, giving you maximum visibility into issues.

Minimum Acceptable Configuration

If you are still working toward full enforcement, p=quarantine with pct=100 is the minimum that demonstrates active anti-phishing protection. Messages failing DMARC are sent to spam rather than the inbox, which still provides meaningful protection.

A p=none policy is unlikely to satisfy an assessor on its own, since it takes no action against spoofed emails. If you are currently at p=none, you should have a documented plan and timeline for moving to enforcement.

Documenting Your DMARC Setup for Auditors

PCI DSS assessments require documentation, not just configuration. Here is what to prepare:

Evidence of Implementation

Your assessor will want to see proof that your DMARC record is published and active. This includes:

• A DNS lookup showing your current DMARC record (you can use dmarcrecordchecker.com and screenshot the results)
• The corresponding SPF record showing authorized senders
• DKIM configuration evidence showing signing is enabled for your email services

Monitoring Evidence

Show that you actively review DMARC reports. This could be screenshots of a DMARC report analysis dashboard, samples of aggregate reports you have reviewed, or documentation of actions taken based on report findings (such as adding a new authorized sender or investigating a spoofing attempt).

Policy Progression Documentation

If you recently moved from p=none to enforcement, document the timeline. Showing a deliberate progression from monitoring to quarantine to reject demonstrates a mature, planned approach rather than a last-minute checkbox exercise.

Incident Response Procedures

Document what happens when your DMARC reports reveal suspicious activity. Who reviews the reports? What is the escalation path if spoofing is detected? How quickly do you respond? This ties your DMARC implementation into your broader incident response framework, which PCI DSS also requires.

The Broader Compliance Landscape

PCI DSS 4.0 is not the only compliance framework that values DMARC. Understanding the broader landscape helps you justify the investment and build a comprehensive email security posture.

SOC 2

SOC 2 audits assess controls related to security, availability, and confidentiality. While SOC 2 does not have a specific DMARC requirement, auditors frequently evaluate email security controls as part of the security trust service criteria. Having DMARC at enforcement demonstrates a proactive approach to preventing phishing and protecting your domain.

HIPAA

For healthcare organizations, HIPAA's Security Rule requires safeguards against unauthorized access to electronic protected health information (ePHI). Email-based phishing is one of the primary attack vectors in healthcare breaches. DMARC is increasingly cited as a best practice for HIPAA compliance, and some HIPAA security assessments now explicitly ask about email authentication controls.

Government Mandates

In the United States, BOD 18-01 required all federal agencies to implement DMARC at p=reject. In the United Kingdom, the NCSC recommends DMARC for all organizations. The European Union's NIS2 directive also promotes email authentication. These government mandates signal the direction the industry is heading: DMARC enforcement as a baseline expectation.

Cyber Insurance

Many cyber insurance providers now ask about email authentication controls during underwriting. Having DMARC at enforcement can positively affect your policy terms, premiums, or eligibility. Some insurers specifically list DMARC as a required or recommended control.

Steps to Achieve PCI-Compliant DMARC

If you are starting from scratch, here is the path to compliance:

Do Not Wait for the Audit

If your organization handles payment card data and you do not yet have DMARC at enforcement, now is the time to act. The requirement is already in effect, and assessors are actively checking for it. Starting with p=none today puts you on the path to compliance, and a documented plan to reach enforcement shows good faith during your assessment.

Beyond compliance, DMARC enforcement protects your organization from the phishing attacks that lead to data breaches, financial fraud, and the kind of incidents that trigger PCI investigations in the first place.

Monitor Your DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.