Does PCI DSS require DMARC?

21 June 2026 · 15 min read

Short answer: yes, PCI DSS version 4 names DMARC by name, and this is the first version of the standard to do so. Earlier versions of PCI DSS talked about anti-phishing in general terms and left the technology choice to you. Version 4.0 closed that gap. The guidance attached to its anti-phishing requirement explicitly lists DMARC, alongside SPF and DKIM, as the kind of automated mechanism the standard expects you to deploy to protect personnel from phishing. So if your organisation stores, processes or transmits cardholder data, and you are being assessed against PCI DSS v4, email authentication is no longer an optional nicety: it is the named, expected way to satisfy a specific control. This article explains exactly where DMARC appears in the standard, what "required" versus "best practice" means in PCI terms, why an honest reading still points firmly at enforcement, and how to meet the control with hosted authentication that will not break your legitimate mail.

We will keep the language plain and define each technical term the first time it appears. You do not need to be a QSA (a Qualified Security Assessor, the auditor who validates PCI compliance) to follow it.

What PCI DSS is and who it applies to

PCI DSS stands for the Payment Card Industry Data Security Standard. It is maintained by the PCI Security Standards Council, a body founded by the major card brands (Visa, Mastercard, American Express, Discover and JCB). Any organisation that stores, processes or transmits cardholder data, or that can affect the security of that data, falls within its scope. That covers far more than just retailers: it includes payment service providers, e-commerce platforms, software-as-a-service companies that touch card data, hosting providers, and the in-house teams that run all of the above.

PCI DSS is contractual rather than statutory. You do not comply because a government tells you to; you comply because your acquiring bank and the card brands require it, and the penalty for not complying ranges from fines to losing the ability to take card payments at all. That contractual force is part of why the v4 mention of DMARC matters: unlike a vague legal "reasonable safeguards" obligation, PCI DSS comes with a defined assessment process, named requirements, and an auditor who will ask you to show evidence against each one.

The current version is PCI DSS v4.0, published in 2022, with v4.0.1 following as a maintenance update. The standard set a transition timeline: v3.2.1 was retired, v4 became mandatory, and a set of "future-dated" requirements that were best practice during the transition became fully required from the deadline in early 2025. The anti-phishing requirement is one of those future-dated items, which is the single most important nuance in this whole topic and we will come back to it.

If you want to see where your own domain stands before reading on, run it through the free DMARC checker. It takes a few seconds and the rest of this article will make more sense against your real configuration.

Where DMARC actually appears in PCI DSS v4

The relevant control lives in Requirement 5, which in v4 was broadened from "anti-virus" to the wider goal of protecting all systems and networks from malicious software. Within it sits a sub-requirement about phishing:

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

That is the requirement text, and on its face it does not say DMARC. It says "automated mechanisms" against phishing. The crucial detail is in the guidance and examples the Council publishes alongside the requirement. There, the standard spells out what those automated mechanisms look like, and it explicitly names the email authentication trio. The guidance points to anti-spoofing controls such as DMARC, SPF and DKIM as mechanisms that detect and block phishing and spoofed email at the server level, before it reaches a person who might click it.

In other words, the requirement is technology-neutral in its headline but technology-specific in its guidance. The standard is telling you, in as many words, that publishing and enforcing DMARC (with SPF and DKIM underneath it) is the expected way to satisfy 5.4.1 for inbound spoofing protection. An assessor reading your evidence against 5.4.1 will reasonably expect to see these records in place and working.

There is an important scoping subtlety. Requirement 5.4.1 is framed around protecting your personnel from phishing, which is principally about inbound mail: stopping spoofed messages reaching your staff. DMARC on your own domain protects the outbound identity: it stops other people sending mail that forges your domain to your customers and your own staff. These two angles meet in the middle. A DMARC policy of p=reject on your domain means a fraudster cannot spoof your own domain back at your finance team, which is one of the most common phishing vectors in payment fraud (the "the CFO needs this invoice paid" attack that uses your own brand against you). So your own DMARC enforcement is both an outbound brand-protection control and a direct contributor to the inbound personnel protection 5.4.1 is asking for.

