PCI DSS 4.0, cyber-insurance and email authentication

23 May 2026 · 12 min read

When compliance and insurance start asking about your email

For years, email authentication was a topic that lived quietly inside the mail team. SPF, DKIM and DMARC were configured (or not), and nobody outside IT asked about them. That has changed. Two very different forces now put your DNS records under scrutiny: the Payment Card Industry Data Security Standard, in its 4.0 revision, and the cyber-insurance questionnaire you fill in to renew your policy each year. Both have woken up to the fact that phishing is the cheapest, most reliable way an attacker gets into an organisation, and both have started treating anti-phishing controls as a measurable requirement rather than a nice-to-have.

If you process card payments, PCI DSS 4.0 brings an explicit anti-phishing obligation into scope. If you buy cyber-insurance, the proposal form almost certainly asks whether you have DMARC at enforcement. In both cases the honest, technical answer comes down to the same three protocols and the same DNS records. This article explains exactly where PCI DSS 4.0 and insurance expectations intersect with email authentication, what "good" looks like in evidence terms, and how to get there without knocking out your own legitimate mail.

If you want to see where your domain stands before reading on, run it through the free DMARC checker. It will show you the policy receivers see today, which is the single fact both an assessor and an underwriter will ask about first.

What PCI DSS 4.0 actually requires

PCI DSS is the standard that any organisation storing, processing or transmitting payment card data has to meet. Version 4.0 supersedes 3.2.1, and the dates matter: 4.0 became the only active version from April 2024, and a large block of its "future-dated" requirements became mandatory from 31 March 2025. Several of those future-dated items are precisely the ones that touch email.

The two requirements to understand are in Requirement 5 (protecting against malicious software) and Requirement 12 (the human side, policies and awareness).

• Requirement 5.4.1 is the new and important one. It states that processes and automated mechanisms must be in place to detect and protect personnel against phishing attacks. This is the first time PCI DSS has named phishing as a thing you must defend against with a technical control, not just train people to spot. The supporting guidance explicitly mentions anti-spoofing controls, and it names DMARC, SPF and DKIM as examples of the kind of mechanism that satisfies the intent.
• Requirement 12.6.3.1 sits on the awareness side and requires that security-awareness training covers threats including phishing and social engineering. This is the training half of the same coin.

The distinction matters because 5.4.1 is technical. You cannot satisfy it purely by sending staff on a phishing-awareness course. The standard wants an automated mechanism that reduces the chance a spoofed message reaches a person in the first place. For inbound mail that is your gateway filtering and your enforcement of inbound DMARC. For outbound, the protection of your own domain (so attackers cannot spoof your From: address to your staff, your customers and your suppliers) is delivered by SPF, DKIM and DMARC published on the domains you own.

A subtle point that trips people up: 5.4.1 is principally aimed at protecting your personnel from phishing. But you cannot meaningfully separate inbound protection from outbound posture. The most damaging phishing inside a card-handling business is internal-looking mail: a forged message that appears to come from your own finance director or your own payments provider. Publishing DMARC at enforcement on your sending domains is what stops your own domain being used as the lure. So the practical reading of 5.4.1 for most assessed entities is: deploy SPF and DKIM correctly, then move DMARC to p=quarantine or p=reject, and run a mail gateway that honours inbound DMARC.

Two further things are worth saying plainly. First, 5.4.1 applies to in-scope systems and the people who administer them, not necessarily to every domain your marketing team owns; but assessors increasingly expect anti-spoofing on any domain that could be used to phish staff. Second, PCI DSS does not mandate a specific p= value in the text. It asks for a mechanism that works. In practice, a QSA (Qualified Security Assessor) looking for evidence will treat p=none as monitoring, not protection, because a none policy instructs receivers to do nothing about forged mail. We explain that gap in detail in DMARC policy: none, quarantine or reject.

Why insurers ask the same question for different reasons

Cyber-insurance underwriters are not enforcing a standard. They are pricing risk with their own money on the line, and over the last few years they have learned, expensively, that business email compromise (BEC) and phishing-led ransomware are where the claims come from. So the proposal and renewal questionnaires have grown a section on email security, and DMARC appears on almost all of them.

The questions tend to look like this:

• Do you have SPF, DKIM and DMARC records configured for all your email domains?
• Is DMARC set to an enforcement policy (quarantine or reject)?
• Do you use email-filtering or a secure email gateway that performs anti-spoofing and anti-phishing checks?
• Do you have multi-factor authentication on email and remote access?

