DMARC
DMARC tells receiving servers what to do with mail that claims to be from your domain but fails DKIM and SPF. You publish one TXT record naming a policy, none, quarantine or reject, and an address for the reports. It also demands alignment: the domain that passed authentication has to match the one a reader sees in the From header.
At a glance
- Category
- Domain authentication
- Lives in
- A TXT record at _dmarc.<domain>
- Policies
- none, quarantine, reject
- Requires
- DKIM or SPF to pass, and to align with the From domain
- Reports to
- The addresses named in the record
- Specified in
- RFC 7489
How it works
A receiving server reads the From header, looks up the DMARC record for that domain, and checks whether either DKIM or SPF both passed and aligned with it. If neither did, the record's policy says what to do: nothing, treat it as suspicious, or refuse it outright. Whatever it decides, the server can send you an aggregate report naming the sources it saw and what happened to their mail, which is how you find senders on your own domain you had forgotten about.
Why it matters
Without DMARC, anybody can put your domain in the From header and the receiving server has no instruction about it. Publishing a record at p=none changes nothing about delivery but starts the reports, and the reports are the point: they show every system sending as you, including the invoicing tool nobody documented. Only once that list is complete and authenticated can you move to quarantine and then reject, at which point impersonating your domain stops working.
Example
A domain publishes a record at _dmarc.example.com reading v=DMARC1; p=none; rua=mailto:dmarc@example.com. Reports arrive daily and reveal three senders: the main email API, a help desk and a forgotten survey tool. The first two are authenticated, the third is switched to an authenticated path, and a month later the policy moves to quarantine and then to reject, with the reports confirming nothing legitimate is being caught.
Common mistakes
- 01Publishing p=reject on day one, which blocks the senders you have not yet found rather than revealing them.
- 02Setting up reporting and never reading it, so the record is a policy nobody has evidence for.
- 03Assuming a DKIM pass is enough, when DMARC also requires the passing domain to align with the From header.
- 04Publishing two DMARC records on the same name, which is invalid and leaves receivers with no policy at all rather than the stricter of the two.
In Rasket
The dashboard shows the record to publish, walks you from none up to reject, and warns you when a strict policy would block mail you have not finished authenticating. Domains
Related terms
Frequently asked questions
Where do I start with DMARC?
Publish a record with p=none and a reporting address. It changes nothing about how your mail is treated, and the reports it produces are what tell you which senders still need authenticating.
How long until I can move to reject?
Long enough for the reports to show a full cycle of your sending, including monthly and quarterly systems. Teams commonly spend weeks at none and weeks at quarantine before enforcing.
Does DMARC affect mail I receive?
No. Your record governs how other servers treat mail claiming to be from your domain. What you do with inbound mail is decided by your own mail host.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.