p=none is not a policy: eleven days of spoofed invoices

Composite story. The mechanism, unfortunately, is not hypothetical.

A small distributor has a DMARC record. It has had one for three years. It reads `v=DMARC1; p=none; rua=mailto:dmarc@…` and it was published by an agency that set it up to 'start collecting data' and never came back to finish the job.

What p=none actually instructs

It instructs receivers to do nothing. Mail that fails alignment is delivered, and a report may be sent to the address in rua. Enforcement is the entire point of DMARC; p=none is the observation mode you use before you turn it on. Left in place, it is a monitoring configuration that produces a comfortable dashboard and zero protection.

This is the single most common finding in the domains we scan, and it is not a misconfiguration — it is an unfinished migration. Somebody did the hard part, collected the reports, and the last step never happened.

Eleven days

A supplier invoices by email. A spoofed message arrives from the distributor's exact domain — SPF passes because the record ends in `~all` and the sending IP is not listed, DKIM has no key for the provider in use, and DMARC says p=none. The message lands in the inbox with the correct display name, an attached PDF with changed bank details, and a reply-to on a lookalike domain.

It takes eleven days to surface. The first signal is a phone call about a payment that never arrived. By then the reports in rua would have shown the forged source — if anyone had been reading them, which is exactly what p=none assumes.

The migration that was never finished

1. Read the aggregate reports for two to four weeks. Every legitimate sender should show as passing SPF or DKIM alignment.
2. Publish p=quarantine with pct=25. Watch for a week: legitimate mail that fails alignment shows up as a support ticket, and 25% limits the blast radius.
3. Raise pct to 50, then 100.
4. Move to p=reject. This is the state that actually stops spoofing.

SPF and DKIM are not optional extras

DMARC alignment is computed against SPF and DKIM. A domain can have a perfect DMARC record and still fail alignment on every message if neither authentication mechanism passes for its real senders. That is why the checks belong together: SPF tells receivers which hosts may send, DKIM signs the message so forwarding does not break it, DMARC tells them what to do when neither lines up.

The shortest version of the advice

If your record says p=none, it is not protecting you, and the fix is not a rewrite — it is finishing a migration you already started. Take the reports you have been collecting, confirm your senders, and walk the pct ladder. Two weeks of attention, and the domain stops being usable as a forgery.