Module 4 · 4.5

English

Nederlands English Deutsch Français Dansk Español Svenska Italiano Polski Português Română Čeština Ελληνικά Български Hrvatski Norsk Lietuvių Slovenščina

DMARC: what receivers should do with fake mail

Module 4: Records for email · Reading time: 10 minutes

Learning objective: After this lesson you can explain how DMARC combines SPF and DKIM, set up a valid DMARC record, and tighten the policy step by step.

Key concepts: DMARC, _dmarc, v=DMARC1, policy p=none / quarantine / reject, alignment, rua reports, sp= and np=, test mode t=, one DMARC record

The missing piece

SPF (lesson 4.3) checks which server a mail comes from, but looks at the technical envelope address. DKIM (lesson 4.4) checks a signature, but that can be from any domain. So a scammer can send a mail with "From: info@example.com" that passes SPF nicely for their own domain and is neatly signed by their own domain.

DMARC (Domain-based Message Authentication, Reporting and Conformance) closes that loop. It asks one question: does the passed SPF or DKIM check belong to the domain the receiver sees in the "From:" address? That's called alignment. And you tell receivers what to do if the answer is no.

DMARC was described in RFC 7489 in 2015. In May 2026, the revised version was published as an official internet standard: RFC 9989 (with RFC 9990 and 9991 for the reports). Existing records with v=DMARC1 remain valid.

How a receiver decides

If a mail arrives with sender info@example.com, the receiver does the following:

SPF: does the mail come from an allowed server, and does the envelope domain belong to example.com?
DKIM: is there a valid signature, and does the signing domain (d=) belong to example.com?
DMARC: did at least one of these two pass and align? Then the mail is fine. If not, the receiver follows your policy.

One of the two is enough. That's why DKIM is so important for services that send with their own envelope address, such as many newsletter services: there, SPF passes, but not for your domain. Only a DKIM signature with d=example.com makes it fine then.

"Belongs to" means by default: the same organisational domain. nieuws.example.com belongs to example.com. That's called relaxed alignment. With adkim=s or aspf=s (strict) it must be exactly the same domain. For almost everyone, relaxed is fine.

What does a DMARC record look like?

A DMARC record is a TXT record on the name _dmarc of your domain:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

It consists of parts (tags) separated by a semicolon.

Tag	Meaning
`v=DMARC1`	This is a DMARC record. Must come first.
`p=`	The policy for your domain: `none`, `quarantine` or `reject`.
`rua=mailto:...`	Optional: address for daily aggregate reports.
`sp=`	Optional: different policy for subdomains that exist.
`np=`	Optional (new in RFC 9989): policy for subdomains that don't exist, such as `factuur.example.com` if you've never created it. Scammers love using such names.
`adkim=` / `aspf=`	Optional: `r` (relaxed, default) or `s` (strict).
`t=y`	Optional (new in RFC 9989): test mode. Receivers apply a policy one step milder. Replaces the old `pct=`.

Choosing the policy

Policy	What the receiver does
`p=none`	Nothing. Mail is delivered as normal. You do get reports if you fill in `rua`. This is also called monitoring.
`p=quarantine`	Mail that doesn't pass goes to the spam folder.
`p=reject`	Mail that doesn't pass is rejected. The best protection against misuse of your name.

Sensible order:

First get SPF and DKIM right, for all services that send mail on your behalf: your mail provider, your website, your newsletter service, your accounting software, your webshop.
Start with p=none and a rua address. Check the reports for a few weeks to see which services send mail on behalf of your domain and whether they pass.
Move to p=quarantine, and if everything keeps going well, move to p=reject.

If you're unsure whether all your services are set up correctly, don't jump straight to reject. A forgotten service (for example the program that sends your invoices) will then no longer get through.

Some hosting providers set a strict DMARC record (p=reject) immediately for a new package. That's safe as long as all your mail runs through their servers. If you also send mail through other services, check the SPF and DKIM of those services first.

Reports

With rua=mailto:dmarc@example.com, large receivers send you a daily overview (an XML file) of who sent mail on behalf of your domain and whether it passed. Useful, but technical. Use a separate address for it; you'll quickly get several a day. There are services that make the reports readable.

If you send reports to an address on an other domain (for example a reporting service), that other domain must give permission in its DNS. The service usually arranges this itself.

Common mistakes

Two DMARC records. There may only be one on _dmarc. With two, the receiver treats it as if you have no DMARC. Adjust the existing record instead.
On the wrong name. The record belongs on _dmarc.example.com, not on example.com itself.
Typos in the tags. p=reject works, p=rejected or policy=reject doesn't. Without a valid p=, the record counts as p=none.
Enabling DMARC before SPF and DKIM are correct. Then you reject your own mail.
Checking again too soon after a change. A DMARC record sometimes has a long TTL (for example four hours). After a change, you'll still see the old record for a while.

Why it matters

Since February 2024, Gmail and Yahoo have required senders of large volumes of mail (more than about 5,000 per day) to have a DMARC record, at least with p=none, and for SPF or DKIM to pass aligned. Microsoft has required the same since May 2025 for Outlook.com and Hotmail. Even for small senders, DMARC improves delivery and protects your customers against fake invoices sent in your name.

In practice: what it looks like in a panel

In this example we use DirectAdmin. In DNS Administration, click the pencil next to the TXT record _dmarc, or create a new TXT record with name _dmarc and choose DMARC under TXT Record Type. Under Domain policy type, choose None, Quarantine or Reject; under Aggregate Email (RUA) you can optionally enter a report address. My WebOké has a similar DMARC helper on the DNS tab.

If your panel doesn't have a helper, just create a plain TXT record on _dmarc and type the text yourself. The result is the same.

Summary

DMARC checks whether SPF or DKIM passes for the domain in the "From:" address (alignment).
The record sits on _dmarc.<domain>, starts with v=DMARC1, and has a policy of p=none, quarantine or reject.
First SPF and DKIM for all services, then p=none with reports, then tighten.
Exactly one DMARC record per domain.

Quiz

Exercise

Exercise Z4.5: Looking up DMARC. Look up the DMARC record of sidn.nl (SIDN is the registry of .nl in the Netherlands), or of your own domain. Paste the full record and fill in which policy (p=) is set.

Exercise O4.5: Setting it up yourself in your practice zone. In the practice zone you send the reports to a fixed practice address; for your real domain you use an address of your own. In your practice zone <code>.dnspractice.eu, create a DMARC record with policy quarantine (or none if you want to start with monitoring) and reports to dmarc@dnspractice.eu (rua=mailto:dmarc@dnspractice.eu).

Exercise O4.5

You'll do this exercise in your own practice zone: a real DNS zone on WebOké's nameservers, just for you. Sign up with your email address. You'll get a login link by email and then come back to this lesson. We only use your address for the course.

Cookies at WebOké

Cookie settings

Necessary

Marketing