Guides

How to do DMARC properly: check the record you already have

A setup wizard hands you a p=none record. Replace yours and you weaken it; add it beside yours and receivers apply no DMARC at all. Plus the records that look published and aren't.

Yowl reads your DMARC record before it hands you anything, and refuses to weaken it. If you already publish a policy we leave it alone, because our own record says p=none and a customer already on quarantine would be downgrading themselves by pasting ours. It stays advisory throughout: you paste the record, we never touch your DNS.

DMARC is a ladder, and Yowl climbs it with you

Everyone tells you to “start at p=none and tighten later”. Almost nobody tightens, because the step from monitoring to enforcing is a judgement call made on evidence you do not have.

Yowl is built around supplying that evidence and then asking. The reports come back to an address on your own domain — which Yowl already hosts, so there is nothing to sign up for and no third party holding your traffic data — and they are parsed into one answer: who actually sent as you, whether they aligned, and for how long that has been true. When it has been clean long enough, the domain page shows one card: it is time to tighten. When there is nothing to do, it shows nothing:

{ "live":  { "status": "quarantine", "record": "v=DMARC1; p=quarantine; rua=mailto:..." },
  "statusSince": "2026-09-14", "firstReportAt": "2026-09-15",
  "card": null,
  "note": "nothing to act on — no DMARC card is showing on the owner's dashboard" }

Ask your agent “where are we on DMARC?” and that is what it reads. One rung, or nothing.

And it argues the right way round. The usual reason a domain is stuck on p=none forever is “but we also use Mailchimp”. That is not a reason to stay unprotected — it is a reason to publish Mailchimp’s DKIM selector so it signs as you. Authorising another sender is a DNS record, never an exemption, and if something breaks under enforcement the fix is to authenticate it rather than to weaken the policy. Yowl will never offer you the weaken option, and will not pretend tightening improves your own deliverability either: mail sent through Yowl is signed and aligned at every policy level, so the ladder is about stopping other people forging you, which is the only thing it was ever for.

⛔ What that buys, stated plainly, because it usually isn’t: at p=quarantine or p=reject, only the senders you have authorised can send as your domain. Everyone else is blocked — at the receiver, before your customer ever sees it.

That whole behaviour exists because of the trap below, which is the one most domains are sitting in.

Most DMARC advice assumes you are starting from nothing The interesting failures happen on domains

that already have a record, because the instruction every provider gives — add this TXT record at _dmarc — has two possible readings and both of them can break you.

DMARC is one TXT record at _dmarc.example.com, saying what a receiver should do with mail that claims your domain and fails authentication. A message passes when either SPF or DKIM passes and that pass is aligned with the From domain the reader sees — a newsletter tool with a Return-Path on bounce.tool.com signing d=tool.com passes both checks, aligns with neither, and fails.

The fork

You already publish v=DMARC1; p=reject. A new provider’s setup page shows you v=DMARC1; p=none; rua=... and says to add it.

If you replace yours, you have just moved from reject to none. Every forgery of your domain that was being bounced this morning is delivered this afternoon. Nothing errors. No checker complains — you have a valid DMARC record.

If you add it alongside, it is worse. Receivers query _dmarc, discard anything not starting v=DMARC1, and if more than one record survives that filter they abort and take no DMARC action at all. Not the stricter one, not the newer one, not the first one. Two perfectly valid records produce exactly the same outcome as having none, deliberately, on the reasoning that an ambiguous policy is more dangerous than no policy.

⛔ This is not the SPF rule wearing a different hat. Two v=spf1 records give you a PermError — an error state you can see. Two DMARC records give you silence: policy simply becomes undiscoverable, and your DNS panel shows two records that are each individually correct.

And silence now costs money. Microsoft’s consumer Outlook requires a resolving, aligned DMARC record from anyone sending it more than 5,000 messages a day, and since 5 May 2025 it rejects outright rather than junk-foldering as first announced — 550 5.7.515 Access denied, sending domain does not meet the required authentication level. A duplicate _dmarc reads as no DMARC, so it trips that rejection while the owner is looking at two valid records and concluding the problem must be somewhere else.

Records that look published and aren’t

Multiplicity is one of four states that a DNS panel renders identically. Worth knowing all four, because “we have DMARC” is not one fact.

That third row deserves its reputation carefully rather than a slogan. It is not a no-op: receivers still evaluate DMARC and still stamp dmarc=pass or dmarc=fail, a pass is still a positive signal, and the record does satisfy the Google, Yahoo and Microsoft bulk-sender requirement. What it does not do is enforce anything or tell you anything. That combination — compliant, invisible, silent — is why it is the single most common DMARC record in the wild.

A fifth trap the table cannot show: sp sets the subdomain policy and defaults to p, so a policy read off the apex says nothing definite about what a subdomain is doing.

Check yours before you paste anything

dig +short TXT _dmarc.example.com

Three questions, in order. How many of those lines start with v=DMARC1? More than one is the silent failure above. Does the survivor carry a real p=? Does it carry a rua=? A record that answers “one, yes, yes” is a record you should not let a wizard overwrite.

If your policy is already stricter than the record you have been handed, keep yours and add only the records the provider actually needs — its DKIM key and its sending record. The _dmarc record is the one piece of a provider’s instructions that is about your domain’s posture rather than their authorisation to send, which is exactly why it is the one they should not be dictating.

For what the fields mean and what the 2026 specification changed underneath all of this, see what RFC 9989 changed about DMARC.

Connect a domain to Yowl →