DMARC at p=none

SPF authenticates the envelope sender, a technical address the recipient never sees. DKIM signs the message with a domain's key. Either can pass while the visible From: shows a completely different domain.

DMARC requires that a passing SPF or DKIM result belong to the same domain as the From: header. That is alignment, and it is what makes DMARC the mechanism that stops exact-domain spoofing.

So a message can pass SPF and still fail DMARC. This surprises people and it is the design working as intended.

Alignment can be relaxed — matching the organisational domain — or strict, matching exactly. Relaxed is the default and is right for most organisations, because subdomains are commonly used for sending.

`p=none`: take no action, send reports. A monitoring mode, and the state most domains stop in.

`p=quarantine`: treat failing mail as suspicious, typically delivering it to spam.

`p=reject`: refuse it outright. The end state, and the only one that prevents exact-domain spoofing.

`pct=` applies the policy to a percentage of messages, which is how a move to quarantine or reject is rolled out gradually rather than all at once.

`sp=` sets the policy for subdomains. Without it, subdomains inherit the organisational policy — which means a `p=reject` on the apex covers a subdomain nobody configured, for better and for worse.

Because moving forward requires knowing every system that sends in your name, and nobody does at the start.

The reports answer that, and they arrive as gzipped XML from dozens of providers daily — unreadable without processing, which is why they are so often published and then ignored.

The list they produce is always longer than expected: a CRM sending from a salesperson's address, an invoicing tool, a recruitment system, a survey platform, a support desk, a scheduling tool, a monitoring alert.

Each has to be brought into alignment or accepted as a loss before enforcement. That is real work, and it is the reason the last step is postponed indefinitely.

The cost of postponing it is precise: the domain remains spoofable, and the reports pile up unread.

Publish `p=none` with a `rua=` address and collect reports for several weeks. Send them to a mailbox with a processing tool, not to a person.

Work through every sender the reports name. Bring each into alignment — add it to SPF, or set up DKIM signing with your domain — or decide its mail can fail.

Move to `p=quarantine` with a low `pct=` and watch. A missed sender now appears as a small number of complaints rather than as every message failing.

Raise `pct=` in stages, then move to `p=reject` once the reports show only illegitimate mail failing.

Set `sp=reject` for subdomains that never send, which closes the most commonly forgotten spoofing route.

Rushing this rejects your own invoices. Staying at none protects nothing. The staged path is the whole answer.

`dig _dmarc.example.com TXT +short`. The record lives on the `_dmarc` subdomain, not the apex, which is a frequent reason people believe they published one when they did not.

Read `p=` first. Then check whether `rua=` is present, since a policy of none without reporting gains nothing at all.

Check `sp=`, and check the subdomains you actually send from.

For a specific message, the `Authentication-Results` header written by the receiving server reports the DMARC result and why — which is where an alignment failure is stated plainly.

`email.dmarc.present` and `email.dmarc.policy` read the record and report the policy in force, including when it is `none`.

`email.dmarc.alignment`, `email.dmarc.pct` and `email.dmarc.subdomain` report the alignment mode, the rollout percentage and the subdomain policy.

`email.dmarc.rua` and `email.dmarc.ruf` report the reporting addresses, which decide whether the monitoring the policy enables is actually reaching anyone.

`email.spoofing_exposure` combines the SPF, DKIM and DMARC state into the practical question the record exists to answer: whether this domain can be spoofed.