Tessera
Synthetic sample

PCI 4.0.1 requirement 5.4.1 email anti-phishing remediation

Synthetic example: anti-phishing policy is monitoring-only and the exact DKIM selector still needs provider confirmation.

Synthetic sample — every target, observation, and record on this page is invented and uses reserved example domains. It contains no customer data, is not evidence of a real evaluation, and is not a certification or compliance determination.
Run the matching free email-authentication check
$99 one-time pack, offered only after an actionable resultOne written SPF, DKIM, and DMARC remediation pack for the submitted domain. Eligible orders are automatically refunded if no complete initial delivery arrives within 48 hours.
Standard
Email authentication evidence — PCI DSS v4.0.1 requirement 5.4.1
Target
merchant.example
Actionable items
2

Observed inventory

Facts carried by the canonical artifact, before remediation judgment.

  • merchant.example
    Kind
    SPF
    Observation
    v=spf1 include:mail.vendor.example -all (synthetic)
  • _dmarc.merchant.example
    Kind
    DMARC
    Observation
    v=DMARC1; p=none; rua=mailto:reports@merchant.example (synthetic)

Remediation plan

Each item preserves the observed fact, explains the risk, and names a closure test.

1. DMARC_NOT_ENFORCED

high

Observation

v=DMARC1; p=none; rua=mailto:reports@merchant.example

Risk

The synthetic DMARC policy is p=none, so it requests reports but does not ask receivers to quarantine or reject failing mail.

Fix

Move off p=none. Monitor-only tells receivers to report spoofed mail and then deliver it, so it does not protect anyone against phishing. Read the aggregate reports until every legitimate sender passes with alignment, then step to p=quarantine, then p=reject. Do not skip the reading step — that is what makes the change safe, and it is also the evidence a reviewer will ask for.

Validation

Use aggregate reports to confirm legitimate sources align, then verify the deployed policy has progressed to the reviewed quarantine or reject setting at 100 percent.

2. DKIM_MISSING

medium

Observation

Checked selector1._domainkey.merchant.example and selector2._domainkey.merchant.example (synthetic observation)

Risk

No valid DKIM record was found among the explicitly listed synthetic selectors. The sending provider must confirm the real selector.

Fix

Confirm the correct selector with each mail provider before changing DNS — the selector is provider-specific and a wrong guess publishes a dead record. Enable DKIM signing at every sending service and publish each provider's public key at the selector it specifies. DKIM is the only authentication that survives forwarding, so without it forwarded mail fails DMARC.

Validation

Send a test message through every authorized provider, read its DKIM-Signature selector, query that exact selector, and retain an Authentication-Results header showing dkim=pass.

Use this in qualified review

  1. Retain the canonical JSON. Download it and keep it unchanged as the machine-readable artifact; this synthetic file shows the paid format but is not customer evidence.
  2. Attach the review view. Print or save this view and attach it, together with the JSON, to the applicable change record.
  3. Collect validation evidence. Complete the Validation step listed for every item and retain the records it names before a qualified reviewer decides whether to close that item.

Scope and reliance

This is software-generated remediation guidance for qualified human review. It does not determine PCI DSS compliance, replace a Qualified Security Assessor, or certify that an implementation is secure. Validate every change in a safe environment before deploying it.

The downloaded JSON is the stable, machine-readable artifact used by this presentation. Save it with your change record.