Failed compliance

For years, email authentication lived with the deliverability team. It was a thing you tuned to keep mail out of spam folders. That has changed. DMARC now turns up in audit scopes, in cyber-insurance applications, and in the security questionnaires that decide whether a buyer will sign with you. Reviewers are no longer satisfied that a record exists. They check what the policy actually says, and a domain stuck at p=none increasingly counts as a fail.

This article covers where email authentication shows up in compliance and procurement, why publishing a record is not the same as enforcing one, what assessors and insurers genuinely look for, the cost of getting it wrong, and how to assemble evidence that satisfies them.

Where email authentication now shows up

A few years ago, DMARC was a deliverability detail. Now it appears in four places that can directly affect revenue and cost.

PCI DSS 4.0, requirement 5.4.1

The Payment Card Industry Data Security Standard version 4.0 introduced requirement 5.4.1, which states that processes and automated mechanisms must be in place to detect and protect personnel against phishing attacks. It was a future-dated requirement that became mandatory on 31 March 2025. DMARC is the recognised technical control for the anti-spoofing side of this: it stops attackers from sending mail that appears to come from your own domain. If your organisation falls in scope for PCI DSS, an assessor will ask how 5.4.1 is met, and an enforced DMARC policy is the cleanest answer.

Cyber-insurance questionnaires

Cyber-insurance underwriters price risk from a questionnaire, and email security questions have moved up the list. Application forms now routinely ask whether DMARC is deployed and, more pointedly, whether it is set to enforcement. A blank or a half-answer can raise your premium, narrow your cover, or in a hardening market lead to a declined application. Insurers know that business email compromise and invoice fraud are among the most expensive claims they pay, and domain spoofing is a common first step.

Enterprise vendor security reviews and supplier onboarding

If you sell to large organisations, their security team will review you before a contract is signed and often again at renewal. Standard questionnaires such as the SIG or a CAIQ ask about email authentication. Some buyers go further and check your domain directly: they query your DNS, read your published DMARC policy, and note whether it says p=none or p=reject. A weak posture can stall onboarding or push your contract into an exceptions process that takes weeks.

Government and sector frameworks

Public-sector and regulated-sector frameworks increasingly expect anti-spoofing controls. The UK government has mandated DMARC on central government domains for years, and similar expectations have spread through guidance such as Cyber Essentials adjacent advice and sector codes of practice. If you supply into these environments, your own domain posture becomes part of the assessment.

Publishing a record is not enforcement

This is the single most common reason a domain fails a review while its owner believes everything is fine. A DMARC record has a policy tag, p=, with three possible values:

• p=none: monitoring only. Failing mail is still delivered. You receive reports, but nothing is blocked.
• p=quarantine: failing mail is sent to the spam or junk folder.
• p=reject: failing mail is refused outright, so a spoofed message never reaches the inbox.

Most domains that publish DMARC are stuck at p=none. They watch but never block. From a deliverability point of view that is a reasonable starting position. From a compliance point of view it is the equivalent of installing a smoke alarm and disconnecting the battery. The control exists on paper and does nothing in practice.

Reviewers have caught on. An insurer who asks "is DMARC enforced?" is asking specifically because they know p=none is the default trap. A buyer who reads your record knows the difference between a policy that quarantines and one that only reports. The presence of a record buys you nothing if the policy is permissive.

What assessors and insurers actually look for

Across PCI assessors, underwriters and procurement teams, the expectations converge on a short list. They want to see a control that is real, complete and demonstrable.

An enforced policy

The policy must be at p=quarantine or p=reject, applied to the whole domain rather than a token percentage. A record carrying p=reject; pct=10 only enforces on a tenth of mail and is treated as incomplete. The strong answer is a full p=reject with no percentage hedge.

Aligned SPF and DKIM

