DMARC: telling the world what to do with fake emails from your name

The short version

The gap DMARC fills

Picture a receiving server — Gmail, say — getting an email from accounts@yourbusiness.co.uk. It checks SPF: the sending server is not on your list. It checks DKIM: there is no valid signature. So it knows the message is probably fake. Now what? Without DMARC, there is no instruction from you, so Gmail makes its own judgement — and very often delivers the message to the inbox with no warning. All your SPF work has produced a slightly higher spam score and nothing more.

DMARC adds two things. First, a policy: your explicit instruction for messages that fail — none (just report), quarantine (put it in spam) or reject (do not deliver at all). Second, alignment: it insists that the domain SPF or DKIM validated is the same domain the *recipient sees* in the From line, closing the loophole where an attacker passes SPF on their own domain while displaying yours.

DKIM, briefly

DKIM gives each outgoing email a digital signature using a private key only your mail provider holds; the matching public key is published in your DNS. Receivers verify the signature, which proves the message came from your provider and was not altered in transit. Unlike SPF, it survives forwarding. Setting it up is almost always a matter of switching it on in your email provider's admin panel and copying one or two DNS records they give you — Google Workspace, Microsoft 365 and every reputable newsletter tool support it. DMARC can pass on either SPF *or* DKIM, so having both makes your legitimate mail resilient.

What a DMARC record looks like

It is a TXT record at _dmarc.yourbusiness.co.uk. The simplest safe starting point is:

v=DMARC1; p=none; rua=mailto:dmarc@yourbusiness.co.uk

p=none means "take no action yet, but report to me". rua= is where aggregate reports go — daily summaries from each receiver of what passed and failed. Once you have confirmed all your real senders pass, you tighten it:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourbusiness.co.uk; adkim=s; aspf=s

and finally to p=reject. pct= lets you apply the policy to a percentage of mail while ramping up. adkim=s and aspf=s demand strict alignment (exact domain match rather than allowing subdomains). sp= sets a separate policy for subdomains, which is worth setting to reject if you never send from them.

Why p=none is only a starting point

We flag p=none as a finding — a mild one — because it is where a lot of businesses stop. It gives you visibility, which is valuable, but it does not protect anyone: fake emails are still delivered. The journey is meant to be none → quarantine → reject, usually over four to eight weeks, and the reports tell you when it is safe to move.

Those reports arrive as XML attachments, which are unreadable by hand. Free and low-cost services (Postmark's DMARC Digests, dmarcian, EasyDMARC, Cloudflare's DMARC Management) will take them in and show you a simple dashboard: which services are sending as your domain, which pass, which fail. Typically you discover a forgotten sender or two — the website contact form, the old CRM — add them to SPF or enable DKIM for them, and then move to reject.

Setting it up

Make sure SPF is in place and DKIM is enabled with your email provider (and any newsletter or transactional service). Create a mailbox or alias to receive reports, or sign up for a reporting service and use the address they give you. Then add the TXT record at _dmarc in the DNS that your nameservers actually use, starting with p=none. Review reports after a couple of weeks, fix any legitimate senders that fail, then move to p=quarantine and later p=reject.

If you have a domain that sends no email at all — a holding domain, a brand variant — publish v=DMARC1; p=reject; alongside v=spf1 -all and be done.

What VigilScan checks

We look up _dmarc.yourdomain and report whether a valid record exists, what the policy is (flagging none as weaker than quarantine/reject), and whether reporting addresses are present. For DKIM, we check the common selectors used by major providers (google, selector1/selector2 for Microsoft, default, and others); if your provider uses a custom selector we may not see it, so a DKIM finding on a domain where you know it is enabled is worth checking against your provider's record rather than taken as gospel.

Common questions