quarentine, quarantaine, and the DMARC typos that void a record

Someone ran your domain through a scanner, the DMARC line came back red, and now you’re the one who has to explain it. You know there’s a record at _dmarc, because you or whoever held the job before you put it there. Pull it and read the p= tag one character at a time. A DMARC record with the policy word misspelled, missing or replaced by a placeholder is a record no receiver enforces, and of the 78,444,857 DMARC records in the September 2026 census, 43,329 carry a p= value that isn’t none, quarantine or reject.

What a receiver does with a policy word it can’t read

A receiving mail server fetches your record with the same query you can run from a laptop:

dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarentine; rua=mailto:[email protected]"

On Windows without dig, nslookup -type=TXT _dmarc.example.com shows the same string.

RFC 7489 is exact about what happens next. The receiver keeps only the records that start with v=DMARC1, splits the remainder on semicolons, and looks for a p tag whose value is one of three words. If the tag is missing or its value is anything else, section 6.6.3 allows two outcomes. When a usable rua= address is present, the receiver behaves as though you’d published p=none. When it isn’t, the receiver applies no DMARC processing to the message at all, and neither outcome involves guessing that quarentine meant quarantine.

You can see the outcome in the headers of a message you send yourself from the domain. A receiver that couldn’t parse the record writes a line like this into Authentication-Results:

Authentication-Results: mx.example.net;
  dmarc=permerror action=none header.from=example.com

permerror is the receiver saying the record is broken in a way that won’t fix itself on retry, and action=none is what it did with the message, which is nothing. A scanner that grades your domain reads the same record and reaches the same verdict, because it’s reporting what a mail server would do.

The league table of malformed p= values

The census parses the p= token out of each DMARC record it reads and keeps a count of the values that aren’t one of the three real ones. The twenty most common in the September 2026 census, with the number of records carrying each, are below. Scan down the middle column and find yours. Each row is a count of records; no domain is named in this data.

The table stops at twenty. The 43,329 malformed total includes the long tail of values too rare to make it, which is where the more creative typing lives.

Rank one: the record with no policy in it

25,906 records open with v=DMARC1 and never get round to p=. A typical one is the first step of a monitoring rollout that stopped after step one:

"v=DMARC1; rua=mailto:[email protected]"

Because the rua= address is there, section 6.6.3 has receivers treat this as p=none. The aggregate reports keep arriving, which is why the person who published it assumed the job was finished. Take the rua= out as well and the record does nothing whatsoever, for anybody.

The p tag is the one tag RFC 7489 marks as REQUIRED for a policy record; the other tags all have defaults. The fix is to add it. Use p=none if you still want monitoring only, and p=quarantine or p=reject once the reports show your legitimate mail passing. What each of those words instructs a receiver to do, tag by tag, is in the DMARC record anatomy.

Five ways to misspell quarantine

quarentine (4,358), quarantaine (1,439), quaratine (239), qurantine (232) and quarntine (109) are all the same word, mistyped. Quarantine is the longest of the three policy words and the one people type by hand when they move off none, so it collects the finger slips. quarantaine is the French and Dutch spelling, and the receiver compares bytes, so it fails the same way.

The record that results usually looks like a finished enforcement rollout:

"v=DMARC1; p=quarentine; pct=100; rua=mailto:[email protected]"

Every receiver on the internet reads that as p=none. The sender believes they moved to enforcement months ago, and nothing forged in their name has been quarantined since. pct=100 is doing nothing either, because there’s no policy for it to apply a percentage to.

Reject gets its own pair further down the list. rejet (362) is the French spelling, and refect (130) is a slip of the hand. The outcome is the same as the quarantine misspellings.

Words copied straight out of the guide

policy (4,108) is the value you get when a setup guide says “p=policy, where policy is none, quarantine or reject” and the reader pastes the template line without substituting. The Swedish policynamn (95) looks like the same habit, since the word means policy name. A lone p (465) is a placeholder that never got replaced, and monitor (113) most likely came off a dashboard that calls p=none monitoring mode.

nonev (190) is none with a stray character on the end, the shape you get when a semicolon goes missing and the next token runs into the value. Tags in a DMARC record are separated by ; and the receiver has no other way to know where one value ends.

Policies written in another language

non (432), ninguno (402), nenhum (350), aucun (263), keine (133) and yok (109) are none in French, Spanish, Portuguese, French again, German and Turkish. nome (141) sits with the placeholders rather than the translations; it means name in Portuguese and Italian and looks like the same template mistake as policynamn.

The three policy words are protocol tokens, the same way v=DMARC1 and rua are, and they don’t translate. The comparison ignores case, so p=REJECT is fine, and a single wrong letter, as in p=rejet, fails it.

Read your own record one character at a time

Run the query, then check the string that comes back against each of these.

1. Exactly one string begins with v=DMARC1. Two DMARC records at _dmarc and section 6.6.3 has the receiver abandon policy discovery, which leaves you with no policy from two records. DNS control panels that keep the old record when you add a new one cause this.
2. v=DMARC1 is the first tag. A record that opens with p=reject; v=DMARC1 fails the first filter and is discarded before the policy is read.
3. A semicolon follows v=DMARC1 and separates each tag from the next.
4. The value after p= is none, quarantine or reject, spelled as written here.
5. If sp= is present it obeys the same rule. Section 6.6.3 treats an invalid sp= the way it treats an invalid p=, so a subdomain typo voids the apex policy too. Whether you should be setting sp= at all is covered in the sp= tag nobody sets.
6. No quotation marks inside the value. Some DNS editors add their own around the string; pasting a value that already carries them leaves a record with quotes embedded in the middle.
7. Each rua= address is a mailto: URI. A bare address without the scheme isn’t a valid reporting URI, and without a valid one a missing p= drops from “treated as none” to “no DMARC processing”.

The free scan runs the same parse and shows you the record with the exact token it found.

Fix it and watch the header change

The edit is one word in one TXT record at your DNS host. Taking the quarentine example:

before: "v=DMARC1; p=quarentine; pct=100; rua=mailto:[email protected]"
after:  "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]"

Save it, wait out the TTL on the old record, and run the dig again until the new string comes back. Then send a message from the domain to a mailbox at a large receiver and open the raw headers. The Authentication-Results line now echoes the policy it parsed:

dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

A receiver that shows p=QUARANTINE in its own words has read your record and will act on it, and the scanner that started this will grade the same record the same way. If permerror is still there after the TTL has passed, go back through the seven checks above, starting with the first: a second record at _dmarc that you didn’t know was there.

What a fixed record buys you is spelled out in can someone spoof my domain, and it’s worth reading before you decide between quarantine and reject. For today, re-run the scan and send the person who asked a link to the green DMARC line.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.