Guide
PCI DSS v4.0 and DMARC — What You Need to Be Compliant
PCI DSS v4.0 became fully mandatory in March 2025. It includes specific requirements for anti-phishing controls — and DMARC p=reject is the standard way to meet them. If your organisation handles payment card data, this is no longer optional.
This isn't generic security theatre. Requirement 5.4.1 expects real anti-phishing controls. DMARC at p=reject is what auditors look for when they ask how you stop domain spoofing. Our DMARC guide is the implementation path; this page is the compliance lens. Verify everything in DNS Preflight and the report analyzer before you walk into a QSAC interview empty-handed.
What PCI DSS v4.0 Requires
Requirement 5.4.1 covers anti-phishing technology. It expects controls that detect and protect against phishing.
p=reject satisfies the intent because it:
- Stops domain spoofing — attackers can't pass mail that fails DMARC for your From domain
- Feeds evidence through aggregate reports when someone tries
- Shows you actively control the mail channel, not just “monitoring” it
p=none does not satisfy the requirement. Watching without enforcement isn't an anti-phishing control. See why p=none still hurts and when to leave it.
The Full Compliance Checklist
PCI DSS v4.0 email authentication checklist:
- □ SPF record published and passing
- □ DKIM configured and passing alignment
- □ DMARC record at p=reject
- □ DMARC aggregate reports (
rua=) configured - □ No alignment failures in aggregate reports
- □ All third-party senders aligned
- □ DMARC reports reviewed regularly
- □ PTR record for sending IP
- □ Sending IP not on major blocklists
How to Verify Each Item
Run DNS Preflight on your domain. The health score and individual cards show pass/fail for most of this.
For DMARC reports, use DomainPreflight DMARC Report Analyzer — paste XML and confirm you're not hiding alignment failures.
Common Gaps Found During PCI Audits
Gap 1: DMARC at p=none
The most common failure. Auditors look for p=quarantine or p=reject. p=none is explicitly weak tea.
Gap 2: Third-party sender misalignment
Corporate mail is clean. Marketing sends misaligned bulk from the same brand domain. Both have to align before p=reject is safe. Use alignment language with your vendors.
Gap 3: No aggregate reporting
Some teams publish p=reject without rua=. You can't prove monitoring. Add rua=mailto:… and keep the mailbox alive.
Gap 4: Missing PTR
Self-hosted MTA without PTR fails basic infrastructure checks. Fix rDNS before the audit packet ships.
What Auditors Ask For
- Screenshot of DMARC DNS showing
p=reject - Sample aggregate report with no alignment failures
- Evidence of regular review (calendar, tickets, postmortems)
- List of authorised sending services — match to DMARC fix guides
Export or screenshot DNS Preflight after a clean run. That's your quick evidence trail alongside raw DNS screenshots.
Tools: Preflight for live DNS, analyzer for XML — use both before you sign attestation docs.
Step by step
FAQ
Does PCI DSS v4.0 require DMARC?
Yes — Requirement 5.4.1 requires anti-phishing controls. DMARC p=reject is the standard implementation. p=none does not satisfy the requirement.
When did PCI DSS v4.0 become mandatory?
PCI DSS v4.0 became fully mandatory in March 2025. All organisations handling payment card data must comply.
Is DMARC p=quarantine enough for PCI DSS?
p=quarantine provides partial protection but p=reject is the recommended implementation. Auditors increasingly expect p=reject for full compliance.
How do I prove DMARC compliance to an auditor?
Screenshot your DNS Preflight results showing p=reject, provide sample aggregate reports showing no failures, and document your regular monitoring process.
What happens if a third-party sender breaks DMARC alignment?
Emails from that sender will be rejected under p=reject. Fix alignment for all senders before moving to p=reject — use the DMARC provider fix guides.