What DMARC none, quarantine and reject really do

The standard stores a domain owner's preferences as DNS TXT records in a _dmarc subdomain (section 6.1 of RFC 7489 ¹). The p tag carries the requested policy for mail that fails the DMARC check, and the standard words every value as something the owner wishes or requests, never as something it guarantees (section 6.3 ¹).

Three more tags change how far the policy reaches. sp sets the policy for subdomains only, and when it is missing the p value applies to them. pct is the percentage of the domain's mail the policy is applied to. rua lists the addresses that receive aggregate reports (all section 6.3 ¹).

The gap between having a record and being protected comes from a handful of settings. Check for each of these before you treat a domain as safe.

• The policy is none. A record at this level only collects reports, so a forged message is delivered like any other.
• pct is below 100. The standard applies the policy to only that share of messages, so the rest are handled as if the policy were weaker.
• The subdomain policy is weaker. An explicit sp=none leaves every subdomain unprotected even when p=reject guards the main domain.
• Alignment is satisfied by the attacker. A message passes when SPF or DKIM validates a domain that matches the domain in the From address (sections 3 and 3.1 ¹). Strict and relaxed modes decide how closely they must match, so relaxed settings accept sibling subdomains under one organizational domain.
• Receivers may deviate. The standard says a receiver MAY choose to accept failing mail even when the policy is reject (sections 6 and 6.7 ¹), for example because of local allow lists.

DMARC also speaks only about the domain in the From address. A lookalike domain the attacker registered is a different domain with its own, usually empty, record, so no policy on your domain can stop mail from it.

The product reads the TXT record at _dmarc.<domain> and returns the parsed tags in a dmarc object: policy, subdomain_policy, pct, rua, valid and a list of issues. Issue codes are no_dmarc_record, multiple_dmarc_records, missing_policy_tag and invalid_policy_value. It never contacts a mail server, and it does not test whether real mail would pass alignment.

One difference from a receiver matters. The standard has receivers retry at the organizational domain when the exact domain has no record (section 4.3 ¹). Our check reads only the name you send, so a subdomain with no record of its own is reported as no_dmarc_record even if its parent publishes a policy. Query the parent domain as well when you audit subdomains.

1curl -X POST https://YOUR_API_HOST/v1/email-domain-check \
2  -H "Authorization: Bearer $LOOKVALID_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{"domain":"example.com"}'

1{
2  "record": "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s",
3  "record_count": 1,
4  "policy": "reject",
5  "subdomain_policy": "reject",
6  "pct": null,
7  "rua": [],
8  "valid": true,
9  "issues": []
10}

• policy of reject or quarantine with pct null (no value published) or 100: the domain asks for enforcement. Check subdomain_policy next.
• policy of none, or pct below 100: the domain is observing, not enforcing. Treat mail claiming to be from it as unauthenticated.
• valid false with an issue code: the record is missing or malformed, so receivers have nothing to enforce.
• Empty rua: the owner receives no aggregate reports, so it is unlikely to learn about abuse.

Run a single domain in the free DMARC checker, or call the API from your own audit script. The email-domain-check product page lists every field in the response.