The deadline was March 31, 2025. If you process payment card data and you are reading this in April 2026 still running p=none or no DMARC at all, you are out of compliance with PCI DSS v4.0. That is not a hypothetical risk. It is a finding that belongs in a QSA assessment report.
Most conversations about DMARC focus on inbox placement. PCI DSS v4.0 shifts the framing entirely: DMARC is now a security control, not a deliverability optimization. The failure mode it protects against is not your email landing in spam. It is a criminal sending phishing emails that appear to come from your domain to your customers, asking them to verify payment details or click a fraudulent link. Requirement 5.4.1 exists because that attack happens constantly, and unauthenticated domains make it easy.
Here is what is required, what auditors look for, and what the realistic path to compliance looks like if you are not there yet.
What PCI DSS v4.0 Requirement 5.4.1 Actually Says
PCI DSS v4.0 Requirement 5.4.1 falls under the broader anti-phishing controls category. The requirement is that entities implement controls to detect and protect personnel against phishing attacks. Within that section, DMARC is explicitly referenced as the mechanism for protecting the organization's email domains.
The specific language covers three authentication protocols: SPF, DKIM, and DMARC. All three are required. DMARC policy must be at minimum p=quarantine. The PCI Security Standards Council guidance makes clear that p=none does not satisfy the requirement because it provides no actual protection. A p=none policy tells receiving mail servers to take no action on authentication failures, which means phishing emails from your domain can still reach inboxes without any filtering.
p=reject is the strongest configuration and is recommended by the PCI guidance as the target state. p=quarantine is the minimum compliant configuration for most organizations. An organization with documented evidence showing they are actively monitoring p=quarantine and have a timeline to move to p=reject may be treated differently by some QSAs during the transition period, but p=none is not compliant.
The requirement applies to all domains used in email communication within the cardholder data environment (CDE). This matters for businesses with multiple domains. If you have a transactional email domain like notifications.yourstore.com separate from your primary domain, both need to comply if they send mail related to payment processing.
Who Must Comply and What "In Scope" Means
PCI DSS applies to any entity that stores, processes, or transmits cardholder data. For ecommerce businesses, this typically means the primary domain used for checkout confirmation emails, fraud alerts, account verification, and payment receipt communications. B2B businesses that collect payment card data over email or through integrated platforms also fall in scope.
The tricky part is scope creep. Many marketing teams operate email sending from the same primary domain used for transactional communications. If your marketing campaigns go out from @yourcompany.com and your payment receipts also go out from @yourcompany.com, the same domain is in scope for PCI DSS even though most of the email volume is marketing.
Third-party payment processors like Stripe, PayPal, or Square handle the actual card data, which reduces your scope. But if you are sending order confirmation emails from your domain, that domain still needs authentication controls because those emails could be spoofed in a phishing attack against your customers.
SaaS businesses with subscription billing, marketplace platforms, and any ecommerce operator with direct card processing need to take Requirement 5.4.1 seriously. The scope question is worth having a direct conversation with your QSA about, especially if you use multiple sending domains or have recently migrated email infrastructure.
What Auditors Actually Look For in an Assessment
A PCI QSA (Qualified Security Assessor) evaluating Requirement 5.4.1 will typically check several things, and they are not difficult to verify.
The first check is simple DNS lookup. They will query your DMARC record at _dmarc.yourdomain.com and confirm it exists, that the p= value is quarantine or reject, and that the rua= tag (aggregate report address) is populated. A DMARC record with no rua tag is technically syntactically valid but signals that the organization is not monitoring authentication results, which raises questions about whether the control is being actively maintained.
The second check is SPF. They will look for your SPF record at your domain's TXT records and confirm it authorizes your sending infrastructure. SPF with a hard fail mechanism (the -all ending) is generally preferred for PCI compliance. A soft fail (~all) may be acceptable with documented reasoning, but the ~all setting means unauthorized mail is marked suspicious rather than rejected, which is a weaker control.
Third, DKIM. They will want evidence that outbound mail from your domain is DKIM-signed. If you are on an ESP, they may ask for email headers from a sample message to confirm DKIM signatures are present and valid.
Fourth, DMARC alignment. If your SPF and DKIM are configured but they do not align with the From domain (the relaxed or strict alignment setting in the DMARC record), the DMARC check can fail even with valid authentication. Many organizations have this misconfiguration without knowing it. SPF and DKIM alignment under DMARC is worth reviewing carefully.
Fifth, monitoring evidence. Some QSAs will ask for DMARC aggregate reports as evidence that authentication is being monitored. If your rua address is an email inbox nobody reads, that will show up in an audit. A DMARC report aggregation tool (there are several free options) that shows regular review of authentication failures is a stronger evidence artifact.
The p=none Problem for Payment Businesses
Here is the position many organizations are in right now: they have a DMARC record set up, it was set up during a deliverability project a few years ago, it is still at p=none, and nobody has moved it because moving to p=quarantine feels risky.
The risk is real, but it is often overstated. Moving to p=quarantine causes authentication-failing email to land in spam rather than inbox. If your authentication is configured correctly, legitimate mail should not be failing authentication checks. The fear is usually about third-party sending services that have not been properly authenticated.
The right sequence before moving to p=quarantine: spend 30 to 60 days actively reading DMARC aggregate reports to identify every source of email sending from your domain. You are looking for your ESP, your transactional email provider, any marketing automation tools, and any third parties who send on your behalf. Each of them needs to be in your SPF record and needs to be DKIM-signing with a key for your domain.
Once you have a clean aggregate report with no legitimate sending sources failing authentication, you can move to p=quarantine with low risk. Moving from p=none to p=quarantine and p=reject covers this migration in detail.
For PCI purposes, the monitoring period under p=none does not satisfy Requirement 5.4.1. You need to complete the monitoring phase and move to at least p=quarantine. The deadline for that was March 2025. You are late. The practical next step is to set a timeline and document it in your risk register.
A Compliance Remediation Timeline That Works
The organizations I have watched get through late compliance successfully have run a roughly 60-day remediation arc rather than trying to hit the requirement in a weekend. The compressed version usually fails because legitimate sending sources get filtered once p=quarantine goes live, which creates urgent incident response and undermines confidence in the whole project.
The first two weeks are pure monitoring. Publish a p=none DMARC record with a rua tag pointed at an aggregation service (dmarcian, EasyDMARC, or a similar tool). Do nothing else. Let the reports flow for ten to fourteen days so you have a representative sample of your sending sources, including any weekly or monthly senders that might not appear in a shorter window.
Weeks three and four are source cleanup. Every source appearing in your aggregate reports gets classified: legitimate sender that needs authentication fixes, legitimate sender already authenticated correctly, third-party sender you no longer use, or unknown sender that needs investigation. The legitimate senders that need fixes get SPF includes added or DKIM signing configured with your domain keys. The ones you no longer use get removed from SPF records if they are still there.
Weeks five and six are the authentication verification phase. Send test messages through each source and confirm DMARC alignment in the actual message headers. Tools like mail-tester.com and the DMARC aggregate reports themselves show whether each source is now producing DMARC-passing mail. Any source still failing gets another round of configuration work.
Weeks seven and eight are the policy transition. Move to p=quarantine with pct=25 first (applying the policy to only 25% of failing mail as a safety valve). Monitor for a week. If no incidents, move to pct=100. Then monitor for another week before documenting the compliance state for your QSA. For some organizations, the move from quarantine to reject happens in a subsequent quarter once monitoring confirms stability, which is an approach most QSAs accept if documented in the risk register.
This arc is annoying but reliable. The organizations that skip the monitoring phase because "we know our senders" almost always discover an unauthorized or misconfigured source after flipping the policy, and the cleanup happens under fire instead of in a controlled window. Pair this remediation with list hygiene through email verification so your compliance work is not undermined by bounce-driven reputation noise during the transition.
Subdomains and Unused Domains Are Also at Risk
A detail that catches organizations off guard: PCI DSS DMARC requirements apply to your domain even for subdomains you never use for email. If an attacker spoofs support.yourcompany.com in a phishing email, and that subdomain has no DMARC record, the attack may succeed because the subdomain is unauthenticated.
DMARC has a subdomain policy option (sp= in the record) that lets you apply your main domain policy to subdomains. The default behavior when no sp= is set is that subdomains inherit the parent policy for subdomains that have no DMARC record of their own. But this inheritance only applies if the parent domain's DMARC policy is at quarantine or reject. A p=none parent domain does not protect unauthenticated subdomains.
For PCI compliance, catalog all subdomains associated with your organization's domains. For any subdomain that sends email, set up DMARC directly. For subdomains that never send email, create a DMARC record with p=reject and v=DMARC1; p=reject; explicitly, rather than relying on inheritance. This closes the spoofing vector for unused subdomains.
The same logic applies to older domains your organization owns but has not actively used. A domain you stopped using for email three years ago can still be spoofed if it has no DMARC record. Payment-related domain names that your company owns but does not actively use are especially valuable targets for phishing attacks because they look legitimate to recipients.
How DMARC Intersects With Ecommerce Email Operations
Ecommerce operators typically run several distinct email streams from their domain or subdomains: order confirmations, shipping notifications, account registration, promotional campaigns, loyalty program communications, and customer service replies. Each stream may go through a different sending service.
This multi-stream setup creates authentication complexity. Your order confirmations might go through Shopify or Magento's built-in transactional email. Your promotional campaigns go through Klaviyo. Your customer service tickets route through Zendesk or Freshdesk. Each of these services may handle email authentication differently.
For DMARC to be effective across all streams, each service needs to be either included in your SPF record or DKIM-signing with a key for your domain, preferably both. If even one of these services sends unauthenticated mail from your domain, it will show up in DMARC aggregate reports as a failing source. Under p=quarantine or p=reject, those messages will be filtered.
The practical audit process: look at your DMARC aggregate reports and filter for any source with a nonzero DMARC fail rate. Identify what service or IP that source belongs to (the report shows the sending IP, which you can look up against known ESP IP ranges). Contact that service to understand how to set up proper authentication. Most major ESPs support customer DKIM signing as a configuration step.
Verifying email list quality before campaigns is directly relevant here because sending to bad addresses generates bounces, which can create noise in authentication reports and makes it harder to distinguish legitimate authentication issues from delivery problems.
The Intersection With Google and Microsoft Requirements
One thing that makes the PCI DSS situation somewhat easier to accept: the direction of the entire email industry is the same direction PCI is requiring. Google's enforcement for Gmail and Microsoft's DMARC enforcement for Outlook are both pushing toward authenticated mail at p=quarantine or p=reject as the baseline.
This means compliance with PCI DSS v4.0 Requirement 5.4.1 and compliance with inbox placement best practices are largely the same project. You are not doing separate work for auditors versus email performance. A properly authenticated domain with p=reject will satisfy PCI requirements and will see better inbox placement on Gmail and Outlook simultaneously.
The difference is urgency. Deliverability optimization is a revenue question. PCI DSS compliance is a legal and contractual requirement that can result in fines, loss of payment processing capability, and breach liability. For an ecommerce operator, the threat of losing payment processing access is existential. That context should make the priority clear.
If you have a QSA assessment coming up and you are not yet at p=quarantine, spend the next two weeks getting DMARC aggregate reports flowing into a readable format and auditing your sending sources. That is the work that needs to happen before you can safely flip the policy value. The flip itself takes about five minutes. The preparation is the real work.
Start by looking up your current DMARC record. If it says p=none, set a 60-day deadline to reach p=quarantine. If you do not have a DMARC record at all, creating one with p=none and a rua address is a same-day project and starts your monitoring clock immediately.