What Is DMARC? p=none, quarantine and reject Explained
DMARC lets a domain request how receivers handle mail that fails aligned SPF and/or DKIM authentication.
How it works
p=none requests monitoring, quarantine requests suspicious handling, and reject requests rejection. adkim and aspf default to relaxed; pct defaults to 100. rua and ruf are reporting destinations, but receiver support varies and this site never contacts them.
DMARC, SPF, DKIM, and visible From alignment
DMARC is a DNS policy for a domain's visible From address. It builds on SPF and/or DKIM authentication, then asks whether a passing authenticated domain aligns with that visible From domain. A raw SPF pass is not enough for DMARC when the envelope domain is unrelated to the From domain.
An aligned SPF result means the envelope sender domain that passed SPF matches the From domain under the selected alignment mode. An aligned DKIM result means a valid DKIM signature uses a d= domain that aligns with From. DMARC can pass through either aligned SPF or aligned DKIM; it does not require this site to perform a live DKIM validation, and this checker only reads the published DNS policy.
Alignment is relaxed by default for both SPF (aspf) and DKIM (adkim), allowing an organizational-domain relationship such as mail.example.com with example.com. Strict alignment requires an exact domain match. Choose strict modes only after understanding every legitimate sending path.
Policies and commonly used tags
p=none requests monitoring; p=quarantine asks receivers to treat failing mail suspiciously; p=reject asks them to reject it. These are requests, not guaranteed identical actions at every receiver. A domain can publish sp= to set a different policy for subdomains, while pct= applies the requested policy to a percentage of failing mail. When pct is absent, it defaults to 100.
rua= lists aggregate-report destinations and ruf= can list failure-report destinations. Reporting support, privacy rules, and recipient behavior vary; our checker never contacts either destination. fo= controls requested failure-report conditions and ri= suggests an aggregate report interval. They help describe a policy but do not guarantee that reports will arrive on schedule.
A practical starting record is v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. After the domain owner confirms legitimate mail streams, a staged record might use p=quarantine; pct=25. A mature policy may use p=reject, but enforcement should follow evidence rather than a copied template.
Monitoring, rollout, and common mistakes
Start by inventorying services that send mail with the domain in From: people, help desks, invoices, newsletters, and applications. Make sure each has aligned SPF or DKIM, then monitor aggregate reports through an approved reporting workflow. Increase pct or policy strength deliberately, checking subdomains and third-party senders along the way.
Common mistakes include publishing the record at the base domain instead of _dmarc.example.com, using multiple DMARC records, overlooking a subdomain policy, and treating p=none as protection. Another mistake is assuming a valid-looking record guarantees delivery: mailbox providers still apply reputation, content, authentication, and local policy.
DMARC reduces some forms of direct-domain spoofing, but it does not eliminate all impersonation, abuse, compromised accounts, or lookalike domains. It also cannot guarantee every receiver will handle a failing message in the same way. Treat it as an authentication and policy layer, not a complete email-security score.
How to read the checker
The DMARC Checker queries the normal _dmarc subdomain and reports one record, no record, multiple records, malformed records, or a DNS-unavailable condition separately. It exposes useful tags such as p, sp, pct, rua, ruf, adkim, aspf, fo, and ri without attempting to contact reporting addresses.
Absent adkim and aspf mean relaxed alignment, and absent pct means 100 percent. The result describes the published policy, not whether every mail source passes SPF or DKIM. Pair it with SPF and MX checks for DNS context, then use your mail platform's approved reporting and authentication evidence for operational decisions.
For example, a message can pass SPF for bounce.mailvendor.example while displaying From: example.com. That SPF result does not satisfy DMARC for example.com unless the domains align under the configured mode. An aligned DKIM signature from example.com could instead satisfy DMARC. This distinction is why an apparently passing authentication result and a DMARC failure can coexist, and why enforcement must be introduced only after every legitimate sender has been checked.
Practical guidance
- Start with p=none and review legitimate senders before enforcement.
- Confirm SPF and DKIM alignment with the visible From domain, including third-party senders.
- Raise policy strength deliberately; receiver handling is not guaranteed to be identical.
Common question
Does reject guarantee blocking? No. DMARC communicates the domain owner's request, and receivers apply their own policies.