Skip to content
DomainVigil
Sign up

Reference guide

What is DMARC?

SPF and DKIM return verdicts. DMARC ties those verdicts to your name, requires them to point at the visible domain, and tells receivers what to do when they fail.

8 min readUpdated September 12, 2026

In short

DMARC is a TXT record published under the name _dmarc.yourdomain. It requires the domain validated by SPF or DKIM to match the one shown in the recipient's mail client. It says what to do when they do not match — none, quarantine or reject — and it asks for daily reports on what is being sent in your name.

What DMARC is for

A message can pass SPF and DKIM cleanly and still show your name without your consent. The sender only has to validate a domain they control, then write yours in the field a human reads. Both checks pass, and the spoof goes through. DMARC closes that door: it requires the validated domain and the displayed domain to match.

DMARC also adds something neither of the other two gives you: feedback. The large mail providers send a daily report listing what arrived in your name, from which addresses, and with what result. It is the only way to find out what actually sends under your domain — the invoicing tool nobody mentioned included.

DMARC also carries a decision. The domain owner tells receivers everywhere what to do with a message that fails. Make that decision last, once you have read the reports — never on day one.

A DMARC record, term by term

It always lives under the same name, whatever the extension, and reads as a series of tags separated by semicolons.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:reports@example.com; adkim=s; aspf=r; pct=25"

  1. _dmarcThe reserved name

    Always this prefix, underscore included, in front of the domain. Publishing the record at the root of the domain instead is the commonest mistake, and it is a silent one.

  2. v=DMARC1The version

    Required, and first. A record whose opening tag is anything else is ignored outright.

  3. p=quarantineThe policy

    Required, and second. What you ask receivers to do with a message that fails: none, quarantine, or reject.

  4. sp=rejectThe subdomain policy

    Optional. Without it, subdomains inherit the domain policy. With it, you can be harder on the names that send nothing than on the ones that do.

  5. rua=mailto:...Where to send the reports

    The address that receives the daily summaries. The single most useful tag in the record: without it you are flying blind.

  6. adkim=sDKIM alignment

    Strict here: the signing domain must be the displayed domain exactly. Relaxed, a subdomain would do.

  7. pct=25The share affected

    The policy applies to only a share of failing messages. It is there to ramp up gradually, not to sit on.

DMARC tags and their values

Two tags are required, in that order. Every other tag has a default, and knowing the defaults saves you writing out what already applies.

TagAccepted valuesDefault and effect
vDMARC1Required, in first position.
pnone, quarantine, rejectRequired, in second position. none takes no action; it only observes.
spnone, quarantine, rejectDefaults to the value of p. Set it explicitly when subdomains need different treatment.
ruaone or more mailto: addressesNone. With no rua, no report is sent and you tune the policy blind.
rufone or more mailto: addressesNone. Per-message failure reports, which most large receivers do not send.
pct0 to 100100. The policy applies to this share of failing messages.
adkimr (relaxed) or s (strict)r. Relaxed, a signing subdomain is enough; strict, the exact domain is required.
aspfr (relaxed) or s (strict)r. Same logic for the domain validated by SPF.
fo0, 1, d, s0. Decides when a failure report is requested: here, only when both checks fail.
rfafrfafrf. The format of failure reports.
ria number of seconds86400, one report a day. The value is a request, not a guarantee.

Check your own domain, right now

Enter a domain name: the tool reads its DMARC record, its policy and its reporting address, and checks that SPF and DKIM keep up.

No sign-up, no email required. You can paste a full address — we'll pull the domain out of it.

The staircase, from observation to rejection

Going straight to reject is the fastest way to cut off legitimate mail nobody told you about. Take the five steps in this order, and do not skip the first.

  1. 1

    Observe

    Publish the mildest policy with a reporting address. Nothing changes for anyone, and the daily summaries start arriving.

    v=DMARC1; p=none; rua=mailto:reports@example.com

  2. 2

    Read and repair

    The reports list every source sending in your name. Ask two questions of each: is it legitimate, and if so does it pass SPF or DKIM on the right domain? This is where the work happens, over a few weeks.

  3. 3

    Quarantine a share

    Once nothing legitimate fails any more, act on a share only. If you overlooked a sender, it does not disappear all at once.

    v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@example.com

  4. 4

    Extend to everything

    The same policy, without the share. Failing messages land in junk at every receiver that honours the request.

    v=DMARC1; p=quarantine; rua=mailto:reports@example.com

  5. 5

    Reject

    The last step: failing messages are refused before they reach a mailbox. It is the only policy that really protects your name, and it goes in only after the other four.

    v=DMARC1; p=reject; rua=mailto:reports@example.com

Relaxed or strict alignment

This is the heart of DMARC, and it clicks the moment you see the two side by side. The question is always the same: is the validated domain the displayed domain?

Relaxed (r)

Strict (s)

What is compared
The root domain, subdomains included.The exact name, character for character.
Shown: contact@example.com, validated: mail.example.com
Aligned. Both belong to the same root domain.Not aligned. The check fails.
Shown: contact@example.com, validated: example.net
Not aligned.Not aligned.
When to pick it
By default, and in almost every case. Providers often sign from a subdomain.When you control every sender and want the door shut down to subdomains.

DMARC passes as soon as ONE of the two checks is both valid and aligned. It never requires both — which is what lets a forwarded message, where SPF has failed by definition, get through on its signature.

The mistakes that leave DMARC inert

  • The record is published at the root of the domain

    What causes it: The DNS interface offers a name field, it gets left empty out of habit, and the record lands on the domain itself instead of _dmarc.

    What fixes it: Republish under the name _dmarc. Nothing reports the mix-up: the record exists, it is just that nobody looks for it there.

  • Rejection is set on day one

    What causes it: Someone applies a recommendation read somewhere, skips the observation stage, and never finds out what sends mail under the domain.

    What fixes it: Drop back to the mildest policy, read the reports for a few weeks, then climb the staircase one step at a time.

  • The reports never arrive

    What causes it: The reporting address sits on a different domain from the one being watched. That case needs an authorization record published by the receiving domain, and nobody published it.

    What fixes it: Either receive the reports at an address on the domain itself, or publish the cross-domain authorization record on the receiving domain.

  • Defensive domains are left unprotected

    What causes it: DMARC goes on the website's domain, and the registered variants around it are forgotten. They send nothing, which makes them the easiest names to abuse.

    What fixes it: On every domain that sends no mail, publish a rejection policy and an SPF record that authorizes nobody. Two records, no upkeep.

The questions that come next

Does DMARC protect the mail I receive?

No. DMARC protects your domain at everybody else's door: it tells servers worldwide what to do with a message claiming to be from you. What lands in your own mailbox depends on the policies sending domains publish and on your own filtering.

Should failure reports be turned on?

Rarely. They carry excerpts of real messages, and therefore personal data, and most large receivers do not send them anyway. The daily aggregate reports are enough to steer the rollout.

What is the percentage actually for?

To make a mistake survivable. If you overlooked a legitimate service, applying the policy to a quarter of messages lets the other three quarters through, and the problem surfaces before it is total.

Is a subdomain without DMARC covered?

Yes, by the parent domain's policy, or by the subdomain policy tag when present. That is the difference from SPF, where every name must publish its own.

A policy set in June can be gone by September

A change of DNS host, a zone reimported from a backup, a record overwritten: the policy vanishes without anything visibly breaking. DomainVigil re-reads the DMARC record on every domain you own each day and emails you if it changes or disappears.

Start for free

Five domains free, forever. No card required.

The other reference guides