Compliance Guide

PCI DSS Email Security Requirements

Payment Card Industry Data Security Standard

PCI DSS version 4.0 establishes requirements for protecting cardholder data, including when transmitted via email or web applications. Requirement 4 mandates strong cryptography for transmitting cardholder data over open networks, requiring TLS 1.2 as a minimum. Requirement 6 addresses secure development practices including security headers. While PCI DSS does not have explicit requirements for SPF, DKIM, or DMARC, email authentication is essential for protecting against phishing attacks that target cardholder data (Requirement 5) and supports the security awareness requirements under Requirement 12.

Protocol Requirements

ProtocolRequirementDetails
SPFRecommendedSPF is not explicitly required by PCI DSS, but it supports Requirement 5 (protecting systems and networks from malicious software) by reducing the effectiveness of phishing attacks that could lead to cardholder data compromise.
DMARCRecommendedDMARC enforcement helps meet Requirement 5.4.1 (PCI DSS 4.0), which requires mechanisms to detect and protect personnel against phishing attacks. DMARC prevents attackers from spoofing your domain in phishing campaigns targeting employees with access to cardholder data.
DKIMRecommendedDKIM ensures email integrity and supports Requirement 5's anti-phishing controls. For organisations that send payment-related emails (receipts, statements), DKIM helps recipients verify message authenticity.
SSL/TLSRequiredRequirement 4.2.1 (PCI DSS 4.0) requires strong cryptography with TLS 1.2 or higher for transmitting cardholder data over open networks. TLS 1.0 and 1.1 are explicitly prohibited. This applies to all channels including email, web, and APIs.
Security HeadersRequiredRequirement 6.4.1 (PCI DSS 4.0) requires that public-facing web applications are protected against attacks, which includes implementing security headers. Requirement 6.4.2 specifically requires an automated technical solution for web-based attacks (CSP supports this).
DNSSECOptionalDNSSEC is not required by PCI DSS but provides additional protection against DNS-based attacks that could redirect users from legitimate payment pages to attacker-controlled sites.

Compliance Implementation Steps

1

Enforce TLS 1.2+ on all transmission channels

Audit all endpoints that handle cardholder data and ensure TLS 1.2 or higher is enforced. Disable TLS 1.0, TLS 1.1, and all SSL versions. This is a hard requirement under PCI DSS 4.0 Requirement 4.2.1 with no exceptions.

2

Implement security headers on payment pages

Deploy Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, HSTS, and Permissions-Policy on all pages that handle cardholder data. CSP is particularly important for meeting Requirement 6.4.2's client-side security monitoring.

3

Deploy email authentication to combat phishing

Implement SPF, DKIM, and DMARC to prevent domain spoofing that targets employees or customers with access to cardholder data environments. This supports Requirement 5.4.1's anti-phishing controls.

4

Document email security in your information security policy

Include email authentication controls in the information security policy required by Requirement 12. Document which email authentication protocols are implemented, the DMARC policy level, and the review schedule.

5

Run vulnerability scans including domain security

PCI DSS requires regular vulnerability assessments (Requirement 11). Include domain security scanning as part of your assessment program to verify TLS configuration, security headers, and email authentication remain properly configured.

6

Monitor for email-based threats and configuration changes

Set up monitoring for changes to DNS records (SPF, DKIM, DMARC) and TLS certificates. This supports Requirement 10 (logging and monitoring) and Requirement 11.5 (change detection mechanisms).

Audit Evidence

Use Domain Security Scanner reports as evidence for your PCI DSS audit. Pro and Agency plans include PDF export for compliance documentation.

  • TLS scan reports verifying TLS 1.2+ enforcement and absence of weak protocols on all cardholder data channels
  • Security header audit reports showing CSP, HSTS, and other required headers on payment-related pages
  • Email authentication scan reports (SPF, DKIM, DMARC) demonstrating anti-phishing controls for Requirement 5.4.1
  • Monitoring history showing ongoing oversight of TLS certificates and DNS security configurations

Check Your PCI DSS Compliance

Run a free scan to see how your domain's email authentication measures up against PCI DSS requirements.

Frequently Asked Questions

Does PCI DSS require DMARC?

PCI DSS does not explicitly require DMARC, but version 4.0 introduced Requirement 5.4.1, which mandates mechanisms to detect and protect against phishing attacks. DMARC is one of the most effective tools for this purpose. QSAs (Qualified Security Assessors) increasingly expect to see DMARC as part of an organization's anti-phishing controls, particularly for domains used in customer communications.

What TLS version does PCI DSS 4.0 require?

PCI DSS 4.0 Requirement 4.2.1 requires TLS 1.2 or higher for all transmissions of cardholder data over open, public networks. TLS 1.0 and TLS 1.1 are explicitly prohibited and must be disabled. This applies to web traffic, email, APIs, and any other channel that transmits cardholder data. There are no exceptions or compensating controls that allow lower TLS versions.

Are security headers required under PCI DSS?

Yes. PCI DSS 4.0 Requirement 6.4.1 requires protection of public-facing web applications against attacks, and Requirement 6.4.2 requires an automated technical solution to continuously detect and prevent web-based attacks. Content-Security-Policy headers directly support this requirement. HSTS, X-Frame-Options, and X-Content-Type-Options are also expected as part of a secure configuration baseline.

Other Compliance Frameworks