Here is the part that catches people out, and it is the most consequential sentence in this whole article: your answers on that form are warranties. If you tick "yes, DMARC is at enforcement on all domains" and a claim later arises from a spoofed-domain phishing attack, the insurer's forensics will check your historic DNS. If your domain was actually sitting on p=none, or had no DMARC record at all, you have made a material misstatement. Insurers have declined claims on exactly that basis. The classic, much-cited example is a multimillion-pound funds-transfer fraud claim that was contested after the insured had represented that MFA was in place when it was not; the same logic applies to any control you attest to on the form. An email-authentication question is not a box to optimise; it is a statement you must be able to prove was true on the day you signed.

That is good news, oddly, because it means there is a clean, verifiable answer. Unlike a fuzzy question about "security culture", DMARC posture is a fact written in public DNS. You can check it, fix it, and then answer the questionnaire truthfully, knowing the evidence backs you up.

The three records that do the work

Both PCI DSS 4.0 and the insurance forms reduce to the same underlying mechanism. It is worth being precise about what each of the three protocols proves, because assessors and forensic teams will look at all three, not just DMARC.

• SPF publishes, in DNS, the list of servers permitted to send mail using your domain in the envelope MAIL FROM. A receiver checks the connecting IP against that list. SPF on its own has a well-known weakness: it authenticates the envelope, not the visible From: header a human reads, and it breaks on forwarding. It also has a hard limit of ten DNS lookups, and exceeding it causes a permerror that quietly invalidates the record. Check yours with the SPF checker, and if it is over the limit read fixing SPF PermError and SPF flattening explained.
• DKIM attaches a cryptographic signature to each message, tied to a key published in your DNS. The receiver verifies the signature, which proves the signed parts of the message were not altered and genuinely originated from a holder of the private key. Verify your published keys with the DKIM checker.
• DMARC ties the other two to the visible From: domain through alignment, and adds a published policy telling receivers what to do when neither SPF nor DKIM aligns. This is the protocol that actually turns authentication into anti-spoofing, because alignment is what stops From: you@yourcompany.com passing on the strength of some unrelated domain. We cover the mechanism in DMARC alignment explained.

For compliance and insurance evidence, the headline metric is the DMARC policy. A record that reads

v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; fo=1

is what an underwriter wants to see and what a QSA will accept as an anti-spoofing mechanism. A record that reads p=none is monitoring only, and a missing record is nothing at all. But, and this is the part people get wrong in their rush to pass an audit, you cannot just flip to p=reject to satisfy a form. If your legitimate senders are not aligned first, you will start rejecting your own invoices, receipts and payment notifications. That is a self-inflicted outage, and for a card-handling business it can be worse than the spoofing risk you were trying to close.

How to get to enforcement without breaking mail

The order of operations matters more than the destination. Both PCI DSS and the insurer care that you reach enforcement; neither rewards you for getting there in a way that knocks out your own transactional mail. Here is the sequence that gets you to a defensible, evidenced enforcement posture safely.

1. Inventory every sending domain and source. List the domains that send mail (your primary domain, brand variants, regional domains) and the services that send on your behalf: your mail platform, CRM, invoicing tool, helpdesk, marketing platform, payment-provider notifications. Card-handling businesses almost always have more senders than they expect. The DMARC generator helps you produce a starting record per domain.
2. Publish DMARC at p=none with reporting. Add a rua= address so aggregate reports start flowing. This is the visibility stage. You are not protected yet, but you are now collecting the evidence you need to move safely.
3. Read the reports and align your senders. Aggregate reports tell you which sources pass SPF and DKIM with alignment and which fail. Work through the failures: add legitimate senders to SPF (watching the ten-lookup limit), enable DKIM signing on each platform, and fix alignment. Continuous monitoring makes this far less painful than parsing raw XML by hand; this is what continuous DMARC monitoring is for, and the DMARC report analyzer will decode a single report if you just want to inspect one.
4. Move to p=quarantine, optionally with pct. Once your legitimate sources are aligned, step up to quarantine. You can apply it to a fraction first with the percentage tag to contain the blast radius, as covered in DMARC pct and sampling.
5. Move to p=reject. When quarantine has run cleanly and your reports show no legitimate mail failing, go to full enforcement. This is the policy that satisfies the strictest reading of both the insurance form and PCI 5.4.1.
6. Set the subdomain policy and cover parked domains. Attackers love parked and subdomain spoofing. Use the sp= tag deliberately (subdomain policy explained), and publish a strict DMARC record even on domains that send no mail at all (DMARC for domains that do not send mail). An assessor who finds an unprotected parked domain that mimics your brand will flag it.

