Important: Email authentication changes can interrupt legitimate mail when applied without a complete sender inventory. Keep a record of the previous configuration and involve the person responsible for your DNS and email services.
What DMARC does
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It gives a domain owner a published policy describing how receiving systems should handle messages that do not pass aligned SPF or DKIM checks. It can also request reports about messages claiming to use the domain.
DMARC does not scan a message for every type of fraud, and publishing a record does not automatically guarantee inbox placement. Its main job is to connect authentication results to the visible domain in the From address.
Why alignment matters
SPF can confirm that a sending system is authorised, while DKIM can confirm that a message carries a valid cryptographic signature. DMARC then checks whether at least one passing method aligns with the domain that the recipient sees.
- SPF alignment compares the authenticated envelope domain with the visible From domain.
- DKIM alignment compares the signing domain in the DKIM signature with the visible From domain.
- DMARC can pass when either aligned SPF or aligned DKIM passes.
Alignment can be relaxed or strict. Relaxed alignment can allow an exact domain or a related organisational-domain match, while strict alignment requires an exact domain match. The DMARC tags aspf and adkim select the SPF and DKIM alignment modes.
This distinction explains why a service can show a technically passing SPF result but still fail DMARC. The domains may not align.
The three commonly used policies
| Policy | What it requests | Typical purpose |
|---|---|---|
p=none | Monitor without requesting quarantine or rejection. | Discovery and reporting during a controlled rollout. |
p=quarantine | Ask receivers to treat failing mail suspiciously. | A measured enforcement stage after legitimate senders are understood. |
p=reject | Ask receivers to reject failing mail. | Strong enforcement once legitimate traffic is correctly authenticated. |
Receiving providers retain control over their own handling decisions. A published policy is a request, not an absolute command to every provider.
What aggregate reports can reveal
Aggregate reports can show which sending sources are using your domain and how SPF, DKIM and alignment performed. They are useful for finding forgotten marketing platforms, support systems, invoicing tools and unauthorised senders.
The reports are machine-readable XML and may be numerous. A monitoring service can group sources and highlight changes, but the underlying questions remain the same: Is this sender legitimate, is it correctly authenticated and does it align?
Reports are requested through the rua tag. Reporting depends on receiver participation, and a reporting address at another organisational domain may require additional DNS authorisation before reports are sent.
A safer rollout sequence
- Confirm who controls DNS and where records are managed.
- Inventory every system that sends using the domain.
- Check existing SPF and DKIM configuration.
- Publish a monitoring policy with a reporting destination you control.
- Review reports across normal business cycles.
- Correct or remove unrecognised sending paths.
- Move towards enforcement in controlled stages.
- Keep monitoring after enforcement.
DMARC is a process, not a single switch
The most valuable outcome is not merely having a record. It is having a maintained inventory, aligned legitimate senders and enough reporting to spot change.
Further reading
For operational guidance, consult the current DMARC specification, its aggregate reporting specification, your email provider's documentation and the UK National Cyber Security Centre's guidance on protecting parked domains.