How to set up DMARC step by step

DMARC is a DNS record in which the domain owner tells other mail servers: “This is how you recognise that a message really came from us, and this is what to do with messages that fail the check.” Without DMARC anyone can impersonate your domain and receivers have nothing to reject a forgery by.

How DMARC works

DMARC builds on two older mechanisms:

• SPF verifies that the message was sent by a server the domain allows (SPF guide),
• DKIM verifies the message's digital signature.

A message passes DMARC when it passes SPF or DKIM and at the same time the verified domain matches the sender domain the recipient sees (the From header). This is called alignment. Alignment is what stops the most common fraud – an attacker can have valid SPF for their own domain but put yours in the From field.

What you need first

1. Working SPF covering every server and service that sends for the domain.
2. DKIM on the mail server and ideally in other services too (newsletter, CRM, invoicing).
3. A report address, for example dmarc@company.com. XML reports arrive there daily, so a separate mailbox is a good idea.

Step 1: a monitoring record

Add a TXT record at _dmarc of your domain:

_dmarc.company.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@company.com"

The p=none policy does not change delivery yet – you just start receiving reports on who sends mail for your domain and whether it passes the checks.

What the tags mean

Tag	Meaning
v=DMARC1	version, must come first
p=	policy for the domain: none (monitor), quarantine (to spam), reject
sp=	policy for subdomains, if it should differ from p
rua=	where to send daily aggregate reports
ruf=	where to send per-message reports – most providers do not send them for privacy reasons
pct=	percentage of messages the policy applies to – useful when tightening gradually
adkim=, aspf=	DKIM and SPF alignment: r relaxed (same organisational domain is enough), s strict (exact match)

If reports go to an address in a different domain (e.g. a service that processes them), the destination domain must publish an authorisation record, otherwise report senders discard them.

Step 2: reading the reports

Reports arrive as compressed XML files from Gmail, Microsoft and others. They are hard to read by hand, so tools are used to turn them into an overview (open-source e.g. parsedmarc, or online services). Watch mainly for:

• unknown sources sending as your domain – either a forgotten service (add it to SPF/DKIM) or a fraudster,
• legitimate sources that fail – typically an invoicing system or newsletter without DKIM.

Allow 2–4 weeks so that occasional senders (monthly invoices, reminders) show up in the reports too.

Step 3: tighten gradually

1. p=quarantine; pct=25 – a quarter of unverified messages go to spam. Watch reports and complaints for a week.
2. p=quarantine (without pct, i.e. 100%).
3. p=reject – forged messages are rejected outright. The target state.

_dmarc.company.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@company.com"

Watch out for

• Forwarding – automatic forwarding breaks SPF (a different server sends the message). That is why DKIM matters: it survives forwarding.
• Mailing lists often change the subject or body and break the DKIM signature. Modern list software handles this by rewriting the sender.
• Domains you do not send from – give them p=reject and SPF v=spf1 -all as well, otherwise they are an easy target.
• Do not stay at p=none – monitoring protects nothing. It is only a transition phase.

How to verify

Check your domain's DMARC, SPF and DKIM in our free domain test. For a specific message, the result is in the Authentication-Results header – in Gmail via “Show original”, where SPF, DKIM and DMARC should all say PASS.