DMARC
Also known as: Domain-based Message Authentication, Reporting and Conformance
DMARC tells recipients what to do with email that fails the SPF and DKIM checks — and reports back who is sending in the domain's name.
DMARC builds on SPF and DKIM and adds the two things they lack: an instruction to the recipient and feedback to the domain owner. A DNS record states whether failing messages should be delivered normally (`p=none`), moved to spam (`p=quarantine`) or rejected (`p=reject`). DMARC additionally requires the checked domain to match the visible sender address — the point at which forgeries become apparent.
The reports are the most valuable part in practice: receiving providers report back which servers sent mail using your domain and whether those messages passed the checks. That reveals which of your own systems are still misconfigured — and whether someone else is using the domain for phishing.
The typical mistake is to leave it at `p=none`. That level is meant as an observation phase, not a permanent state: it prevents not a single forged message. The path leads from evaluating the reports to `quarantine` and finally `reject` — while switching to enforcement too early makes legitimate mail from systems that are not yet set up correctly disappear.
What it means in practice
Forged invoices in a company's name are the case DMARC guards against — and most SME domains sit at `p=none` or have no record at all. NDVDL evaluates the reports, fixes the sending systems one by one and only then moves the policy to enforcement.
Is this handled properly at your site?
We look at how it actually stands with you — and say honestly whether anything needs doing.
Related terms
All termsA term from your quote missing here?
Send us the passage you do not follow. We will explain it — with no obligation to order anything.