Tessera
PCI DSS reference

PCI DSS 5.4.1: anti-phishing controls and your sending domain

The technical half of 5.4.1 is stopping people from sending mail as you. What SPF, DKIM and DMARC have to look like before that claim holds.

Standard: PCI DSS v4.0.1 requirement 5.4.1. This is a plain-language reference, not legal advice, and it does not determine your PCI DSS compliance or which questionnaire applies to you. Your acquiring bank sets your reporting obligations.

The short checklist

  1. Publish one SPF record that lists your real senders and ends in a fail directive.
  2. Sign with DKIM at every service that sends as your domain.
  3. Publish DMARC, read the reports, then enforce — in that order.
  4. Check that subdomains are not exempted by an sp= tag.

Why email authentication is the technical half

5.4.1 calls for processes and automated mechanisms to detect and protect personnel against phishing attacks. Training is the human half. The technical half is anti-spoofing of your own domain, because the phishing mail that works best is the one that appears to come from you.

Monitor-only DMARC is not protection

p=none tells receivers to report failures and deliver them anyway. It is the right first step and the wrong resting place: under a control described as protecting personnel, a policy that observes spoofing and lets it through is a gap. Move to quarantine and then reject once the aggregate reports show your legitimate senders passing.

  • Does the SPF record stay within the 10 DNS-lookup limit once includes are resolved?
  • Is there exactly one SPF record? Two is a permanent error and SPF stops working.
  • Does DMARC have a rua= address someone actually reads?
  • Does sp=none quietly exempt every subdomain from an otherwise strict policy?

Change DNS in the safe order

Publishing an enforcing policy before the reports are clean drops real mail — invoices, password resets, receipts. Inventory the services that send as you first. That inventory is usually longer than anyone expects.

Primary source

Read the source rather than a summary of it, including this one: PCI DSS v4.0.1, requirement 5.4.1 — https://www.pcisecuritystandards.org/document_library/?class=pcidss&doc=pci_dss.

What the free check can and cannot tell you

The free check reads the HTML your server returns. It inventories script elements and observed integrity attributes, but it does not inspect HTTP response headers or fetch remote script bytes. Live 11.6.1 monitoring separately fingerprints selected response headers and referenced script contents. The free check does not run the page in a browser, and neither does live monitoring. A script injected at runtime by another script is outside what Tessera can see, and no static check can tell you whether a script is authorized — only you know that.

Reviewed August 2026. The standard and the questionnaires change; confirm against the current text before relying on anything here.

Check your domain's published SPF, DKIM and DMARC

Preview the synthetic 5.4.1 remediation pack before deciding whether the paid artifact fits your review.

Related