"Required" versus "best practice": the nuance that matters

People get tripped up by PCI's transition language, so let us be precise.

When v4.0 first published, Requirement 5.4.1 was marked as a future-dated requirement. During the transition window it was a best practice, meaning an assessor would note it but you would not fail your assessment solely for missing it. From the future-dated deadline (31 March 2025), it became a fully effective, mandatory requirement. As of now, in mid-2026, that date is well behind us. So:

If you are being assessed against PCI DSS v4.0 or v4.0.1 today, Requirement 5.4.1 is in full effect, and anti-phishing automated mechanisms are required, with DMARC, SPF and DKIM named as the expected mechanisms.
The requirement text says "automated mechanisms," not literally "you must publish DMARC," so in the strictest letter you could argue an alternative control. In practice, DMARC is the named, standard, widely accepted answer, and choosing not to deploy it leaves you explaining to your assessor why you rejected the very mechanism the guidance lists first.

So the honest framing is this: PCI DSS v4 does not contain a line that reads "DMARC is mandatory" in the requirement itself, but it names DMARC as the expected mechanism for a requirement that is now mandatory. For any practical purpose, treat DMARC as required for PCI DSS v4 compliance, and treat SPF and DKIM as the foundations it depends on.

Why the three records work together

To satisfy 5.4.1 properly you need all three records, because each does a different job and none is sufficient alone. If a term is new to you, the email authentication overview walks through the whole stack, and the glossary defines each one.

SPF: which servers may send for you

SPF stands for Sender Policy Framework. It answers a narrow question: is the server that delivered this email on the list of servers I have authorised to send for my domain? You publish one TXT record in DNS (the Domain Name System, the public directory of the internet) listing your legitimate sending sources. A simple record looks like this:

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

v=spf1 marks it as SPF, each include: pulls in a named provider's servers, and -all means anything not listed is not authorised. SPF has two well-known limits. It checks the hidden envelope sender, not the visible From address a human reads, so on its own it does nothing about the address a phishing victim actually sees. And it has a hard ceiling: an SPF record may trigger at most ten DNS lookups when evaluated, and exceeding it returns a state called PermError that receivers may treat as no SPF at all. Payment-handling organisations accumulate sending tools quickly (receipts, fraud alerts, statements, support desk, marketing) and quietly blow past this limit. Check your own count with the SPF checker, and if you are over, read fix a failing SPF record. Our automatic SPF flattening keeps you under ten lookups without manual surgery.

DKIM: a tamper-evident signature

DKIM stands for DomainKeys Identified Mail. Where SPF is about which server sent the mail, DKIM is about the message itself. It uses a pair of cryptographic keys: your provider holds a private key and signs outgoing mail, and you publish the matching public key in DNS. The receiving server fetches the public key and verifies the signature. This proves two things at once: that the message really was authorised by your domain, and that the content was not altered after signing. Confirm your domain is signing correctly with the DKIM checker, and see the managed signing product at /products/dkim.

DMARC: the policy that protects the visible From

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. SPF and DKIM each prove something useful, but neither protects the address a human actually reads, and neither tells receivers what to do on failure. DMARC fills both gaps. It does three jobs:

Alignment: it requires that the domain validated by SPF or DKIM matches the visible From domain your recipients see. This is the piece that finally protects the human-readable address, closing the gap SPF and DKIM leave open.
Policy: it tells the world what to do with mail claiming to be from you that fails authentication. The policy values are p=none (monitor only, take no action), p=quarantine (send to spam) and p=reject (refuse outright).
Reporting: it asks receivers to send you aggregate reports, daily XML summaries of who is sending mail using your domain and whether it passed. This is your visibility into both your legitimate senders and anyone impersonating you.

A DMARC record at _dmarc.yourdomain.com looks like this:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; adkim=s; aspf=s

