TesseraEvidence follows evidence
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 course

Each item carries the observed fact downstream through risk, fix, and closure evidence.

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 apply no special handling, so it is not an anti-phishing protection policy. Read aggregate reports for a representative period, fix legitimate alignment failures, then step to p=quarantine. Treat p=reject as a separate risk decision: RFC 9989 warns general-purpose domains about mailing-list interoperability and requires aligned DKIM rather than reliance on SPF alone.

Validation

Use aggregate reports to confirm legitimate sources align, then verify the deployed policy has progressed to the reviewed quarantine setting. If reject is selected, retain the aligned-DKIM and indirect-mail impact review that justified it.

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. 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 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.