Why do compliance frameworks care about SPF, DKIM, and DMARC?

Because email is a transmission channel, and unauthenticated email is a spoofing vector aimed at your customers and staff. In our mapping, all three checks satisfy SOC 2 CC6.7 (secure transmission of information); DMARC also carries ISO 27001 A.5.14 and DKIM carries A.8.24. Frameworks treat email authentication as a boundary control, not a marketing setting.

Is p=none enough to satisfy an auditor?

No. A DMARC record at p=none publishes a policy that rejects nothing — it only collects reports. An auditor or vendor reviewer reading for enforcement will mark it as not operating. The control is satisfied at p=quarantine or p=reject with SPF or DKIM aligned; p=none is monitoring, not protection.

What evidence do I attach for email authentication?

The actual records (SPF with -all, a published DKIM selector, DMARC at enforcement), a date, and the control each satisfies. The strongest form is a signed, timestamped report that a reviewer can verify against a public key — stronger than a screenshot, which carries no verifiable date.

Does DMARC enforcement break my legitimate email?

Only if you jump to p=reject before aligning your senders. Roll out p=none to read reports, add forgotten senders to SPF or sign them with DKIM, then ramp to p=quarantine and p=reject. For compliance you want to land at enforcement — but you get there by aligning first, not by flipping the policy blind.

← blog

SPF, DKIM, and DMARC for compliance (not deliverability): the evidence auditors accept

2026-08-03 · By Arshad Ansari · spf · dkim · dmarc · compliance · evidence

spfdkimdmarccomplianceevidence

Almost everything written about SPF, DKIM, and DMARC frames them as deliverability tools: publish them so Gmail stops sending your newsletters to spam. That framing is true, but it is the wrong lens when a SOC 2 auditor or a vendor security reviewer asks about them. To them, email authentication is not about inbox placement — it is a transmission control, and they read your records as evidence that mail claiming to be from your domain can be authenticated and forged mail rejected.

This post reframes the three records as audit evidence: the control each one satisfies, what "operating" looks like to a reviewer, and how to prove it in a form that survives scrutiny.

Deliverability asks "will it arrive?" Compliance asks "can it be forged?"

The deliverability question is about your own outbound mail reaching inboxes. The compliance question is the inverse: can someone else send mail as you? A domain with no SPF and no DMARC is trivially spoofable — an attacker forges your From: address to phish your customers, and nothing stops them. That is why frameworks classify these records as security controls.

In our scan of 994 top domains, 83.4% publish a DMARC record but only 69.1% actually enforce it, and 14.3% sit at p=none — a record that passes a naive checkbox but rejects nothing. That gap is exactly what a competent reviewer probes: existence is not enforcement, and a compliance answer that says "yes, we have DMARC" while publishing p=none unravels the moment someone looks at the record.

The controls each record satisfies

Here is the mapping a reviewer applies, using the real control ids from the dossier's check library:

| Record | SOC 2 | ISO 27001:2022 | NIST 800-53 | "Operating" means | |--------|-------|----------------|-------------|-------------------| | SPF | CC6.7 | A.8.20 | SC-8 | Published with -all hardfail | | DKIM | CC6.7 | A.8.24 | SC-8 | A selector published, key ≥1024 bits | | DMARC | CC6.7 | A.5.14 | SC-8 | p=quarantine or p=reject, aligned |

All three land on SOC 2 CC6.7 — secure transmission of information — because together they are what makes your email channel authenticatable. DMARC additionally carries ISO 27001 A.5.14 (information transfer) and DKIM carries A.8.24 (use of cryptography). One misconfigured record and the whole channel is evidence of a gap, not a control.

What "operating" looks like, record by record

SPF. The reviewer wants -all (hardfail) at the end, not ~all (softfail). A soft fail logs violations but instructs receivers to accept the mail anyway, so it blocks nothing. It also wants the record inside the 10-lookup limit — an SPF record that exceeds it returns permerror and is ignored. Verify both with an SPF record check.

DKIM. The reviewer wants at least one published selector with an adequate key length. A rotated-away or missing selector breaks DMARC alignment and downgrades receiver trust. Confirm the selector resolves and the key is strong with a DKIM lookup.

DMARC. This is where most "yes" answers fail. The reviewer wants p=quarantine or p=reject with SPF or DKIM aligned to your From: domain. p=none is monitoring only; it is not the enforced control the criterion asks for. Check the policy and alignment with a DMARC check.

The through-line: for every record, the reviewer distinguishes present from enforcing. Deliverability tuning often stops at "present and passing." Compliance requires "enforcing," and the two-word difference — ~all vs -all, p=none vs p=reject — is the entire answer.

Turning the records into evidence

Knowing your records are correct is not the same as proving it to someone who does not trust your word. The proof needs three properties: it shows the actual record, it is dated, and it ties to the control. A pasted string has the first, a screenshot fakes the second, and neither ties to a framework.

The signed Domain Audit Report supplies all three. It runs SPF, DKIM, and DMARC (alongside the other 12 checks), renders the result as a PDF plus JSON sidecar, signs it with Ed25519, timestamps it in ISO-8601, and stamps each finding with its SOC 2 / ISO 27001 / NIST control. A reviewer verifies the signature against a published public key — no trust in your word required. It costs $29, arrives in 10–30 minutes, and carries a signed-or-refunded guarantee: if it doesn't verify or isn't accepted where you needed it, reply within 30 days for a full refund and keep the report.

That is the difference between "we have DMARC" and evidence that stands up: one is an assertion, the other is a dated artifact a third party can check.

Land at enforcement, then prove it

For deliverability you can get away with a half-configured stack. For compliance you cannot — a reviewer reads p=none as an open door. Align your senders, ramp DMARC to enforcement, tighten SPF to -all, and keep a dated, signed record of the state you attest to. Then the email-authentication question stops being a liability and becomes one of the easiest sections to answer.

Run the free 15-check dossier on your domain →

Want the dated, signed version to attach to an audit or questionnaire? The $29 Domain Audit Report delivers it, signed or refunded.

Frequently asked questions

Why do compliance frameworks care about SPF, DKIM, and DMARC?: Because email is a transmission channel, and unauthenticated email is a spoofing vector aimed at your customers and staff. In our mapping, all three checks satisfy SOC 2 CC6.7 (secure transmission of information); DMARC also carries ISO 27001 A.5.14 and DKIM carries A.8.24. Frameworks treat email authentication as a boundary control, not a marketing setting.
Is p=none enough to satisfy an auditor?: No. A DMARC record at p=none publishes a policy that rejects nothing — it only collects reports. An auditor or vendor reviewer reading for enforcement will mark it as not operating. The control is satisfied at p=quarantine or p=reject with SPF or DKIM aligned; p=none is monitoring, not protection.
What evidence do I attach for email authentication?: The actual records (SPF with -all, a published DKIM selector, DMARC at enforcement), a date, and the control each satisfies. The strongest form is a signed, timestamped report that a reviewer can verify against a public key — stronger than a screenshot, which carries no verifiable date.
Does DMARC enforcement break my legitimate email?: Only if you jump to p=reject before aligning your senders. Roll out p=none to read reports, add forgotten senders to SPF or sign them with DKIM, then ramp to p=quarantine and p=reject. For compliance you want to land at enforcement — but you get there by aligning first, not by flipping the policy blind.