p=reject is the goal state. At reject, a message that forges your domain in the From line and fails authentication is refused by the receiving server before it ever reaches a customer or a member of your finance team. That is the control that actually stops spoofed phishing carrying your brand. See the DMARC product page and our guide on how to check DMARC is working. For background on why this matters at all, why your domain can be spoofed explains the underlying weakness in email.

Does PCI DSS require p=reject specifically?

This is the most common follow-up question, and the honest answer is: the standard does not put a number or a policy level on it. Requirement 5.4.1 asks for automated mechanisms against phishing; the guidance names DMARC; it does not say "your policy must be p=reject." So in the strict letter, a published DMARC record at p=none is technically a DMARC deployment.

But read it the way an assessor will. A policy of p=none is monitor only: it tells receiving servers to take no action on mail that forges your domain. It generates reports, which is genuinely useful, but it blocks nothing. A control whose entire purpose is to "detect and protect against phishing" does not protect anything if it is set to do nothing. An assessor who understands DMARC will quite reasonably regard a permanent p=none as an incomplete implementation of the control, in the same way a firewall left in log-only mode is not really filtering traffic. The defensible position is enforcement: p=quarantine or, better, p=reject, so that spoofed mail is actually stopped. Treat p=none as a temporary staging state on the way to enforcement, not as your finished answer to 5.4.1.

Two related notes assessors appreciate:

Apply DMARC to your sending domains and to domains you do not send from. A common gap is leaving parked or non-sending domains with no DMARC, which lets attackers spoof them freely. A non-sending domain should carry a strict v=DMARC1; p=reject; with no senders authorised in SPF.
Subdomains matter. The sp= tag controls subdomain policy. If you do not set it, subdomains inherit the parent policy, but it is worth being explicit so a forgotten subdomain is not a soft spot.

Why you should not jump straight to p=reject

Here is the trap that catches PCI teams under deadline pressure. Knowing that enforcement is the goal, someone publishes p=reject on a Monday morning. By Wednesday the receipt service, the fraud-alert platform, the statements system and the marketing tool, none of which were properly aligned, are all failing DMARC, and legitimate customer mail is being rejected. For a payment business this is acute: a customer who never receives a transaction receipt or a fraud alert is a support ticket at best and a chargeback or a churned account at worst.

The safe path is the whole reason DMARC includes a monitoring mode:

Start at p=none. This changes nothing about delivery. It turns on reporting so you can see every system sending mail using your domain, including the ones nobody documented.
Read the aggregate reports and fix alignment for each legitimate sender, one by one. The raw XML is unreadable by hand, so use the DMARC report analyzer or read how to read a DMARC aggregate report.
Move to p=quarantine, often on a percentage of mail first, watching that nothing legitimate is caught.
Reach p=reject once the reports show only known, aligned senders failing.

This staged journey, from p=none to p=reject with no email outage, is exactly what DMARC Engine is built to manage. It watches the reports, tells you which senders still need fixing, and advances policy only when the evidence says it is safe. Our done-for-you DMARC enforcement explains the managed version, and how long to reach p=reject sets realistic expectations on timing, which matters when you have an assessment date in the diary.

Where MTA-STS and TLS fit a payment context

Authentication proves who sent a message and that it was not altered. PCI DSS also cares a great deal about strong cryptography during transmission of cardholder data over open, public networks (Requirement 4). Email is one such network. By default, the encryption between mail servers is opportunistic: if a TLS (Transport Layer Security) connection cannot be established, many servers quietly fall back to plain text, and an attacker positioned in the network can strip encryption or read the contents.

MTA-STS stands for Mail Transfer Agent Strict Transport Security. It lets you publish a policy that says mail servers must use TLS to deliver to your domain and must refuse to fall back to plaintext. Its companion, TLS-RPT (TLS Reporting), sends you reports when a sender's TLS connection to your domain fails, so a downgrade attack or a broken configuration does not stay invisible. Check both with the MTA-STS checker and the TLS-RPT checker, and see the MTA-STS product page.

