Does PCI DSS 4.0 require DMARC? What requirement 5.4.1 means

Who requirement 5.4.1 applies to

Requirement 5.4.1 was listed as a future-dated best practice in PCI DSS v4.0, so assessments before March 31, 2025 could leave it out. That date has passed, and it is now assessed like any other requirement.

Scope follows the assessed environment rather than an industry label. It covers:

• Any entity or service provider that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD).
• The people, processes, and system components involved in those flows.
• System components with unrestricted connectivity to systems handling CHD or SAD, even when they never touch that data themselves.

Merchants, acquirers, issuers, processors, and their vendors are all covered when they meet those conditions. Your assessor sets the final boundary for the environment in scope.

When the answer changes

The answer remains no if the question is whether PCI DSS 4.0 explicitly requires a DMARC record, a specific tag, or a specific enforcement policy. None is specified in requirement 5.4.1.

The operational answer changes when the question becomes whether DMARC is useful evidence for an anti-phishing control. In that case, DMARC can be relevant if the organization controls the From domain, publishes a valid record, and has verified that legitimate production senders authenticate with aligned SPF or DKIM.

Use this decision rule:

• If the goal is to show that a domain has published a DMARC policy, inspect the DNS record.
• If the goal is to show that an application sends authenticated mail, inspect a real delivered message from that application and its Authentication-Results header.
• If the goal is to show protection against phishing generally, include the automated inbound controls that detect and protect personnel, not only outbound domain authentication.
• If the goal is an assessment conclusion, retain the evidence your assessor requires for the scoped environment.

A DNS result is not proof that a mail platform signs production messages, that receivers apply a requested policy, or that every phishing message is detected.

Requirement 5.4.1 should also not be confused with an SMTP reply code containing 5.4.1. The Microsoft 550 5.4.1 recipient-address guide and Microsoft SMTP relay-error guide concern message-delivery errors, not PCI DSS requirement numbering.

Worked evidence example for DMARC

A DMARC record is published as a DNS TXT record at the _dmarc name for the domain. This is illustrative only. Do not publish another organization's reporting address or reuse its values.

Host: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

This example gives useful evidence about one narrow point: yourdomain.com requests quarantine handling for messages that fail DMARC, and it requests aggregate reports at the listed address.

It does not establish that the reporting mailbox receives or processes reports. It also does not prove that each legitimate sender using yourdomain.com passes DMARC, that a receiver accepted the requested handling, or that inbound phishing defenses detect a lookalike domain.

For a meaningful operating check, validate separate layers:

• DNS: query the authoritative DNS server and a public resolver for the intended record.
• Sending platform: confirm the platform's current domain-authentication status.
• Message: send a test message through the exact production path and inspect its Authentication-Results fields. RFC 8601 defines this header field for communicating message-authentication results.
• DMARC: review aggregate-report data after it has accumulated to identify sources and authentication or alignment failures.

Rolling out DMARC before an assessment

DMARC becomes useful evidence only once legitimate senders authenticate. Publishing an enforcing policy on a domain whose senders are not aligned tells receivers to act against your own mail, which is a worse outcome than publishing nothing.

Work through it in order:

1. Inventory the sending domains in scope and check what each one publishes today with the DMARC checker and the Email Security Score.
2. Publish p=none with a rua address. Mail flow is unchanged, and aggregate reports start naming the sources sending as your domain.
3. Read the reports until every legitimate source is accounted for, then fix the SPF and DKIM gaps that surface. Third-party platforms sending on your behalf are the usual source of failures.
4. Move to p=quarantine and watch for legitimate mail landing in spam folders.
5. Move to p=reject once report data stays clean.

Steps 2 through 5 leave dated artifacts behind: the record as published, the report data behind each policy change, and the date each change took effect. That trail is more useful to an assessment than the record alone. Moving from quarantine to reject is the step to take slowly, and reading aggregate reports is what tells you when to take it.

What to do next

Start with the evidence you have.

If you only know the domain name, use the DMARC checker to inspect the public DMARC record and its policy tags. Compare the result with the record your organization intended to publish.

If you administer the sending path, send a controlled message through each important application, gateway, and provider. Preserve a redacted copy of the delivered headers and compare the visible From domain with SPF and DKIM results.

If you are preparing PCI DSS evidence, document the automated controls that protect personnel from phishing, their owners, and the evidence that they are operating in the relevant environment. DMARC can support that record, but it should remain scoped as an anti-spoofing measure rather than the entire requirement.

Check the DMARC record that supports your evidence

Run the sending domain through Palisade's DMARC checker to inspect the record currently visible in public DNS before comparing it with message-level evidence and your wider anti-phishing controls.

Check the published DMARC record

A public record check cannot prove that every production sender is aligned, repair a phishing-control gap, monitor future DNS changes, or establish a receiver's final message decision. For teams that need to inventory sending sources and work through DMARC remediation over time, Start with Palisade. Palisade analyzes DMARC aggregate-report data and proposes prioritized remediation work, while a human reviews the evidence and applies any change.