Last reviewed:
Translated from German; if the versions differ, the German version applies.
Setting up DMARC: step by step
DMARC links the two checks SPF and DKIM to the sender address that recipients see, and tells receiving servers what to do with emails that fail the check. Gmail, Yahoo and Outlook.com require bulk senders to have at least a DMARC record with p=none. This page shows the way from the first record to a policy that rejects forged emails. It is based on RFC 9989 of May 2026, which replaces the earlier version RFC 7489.
Step 1: Check the prerequisites
Before you set up DMARC, every system that sends emails in your name should pass SPF or DKIM – preferably both:
- Inventory: who sends emails with your domain as the sender? Typical examples are your own mailbox, the newsletter platform, the shop, the accounting software, a contact form, a ticket system.
- SPF: all these services are in the SPF record of the domain – there may only be one (RFC 7208). Details under Creating and checking an SPF record.
- DKIM: each service signs with a key under your domain (RFC 6376). If a service signs only with its own domain, it passes DKIM, but not aligned with your sender address.
Step 2: The first record with p=none
DMARC is a TXT record under the name _dmarc of your domain. A good start:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"| Part | Meaning |
|---|---|
v=DMARC1 | identifier, must come first |
p=none | no instruction to recipients – observe only |
rua=mailto:… | address for the daily aggregate reports |
RFC 9989 describes exactly this path: domain owners usually start with p=none and a reporting address, evaluate the reports, fix errors and only then decide on a stricter policy. You can put the record together with the DMARC builder; it explains every option but does not query the DNS.
Step 3: Reading the reports
Receiving servers that support DMARC reporting send aggregate reports as XML files to the rua address (RFC 9990). For each sending IP address they show how many emails arrived with your domain and whether SPF and DKIM passed and were aligned. What to look for:
- Your own services that fail. If the newsletter platform is missing from the SPF record or does not sign with your domain, you will see it here.
- Services you had forgotten. The invoicing software, an old contact form – everything that sends with your domain shows up.
- Unknown senders. Emails from servers that have nothing to do with you are often forgeries. A stricter policy works precisely against them.
The XML files are hard for people to read. There are services that evaluate them; check where the reports go, because they contain IP addresses and domain names.
Step 4: Tightening step by step
Once the reports have shown over at least a few weeks – for infrequent mailings such as monthly invoices preferably a few months – that all your own services pass, you can move on:
| Stage | Record (extract) | Effect |
|---|---|---|
| Observe | p=none | nothing, reports only |
| Test | p=quarantine; t=y | test mode: recipients should not yet fully apply the policy |
| Quarantine | p=quarantine | failing emails are treated as suspicious, e.g. spam folder |
| Reject | p=reject | failing emails should be rejected |
The former percentage switch pct has been dropped in RFC 9989; it is replaced by the test mode t=y or t=n. You will still find pct in older guides. For Outlook.com, Microsoft recommends p=reject in the long run.
Other switches
| Switch | Meaning | Default |
|---|---|---|
sp= | policy for subdomains | same as p |
np= | policy for subdomains that do not exist in the DNS at all | same as sp |
adkim=, aspf= | strict alignment (s, identical domain) or relaxed (r, same organisational domain) | r |
ruf= | address for failure reports on individual emails | – |
fo= | when failure reports are generated (only takes effect together with ruf) | 0 (report if neither SPF nor DKIM produces an aligned pass) |
Relaxed alignment (r) allows, for example, the newsletter platform to sign with news.example.com while the sender shows example.com. For most newsletters it is the right choice.
Common mistakes
- Two DMARC records under
_dmarc– then none applies. - Going straight to
p=rejectwithout having read any reports: your own invoices or form emails get rejected. - Reporting address in another domain without approval: under RFC 9989 (section 11.6), reporting addresses must as a rule be in the domain being reported on. For addresses at an external service, RFC 9990 describes a procedure by which that service’s domain agrees in the DNS; without this approval, no reports arrive.
- Forwarding and mailing lists change emails or the sending route; SPF and DKIM can then fail even though the email is genuine. Check anomalies in the reports before tightening.