If an attacker can send an email that looks like it came from your domain, they can impersonate your finance team, your CEO, or your brand, and your customers have no easy way to tell. DMARC is the standard that stops this. This guide explains what it is, why it matters for smaller organisations, and how to roll it out safely.
What is DMARC?
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a published policy that tells receiving mail servers what to do with an email that claims to be from your domain but fails authentication. It builds on two older standards:
- SPF lists the servers allowed to send mail for your domain.
- DKIM adds a cryptographic signature that proves a message was not tampered with and genuinely came from your domain.
DMARC ties them together and, crucially, lets you say: "If a message fails these checks, reject it, and send me a report."
Why small organisations are targeted
There is a myth that spoofing only happens to big brands. In practice, smaller organisations are attractive precisely because they often have no DMARC policy, so their domain can be spoofed freely. Attackers use this for invoice fraud, CEO fraud, and phishing that trades on your reputation with your own customers and suppliers.
Without DMARC, "reject", anyone in the world can send email as you@yourdomain and most inboxes will deliver it.
The three DMARC policies
Your DMARC record contains a policy (`p=`) that escalates in strength:
- p=none: monitor only. Nothing is blocked, but you receive reports. This is where you start.
- p=quarantine: failing mail is sent to spam.
- p=reject: failing mail is refused outright. This is the goal, and the only setting that actually stops spoofing.
Many organisations publish `p=none` and stop there, which feels like progress but blocks nothing. The value is in reaching `p=reject`.
How to roll out DMARC safely
Rushing to `p=reject` can break legitimate mail: newsletters, invoicing tools and CRMs that send on your behalf. Follow a staged approach:
1. Publish SPF and DKIM first
Make sure every legitimate service that sends mail for you is listed in SPF and signs with DKIM. This includes your email provider, marketing platform, help desk, and any finance or invoicing tools.
2. Start at p=none and read the reports
Publish a DMARC record at `p=none` with a reporting address. The aggregate reports show you every source sending mail as your domain, including forgotten services and impersonators.
3. Fix the legitimate sources
For each real service that is failing, add it to SPF or enable DKIM until all your genuine mail passes.
4. Move to quarantine, then reject
Once your legitimate mail passes cleanly, tighten the policy to `p=quarantine`, watch for a couple of weeks, then move to `p=reject`. Now spoofed mail is blocked and your domain is protected.
How to check where you stand
You can check your current SPF, DKIM, and DMARC posture with free public tools, or run a live check on your own domain with our Attack Surface tools. If you see "no DMARC record" or "p=none", your domain can currently be spoofed, and that is one of the fastest, cheapest gaps to close.
Reading a DMARC record, field by field
A published record is a single DNS TXT entry at `_dmarc.yourdomain.co.uk`. A typical one looks like this:
`v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.co.uk; pct=100; adkim=s; aspf=s`
- v=DMARC1: the version. Always this value, and it must come first.
- p=: the policy applied to mail that fails: `none`, `quarantine` or `reject`.
- sp=: an optional separate policy for subdomains. If you omit it, subdomains inherit `p`. Attackers do target forgotten subdomains, so set this explicitly once you are confident.
- rua=: where aggregate reports are sent. This is the field that makes DMARC useful; without it you are flying blind.
- ruf=: forensic reports on individual failures. Most providers no longer send these, and they can contain personal data, so most organisations leave it off.
- pct=: the percentage of failing mail the policy applies to. Useful for a gradual rollout: `pct=25` applies your policy to a quarter of failing mail.
- adkim= / aspf=: alignment strictness, `r` for relaxed (the default) or `s` for strict. Start relaxed; tighten later if you have a reason to.
Alignment: the part that trips people up
DMARC does not simply ask "did SPF pass?". It asks whether the domain that passed SPF or DKIM matches the domain the recipient actually sees in the From header. That match is called alignment, and it is where most confusing failures come from.
A marketing platform might send on your behalf with a perfectly valid SPF record, but if the envelope sender is `bounces.theplatform.com` and your From address is `hello@yourdomain.co.uk`, SPF passes while alignment fails. The message still fails DMARC.
The practical consequence: it is not enough for your senders to "have SPF". They must either send from a subdomain of your domain, or sign with a DKIM key published on your domain. Any reputable provider documents how to do this; it usually means adding a CNAME record they give you.
A realistic 30-day rollout plan
Days 1-3. Inventory your senders. List every system that sends email as you: the email platform itself, your CRM, invoicing and accounting tools, the help desk, marketing and newsletter tools, HR and recruitment systems, booking or e-commerce platforms, and anything a department signed up for independently. This last category is where rollouts fail.
Day 3. Publish SPF and DKIM. Ensure each legitimate sender is covered. Keep SPF within the ten-lookup limit, and exceeding it causes a permanent error and SPF simply stops working.
Day 4. Publish `p=none` with a `rua` address. You are now monitoring, blocking nothing, and breaking nothing.
Days 5-14. Read the reports. Aggregate reports arrive as XML; a free DMARC report reader makes them legible. You are looking for two things: legitimate senders that are failing, and unfamiliar sources that may be spoofing you.
Days 14-21. Fix the failures, then move to `p=quarantine`. Consider `pct=25` first if your mail volume is high, then raise it.
Days 21-30. Move to `p=reject`, then set `sp=reject`. Keep the `rua` address live permanently. DMARC is a control you monitor, not one you set and forget.
What DMARC does not protect against
It is worth being precise, because DMARC is often oversold.
- Lookalike domains. DMARC protects `yourdomain.co.uk`. It does nothing about `your-domain.co.uk` or `yourdomaln.co.uk` registered by an attacker. Those need monitoring and, where warranted, defensive registration.
- Display-name spoofing. An attacker can put "Your Finance Director" as the display name on a Gmail address. DMARC has no view on this; it is a training and mail-filtering problem.
- Compromised accounts. If an attacker is logged into a real mailbox on your domain, their mail is genuinely from you and passes every check.
- Inbound protection. DMARC stops others spoofing *you*. Whether you are protected from spoofed inbound mail depends on your own mail provider honouring other organisations' DMARC policies.
This is precisely why domain authentication and human decision-making have to be addressed together. A protected domain removes one large class of attack; it does not remove the payment-diversion email sent from a compromised supplier's real account.
Why this matters commercially, not just technically
Three arguments tend to land with a board that is unmoved by DNS.
Supplier assurance. Security questionnaires increasingly ask about email authentication. "We are at p=reject" is a clean answer that removes friction from procurement.
Fraud liability. Invoice redirection fraud committed using your spoofed domain damages a customer relationship even when you are not legally liable. The reputational cost lands on you regardless.
Public sector and grants. UK government supplier guidance has pushed DMARC for years, and Cyber Essentials-adjacent expectations continue to tighten. For organisations bidding for public work, this is close to table stakes.
How to check where you stand
You can check your current SPF, DKIM, and DMARC posture with free public tools, or run a live check on your own domain with our Attack Surface tools. If you see "no DMARC record" or "p=none", your domain can currently be spoofed, and that is one of the fastest, cheapest gaps to close.
The bottom line
DMARC at `p=reject` is one of the highest-impact, lowest-cost security controls available to a small organisation. It protects your customers and suppliers from fraud committed in your name, and it is usually a few DNS changes away.
Publishing `p=none` and leaving it there is the single most common mistake. It produces a reassuring green tick on a questionnaire while blocking precisely nothing. Give yourself thirty days, work the plan above, and finish the job.