DMARC works by checking alignment. SPF or DKIM must pass, and the domain it validates must match the visible From domain. A message can pass SPF for some unrelated bounce domain and still fail DMARC because nothing aligns with what the recipient sees. Assessors who understand the standard will look for both SPF and DKIM in place and aligned, not just one. DKIM matters most because it survives forwarding, where SPF breaks.

Evidence of monitoring

An enforced policy with no oversight worries a careful reviewer, because it suggests you might be blocking legitimate mail by accident. They want to see that you collect and read aggregate reports, the rua= feed, so you know which sources send on your behalf and can prove the policy is not causing collateral damage. Monitoring reports double as your audit evidence.

The checklist a reviewer expects to see

If you want to know whether your domain will pass before someone else checks, run through this list. It mirrors what an underwriter or supplier-security analyst works from.

One detail that catches people: the SPF 10-lookup limit. RFC 7208 caps SPF evaluation at ten DNS lookups. An SPF record that chains several include: mechanisms can quietly cross that line and return permerror, at which point SPF fails and your alignment leans entirely on DKIM. Flattening, which resolves those includes down to plain IP ranges, keeps you under the limit. A reviewer who tests your SPF and sees a permerror will flag it.

The business cost of failing

The reason this matters is not abstract. Failing these checks costs money and time in concrete ways.

Lost or delayed deals

When a procurement review flags your email posture, the deal does not always die, but it slows. Your sales team waits on an exceptions process. The buyer's security team asks for a remediation plan and a date. Every week of delay is a week the contract is not signed, and some buyers simply move on to a supplier whose domain already passes.

Higher premiums or refused cover

On the insurance side, a weak answer pushes your premium up or limits the cover available. In a tighter market, underwriters have declined applications outright where basic email controls were missing. Given that domain spoofing feeds directly into the business email compromise claims insurers most dislike, this is a deliberate filter, not an oversight.

Blocked or stalled supplier onboarding

Some large buyers will not complete onboarding until specific controls are confirmed. A p=none domain can leave you sitting in a holding state, unable to invoice or begin work, while you scramble to enforce a policy you could have fixed months earlier.

How to demonstrate compliance

Demonstrating compliance is straightforward once the policy is enforced. You need two things: an enforced policy, and evidence that you operate it responsibly.

Get to an enforced policy safely

You do not jump from p=none straight to p=reject on day one. The safe path is to start at p=none to discover every legitimate sending source, fix SPF and DKIM for each one until they align, move to p=quarantine to confirm nothing breaks, then move to p=reject. Done with care, this is a managed transition that does not interrupt legitimate mail. Our guide to moving to enforcement walks through each step.

Keep monitoring as your evidence

Once enforced, the aggregate reports become your audit trail. They show which sources send for your domain, confirm that legitimate mail still passes, and record that spoofed mail is being blocked. When an assessor or underwriter asks for evidence, you hand over a short summary backed by report data rather than a verbal assurance. That is the difference between "we have DMARC" and "here is our enforced policy and the monitoring that proves it works".

Package the answer once

Most organisations face the same questions repeatedly across insurance renewals, vendor reviews and audits. Write the answer once: your DMARC policy value, your aligned SPF and DKIM setup, your reporting address, and a one-paragraph note on how you monitor. Keep it current and reuse it. The requirements overview sets out the controls that buyers and standards expect, so you can map your evidence to each one.

A note on getting it done

If you would rather not run the enforcement project in-house, it can be done for you. Enforcement is a one-time fee of £200 as an introductory offer (normally £500), which covers the work of taking a domain from monitoring to a clean p=reject. Ongoing monitoring, which produces the evidence reviewers want, is £19 per month introductory (normally £39). Either way, the goal is the same: a policy that actually blocks spoofing and a record of it you can show. You can create an account to begin.

The shift is simple to state. Email authentication used to be judged on whether mail reached the inbox. It is now judged on whether your domain can be impersonated, and the people asking the question are auditors, insurers and the buyers who hold your next contract. A record at p=none answers the old question and fails the new one. Move to an enforced policy, keep the reports that prove it works, and the compliance answer takes care of itself.