DMARC for PCI DSS 4.0 compliance
If you store, process or transmit cardholder data, PCI DSS 4.0 requirement 5.4.1 makes anti-phishing controls mandatory. DMARC is the standard answer. Blankitt gets your domains to safe enforcement and hands your assessor exportable evidence — UK-built, UK-supported, with a self-host option.
Free domain check — no account required.
What requirement 5.4.1 actually asks for
PCI DSS 4.0 requirement 5.4.1 requires that processes and automated mechanisms are in place to detect and protect personnel against phishing attacks. It has been a defined requirement — not a future-dated best practice — since 31 March 2025. The standard does not name a specific product, but for protecting your own domains from being spoofed, DMARC together with SPF and DKIM is the control your assessor expects to see in operation.
The risk here is concrete. If an attacker can send mail that appears to come from your domain, they can phish your finance team, your customers and your card-data environment using your own brand. A published DMARC policy at enforcement tells receiving mailbox providers to reject or quarantine that spoofed mail before it lands. Reporting tells you it happened and proves the control is working.
Why card-handling teams get stuck
Most organisations that handle cards already publish a DMARC record, but it sits at p=none — monitoring only, enforcing nothing. That is the worst of both worlds for an assessment: you are still spoofable, and you have little to show that the control is genuinely operating. The reason teams stall is fear: payment gateways, CRMs, e-commerce platforms, helpdesks and finance tools all send mail as you, and tightening the policy without first authorising them can drop legitimate, revenue-critical email.
Apple iCloud now treats p=none as a negative signal, and Gmail and Outlook escalated bulk-sender enforcement to outright rejection of non-compliant mail. So the compliance driver and the deliverability driver now point the same way: get off p=none safely.
How Blankitt DMARC solves it
Blankitt ingests your DMARC aggregate (RUA) and forensic (RUF) reports — either from a unique reporting address you publish in DNS, or from a connected Microsoft 365 / Google Workspace mailbox — and turns the raw XML into a clear picture of who is sending as you and whether they authenticate. It detects common sending vendors automatically, so you can quickly separate the senders to authorise from the senders to block.
From there, the product gives your compliance lead and QSA what they need:
- A live view of your published policy across every domain you monitor.
- Sender-by-sender SPF and DKIM alignment results.
- Dated assessments showing progress from monitoring to enforcement.
- CSV export of the underlying report data for your evidence pack.
That continuous record is the difference between “we have a DMARC record” and “here is evidence the control was operating throughout the assessment period.”
The guided path to p=reject
Blankitt's job is to get your domain to safe enforcement so mailbox providers trust it — not to guarantee inbox placement. The path is deliberately staged so you never enforce against mail you have not yet accounted for:
- Monitor at p=none. Collect reports and build a complete inventory of every service sending as you.
- Authenticate your real senders. Fix SPF (staying under the 10-lookup limit) and DKIM for each legitimate vendor, using vendor-specific fix guidance.
- Move to quarantine. Use the policy simulator to preview the impact before you change DNS, then tighten with confidence.
- Reach reject. Once your legitimate senders are aligned, move to
p=reject— the position that satisfies the spirit of 5.4.1 and shuts down domain spoofing.
Where the data lives matters
DMARC failure reports describe mail sent as your domains and can contain third-party IP addresses and message-level metadata — personal data under UK GDPR, with US CLOUD Act exposure if it sits on a US-only platform. Nearly every incumbent DMARC vendor is US-SaaS only. Blankitt processes your reports encrypted and tenant-isolated on Cloudflare's UK and EU regions. If your card-data environment means data genuinely cannot leave your walls, the same product self-hosts on your own infrastructure with Docker, air-gap friendly.
And because Blankitt is part of one suite, DMARC sits behind a single login and a single bill alongside Blankitt's IT, Finance, HR and GRC tools — one fewer vendor for your assessor to review, and one fewer DPA to chase. See the full product overview for the complete feature set.
Built for a clean PCI sign-off
Maps to requirement 5.4.1
An operating DMARC control with reporting is the recognised technical answer to the anti-phishing requirement — exactly what your assessor is looking to evidence.
Exportable evidence
CSV export of aggregate and forensic data, dated assessments and policy history. A clean trail that the control was in operation across the assessment period.
Guided path to enforcement
A plain-English route from p=none to quarantine to reject, with a policy simulator so you tighten the screw without dropping legitimate mail.
Sender visibility
Common sending vendors detected automatically, so you can authorise the payment gateways, CRMs and ticketing tools that legitimately send as you before you enforce.
UK / EU data residency
Reports contain personal data. We process them in the UK and EU on Cloudflare, with a self-host option for environments where data cannot leave your walls.
Every feature on every plan
Forensic reports, API, SSO and mailbox sync are included on every tier — we gate only on domain count and retention, never on the features your auditor needs.
PCI DSS & DMARC — frequently asked
Does PCI DSS 4.0 actually require DMARC?
PCI DSS 4.0 requirement 5.4.1 requires processes and automated mechanisms to detect and protect personnel against phishing attacks. The standard does not name DMARC by brand, but DMARC (with SPF and DKIM) is the recognised technical control for stopping attackers spoofing your own domains, so it is the answer most assessors expect to see evidenced. It became a defined requirement on 31 March 2025.
Do I need to be at p=reject to pass my assessment?
Requirement 5.4.1 is about having and operating an anti-phishing mechanism, not a specific DMARC policy value. That said, a domain stuck at p=none gives the assessor little to evidence and leaves you spoofable, so the practical goal is enforcement (quarantine or reject) on the domains that send mail. Blankitt's policy simulator helps you reach reject safely without breaking legitimate senders.
What evidence can I give my QSA?
Blankitt parses your DMARC aggregate (RUA) and forensic (RUF) reports and lets you export the underlying data and dated assessments as CSV. You can show your published policy, which senders are authenticating, your progression from p=none to enforcement, and a continuous record that the control is in operation across the assessment period.
DMARC failure reports can contain personal data — where is it processed?
DMARC reports describe mail sent as your domains and can include third-party IP addresses and message metadata, which is personal data under UK GDPR. Blankitt processes your reports encrypted and tenant-isolated on Cloudflare's UK and EU regions, with no US-SaaS-only dependency. If your data cannot leave your walls, the same product self-hosts on your own infrastructure.
How quickly can I get started?
Run a free check at blankitt.com/dmarc/check to see your current DMARC, SPF and DKIM status with no account. To start collecting reports, create a free account, publish your unique reporting address or connect a Microsoft 365 / Google Workspace mailbox, and you will see your first parsed report within a day.
See where your domain stands today
Run a free DMARC, SPF and DKIM check — no account, no card. Then start monitoring and build the evidence your assessor needs.