A caveat worth stating plainly: you should not be putting full cardholder data such as a primary account number into email in the first place, and PCI DSS forbids sending unprotected PANs by end-user messaging technologies. MTA-STS does not change that rule. It protects the transmission layer of the mail your domain does send, and it pairs naturally with the authentication stack as part of a defensible Requirement 4 and Requirement 5 story. It is one layer among several, not a licence to email card numbers.

BIMI: not required, but a by-product worth knowing about

BIMI, Brand Indicators for Message Identification, lets a verified logo show next to your messages in supporting inboxes. It is not a PCI control and it appears nowhere in the standard. It is worth a single mention only because the same enforcement work that satisfies 5.4.1 (reaching p=quarantine or p=reject) is the prerequisite for BIMI. So a payment brand that does the compliance work also unlocks a visible trust signal for customers who are increasingly wary of payment phishing. Explore it with the BIMI checker and the BIMI product page, but remember enforcement comes first.

A practical checklist to satisfy 5.4.1 with evidence

PCI assessment is evidence-driven. It is not enough to do the work; you must be able to show the assessor it is done and working. Here is a defensible target for an organisation in PCI scope:

Inventory every system that sends mail using your domain. Receipts, fraud alerts, statements, the help desk, marketing, internal tools. You cannot secure senders you have not listed. The DMARC report analyzer will surface ones you forgot once monitoring is on.
Publish SPF covering every legitimate sender, and keep it under the ten-lookup limit. Verify with the SPF checker.
Enable DKIM signing on every sending platform, each signing with a key aligned to your domain. Verify with the DKIM checker.
Publish DMARC at p=none with a rua reporting address, and actually read the reports. This is the visibility step where most of the real work happens.
Fix alignment for each legitimate sender until the reports are clean.
Advance the DMARC policy to p=quarantine, then p=reject, on the evidence, not the calendar.
Cover non-sending and parked domains with a strict reject policy so they cannot be spoofed.
Add MTA-STS in enforce mode with TLS-RPT to support the transmission-security requirement and catch encryption downgrades.
Keep dated evidence. Screenshots of published records, the policy progression with dates, and the aggregate reports themselves are exactly the artefacts an assessor wants. Your DMARC reports are dated proof the control is live and working.

For the broader picture of the modern email requirements that drive all of this, including the bulk-sender rules at Gmail and Yahoo that overlap heavily with PCI's expectations, see the requirements page. If you also handle health data, our companion piece on HIPAA and email authentication covers the same controls under a different regime.

Where DMARC Engine fits

The honest summary is this. PCI DSS v4 is the first version of the standard to name DMARC, and it does so in the guidance to Requirement 5.4.1, a requirement that is now fully in force. The headline text says "automated mechanisms" against phishing; the guidance names DMARC, SPF and DKIM as those mechanisms. For any practical purpose, treat email authentication as required for PCI DSS v4, treat enforcement (p=quarantine or p=reject) as the defensible target rather than a permanent p=none, and treat the aggregate reports as your evidence.

The hard part is not knowing that. The hard part is getting to enforcement without rejecting legitimate payment mail, keeping SPF under its lookup limit as you add tools, signing every sender correctly, covering your parked domains, enforcing TLS, and keeping dated evidence that it all works in time for an assessment.

DMARC Engine is a done-for-you hosted platform that handles exactly that, on Cloudflare, taking a domain safely from p=none to p=reject with no email outage. It manages SPF flattening, DKIM, MTA-STS and BIMI, reads your aggregate reports for you, and emails you when something needs attention. You can run the free diagnostic tools above with no account, and when you are ready to manage enforcement properly the dashboard lives at app.dmarcengine.com. None of this is a substitute for your QSA's judgement, and your compliance posture is ultimately yours to document, but the email authentication layer of it is precisely the part we make straightforward.