Compliance crosswalk · PCI
PCI DSS 4.0 - email + domain controls, mapped to Wiredepth
Framework version: v4.0 + 4.0.1 amendments (in force March 2025)
Who this is for. Merchants, service providers, payment processors, and any organization with stored, processed, or transmitted cardholder data. Compliance is mandated by the card brands and enforced via QSA assessments + Self-Assessment Questionnaires (SAQs).
Where email + domain controls fit.PCI DSS doesn't have a stand-alone "email" section, but several requirements touch the surface directly: encrypted-transit boundaries (Req. 4), authentication of senders (Req. 8), continuous testing of controls (Req. 11), and configuration hygiene of mail servers + DNS (Req. 1, 2). The 4.0 update added explicit language about anti-phishing controls (Req. 5.4 - new in 4.0) which is where DMARC sits.
Clause-by-clause mapping
Each row maps a specific PCIrequirement to the Wiredepth surface that addresses it. The clause ids are the framework's own naming - verify them against the official text. We use precise language: "addresses" (the tool directly satisfies the control), "supports" (the tool contributes evidence the auditor will need), and "evidence for" (the artifact is part of the attestation package).
| Clause | Requirement | Wiredepth response |
|---|---|---|
Req. 4.2.1 Transport | Strong cryptography and security protocols protect cardholder data during transmission over open, public networks. Applies to mail transport when receipts / invoices contain PAN or sensitive data. | MTA-STS + TLS-RPT checker verifies enforce-mode policy on the sending domain. TLS / SSL checker validates the broader web surface. |
Req. 1.4 Inventory | Network connections between trusted and untrusted networks are controlled. Includes outbound mail relays + SaaS providers authorized to send as the cardholder-data domain. | Vendor consolidation report inventories every third party authorized in SPF / DKIM / MX / DMARC. Blast-radius rating exposes which vendors could spoof your card-receipt mail. |
Req. 2.2 Authentication | System configuration standards address all known security vulnerabilities and are consistent with industry-accepted hardening standards. DMARC / SPF / DKIM are now industry-accepted for email-sending domains. | DMARC + SPF analyzer scores the policy strictness. Spoofability checker gives a yes / maybe / no verdict an assessor can cite. |
Req. 8.3 Authentication | Strong authentication for all access into the CDE. By extension - sender authentication for any system that emails customers about their cards. | DKIM checker confirms keys are published and well-formed. SPF flattener prevents PermError which silently breaks SPF auth. |
Req. 11.5 Monitoring | Network intrusions and unexpected file changes are detected and responded to. By extension - unexpected changes to outbound-mail authorization records (SPF includes added, DKIM rotated). | Wiredepth Pro continuous monitoring tracks DMARC / SPF / DKIM / MTA-STS posture and alerts on regressions. Per-domain change history. |
Req. 12.8 Inventory | Risk to information assets associated with service-provider relationships is managed. Maintained list of providers with descriptions of services provided. Email-sending vendors fall under this. | Vendor consolidation audit produces a one-page inventory + CSV export. Vendor-scoring tool batch-grades third parties for the same risk-management workflow. |
What auditors actually look at
What an experienced QSA actually looks at when reviewing the email / domain-posture portion of your PCI assessment:
- Current DMARC record + policy strictness. p=none with adkim/aspf=relaxed is increasingly read as "no real protection". p=quarantine or p=reject with strict alignment is the bar.
- Inventory of authorized senders.Your SPF record + DKIM selector list is itself the inventory for Req. 12.8. The QSA will ask "which of these actually send cardholder-touching mail".
- Evidence of testing (Req. 11). A dated scorecard PDF + the change history from continuous monitoring covers this without a paid external pen test.
- Anti-phishing controls deployed to personnel (Req. 5.4). The extension being installed in Gmail / Outlook is direct evidence - admin-pushed deployment records from your MDM are sufficient.
- Phish-reporting workflow.Req. 12.10 expects a clear "here's what to do when you see one" path. The Report-to-team button gives you a clickable, audited workflow.
Generate a PCI-tagged evidence pack (Wiredepth Prove)
Prove subscribers can generate a ZIP of all five workpapers + a PCI README in one click. Single domain, single click, ready to file in your audit binder. See pricing at /pricing#prove ($499/mo standalone, bundled in Enterprise).
Other compliance crosswalks
Disclaimer. This crosswalk is provided for informational purposes. It is not legal advice, audit guidance, or a substitute for engagement with a qualified assessor (QSA for PCI, accountant or QSA for SOC 2, lawyer for HIPAA / NIS2 / SEC). Framework clause ids and language may have been updated since publication; verify against the official text. Wiredepth does not guarantee compliance based on the use of any tool or page on this site.