DMARC and PCI DSS v4.0: What Payment Processors Must Do in 2026

PCI DSS v4.0 requires DMARC. If your organization processes, stores, or transmits payment card data, DMARC is no longer optional — it's a compliance requirement that took effect in March 2025.

This guide explains what PCI DSS v4.0 actually mandates for email authentication, who it applies to, how strict the requirements are, and what you need to do to demonstrate compliance.

What PCI DSS v4.0 Says About DMARC

The PCI Security Standards Council's v4.0 specification introduced Requirement 5.4, which covers phishing and social engineering controls. Within that requirement, anti-spoofing measures for email domains are explicitly required for organizations in scope.

The relevant mandate: organizations must implement controls to protect against phishing attacks and email-based threats, including publishing DMARC records that instruct receiving servers how to handle unauthenticated mail. SPF and DKIM are required as the underlying authentication layers.

The practical translation: you must have a valid DMARC record published on your sending domain, SPF configured to cover all your email sources, and DKIM signing active on your mail streams. Monitoring-only (p=none) isn't explicitly prohibited by PCI DSS v4.0, but auditors increasingly expect organizations to have a clear path to enforcement — staying indefinitely at p=none is likely to draw scrutiny.

Who PCI DSS v4.0 Applies To

PCI DSS applies to any organization that accepts, processes, stores, or transmits cardholder data. This covers:

E-commerce businesses that take card payments on their website
Retailers and restaurants using point-of-sale systems
SaaS companies that invoice clients via card
Service providers handling payment data on behalf of merchants

The compliance scope determines which requirements apply. Organizations fully outsourcing payment processing to a PCI-compliant payment gateway (using hosted payment pages where cardholder data never touches their systems) are in a lighter compliance scope, but they still operate domains, and those domains can be spoofed in phishing attacks against their customers. DMARC is good practice regardless of your exact PCI scope.

If you're unsure whether PCI DSS applies to your organization, your payment processor or acquiring bank can clarify. A Qualified Security Assessor (QSA) can scope your compliance requirements formally.

The Three Technical Requirements

PCI DSS v4.0's email authentication requirements translate to three technical controls:

1. SPF (Sender Policy Framework)

Publish a TXT record on your domain specifying which mail servers are authorized to send on your behalf. Every service that sends email as your domain — your main mail server, your CRM, your helpdesk, your transactional email service — needs to be included.

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

Run a free SPF check to confirm your record is valid and stays under the 10 DNS lookup limit imposed by RFC 7208.

2. DKIM (DomainKeys Identified Mail)

Every email your domain sends must carry a valid DKIM signature. Configure DKIM signing in each email platform you use.

For Google Workspace, this is done in the Admin Console. For Microsoft 365, it's in the Defender portal. Third-party senders like Mailchimp, Salesforce, and SendGrid have their own DKIM configuration under "domain authentication" settings.

3. DMARC record published

Publish a DMARC record at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com; fo=1;

The rua= address is where aggregate reports are sent. Use SimpleDMARC's reporting address to have those reports parsed automatically — raw XML aggregate reports are difficult to interpret without tooling.

What Policy Level Does PCI DSS Require?

PCI DSS v4.0 does not mandate a specific DMARC policy (p=none, p=quarantine, or p=reject). What auditors are looking for is that:

A DMARC record exists and is syntactically valid
Reporting is enabled (the rua= tag is present)
The organization is actively monitoring reports and taking action
There is a documented plan to move toward enforcement

Staying permanently at p=none with no monitoring and no enforcement roadmap will draw questions during a PCI audit. Being able to show that you're actively reading aggregate reports and have a timeline for enforcement is far more defensible than simply having a record published.

The practical recommendation: if you're in an early monitoring phase, document it. Save your report data, note which sending services are passing and which are still being fixed, and have a written timeline for moving to p=quarantine and eventually p=reject. This demonstrates active compliance management rather than checkbox compliance.

For organizations already managing all their sending sources, moving to p=quarantine or p=reject is achievable in 30 days. See the p=none to p=reject guide for a structured path.

How to Verify Your PCI DMARC Compliance

Before your next audit, verify these items:

DMARC record check
Run your domain through a DMARC validator. The record must be syntactically valid, the v=DMARC1 tag must be first, and at least one rua= or ruf= address must be present.

![DMARC checker screenshot showing record validation result]

SPF coverage check
Confirm your SPF record covers every service that sends email as your domain. Check the DNS lookup count — exceeding 10 causes SPF to fail, which breaks DMARC.

DKIM signing check
Verify that emails from your domain carry valid DKIM signatures. Send a test email from each sending service and check the message headers for a DKIM-Signature header with pass status.

Report monitoring evidence
Print or export a summary from your DMARC monitoring dashboard showing report receipt, sender source breakdown, and compliance rate. This is the evidence auditors want to see.

What Happens If You're Not Compliant

PCI DSS non-compliance has financial consequences ranging from fines imposed by card brands (Visa, Mastercard) to increased transaction fees and, in serious cases, loss of the ability to process cards. The exact penalty structure varies by card brand, your merchant level, and your acquiring bank's policies.

Beyond PCI, an unprotected domain is a liability to your customers. Attackers who spoof your payment-related domain can send convincing phishing emails that appear to come from your billing team. Your DMARC record is what stops those emails from being delivered.

Frequently Asked Questions

Does PCI DSS v4.0 require DMARC at p=reject?
No specific policy level is mandated. Auditors expect a valid DMARC record, active monitoring, and a documented enforcement roadmap. Organizations with good monitoring evidence and a clear plan are generally in better shape than those with p=reject but no evidence of ongoing monitoring.

We use a third-party payment gateway — do we still need DMARC?
If cardholder data never touches your systems, your PCI scope may be reduced. But your domain can still be spoofed regardless of your payment setup. Attackers target your brand, not your infrastructure. DMARC protects your domain's reputation independently of your PCI scope.

How do aggregate DMARC reports help with PCI compliance?
Aggregate reports give you documented evidence that you're monitoring email authentication. They show which senders are passing authentication, which are failing, and what percentage of your email stream is compliant. This is the audit trail PCI assessors want to see.

Can SimpleDMARC generate compliance reports for PCI audits?
SimpleDMARC's dashboard shows authentication pass rates, sender source breakdowns, and historical data that forms the basis of compliance documentation. Paid plans include longer retention periods, which matters for audit evidence spanning longer periods.

How long does it take to get DMARC-compliant for PCI?
SPF and DKIM configuration typically takes one afternoon per sending service. Publishing the DMARC record takes minutes. Getting to meaningful enforcement (p=quarantine or p=reject) takes two to four weeks of monitoring and remediation. Start now — don't wait until the audit window opens.