This is exactly the path the done-for-you DMARC product automates, and the supporting SPF, DKIM and MTA-STS services close the rest of the chain.

Evidence: what an assessor or underwriter will actually look at

Passing the requirement is one thing; proving it is another. Both audiences want artefacts, and the same set of artefacts serves both.

• Live DNS records. The DMARC, SPF and DKIM records as they resolve publicly. A QSA may dig them out themselves, and an insurer's forensic team certainly will after a claim. They are public, so there is nowhere to hide. Keep a dated record of what was published and when.
• The policy value over time. Because the insurance answer is a point-in-time warranty, the date your domain reached p=quarantine or p=reject is the date that matters. If you attest enforcement on a renewal form, the record must already say so on that date, not weeks later. A change log of your DNS, or monitoring history that timestamps the policy change, is the cleanest evidence.
• Aggregate report data. DMARC reports demonstrate that the mechanism is not just published but working: that mail is being evaluated and that failures are visible to you. This is strong evidence for PCI 5.4.1's "automated mechanisms" wording, because it shows an ongoing, monitored control rather than a static record nobody watches.
• Gateway / inbound configuration. For the inbound half of 5.4.1, evidence that your mail filtering honours DMARC and performs anti-phishing checks. That is a screenshot or configuration export from your gateway, not a DNS lookup.
• Change alerts. Evidence that you would notice if any of this regressed. A control that silently breaks (a DKIM key removed during a migration, a DMARC record overwritten) and is never noticed is a finding waiting to happen. Emailed change alerts and monitoring give you the audit trail that says the control is maintained, not just deployed once.

A practical tip: do not present a one-off screenshot taken the morning of the audit. Both audiences are now wise to records that appear days before an assessment and quietly revert afterwards. Continuous evidence (a monitoring history that shows the policy has been at enforcement for months and is actively watched) is far more persuasive, and it is the truthful position you want to be in anyway.

Common ways businesses fail this, and how to avoid them

A few patterns come up repeatedly when card-handling businesses and insured organisations get caught out.

• Ticking "yes" when the truth is p=none. The most dangerous mistake, because it converts a technical gap into a contractual one. If you are on p=none, the honest answer to "is DMARC at enforcement" is no. Fix the posture, then answer yes.
• Protecting only the main domain. Brand-variant domains, regional domains and parked domains are all spoofable. An attacker will pick the weakest one. Cover them all.
• An SPF record that silently permerrors. Over the ten-lookup limit, SPF stops authenticating, which can pull mail into DMARC failure and undermine the very enforcement you published. This is invisible unless you check. See the SPF ten-lookup limit.
• Rushing to p=reject to pass an audit, then rolling back after an outage. A policy you cannot keep is worse than honest monitoring, and a record that flip-flops looks bad in a change log. Align senders first; the enforcement then sticks.
• Treating it as a one-time project. Senders change, platforms get added, keys get rotated. Without monitoring, your evidenced control decays. PCI DSS 4.0's framing of "processes and automated mechanisms" is deliberately ongoing.

If you want to confirm the full chain in a few minutes, run your domain through the free tools: DMARC, SPF and DKIM checkers, plus the MTA-STS checker for transport security, which increasingly appears on the more detailed insurance forms. The requirements overview maps the major mailbox-provider and compliance expectations in one place, and the glossary defines any term here you want to nail down.

The practical takeaway

PCI DSS 4.0 and your cyber-insurance questionnaire have arrived at the same conclusion from opposite directions: spoofable email is an unacceptable risk, and the fix is SPF, DKIM and DMARC deployed properly with DMARC at enforcement. The compliance side wants an automated, maintained anti-phishing mechanism; the insurance side wants a truthful, provable warranty. Both are satisfied by the same work, and both reward you for doing it honestly rather than for the morning of an assessment.

The order is what keeps you safe: inventory your senders, publish DMARC with reporting, align every legitimate source, then step up through quarantine to p=reject, and keep watching it. Start by checking where you stand with the DMARC checker. If you would rather not parse aggregate reports and ramp policies by hand, the done-for-you DMARC service takes a domain from p=none to p=reject with no email outage and leaves you with exactly the monitored, dated evidence a QSA or an underwriter wants to see.