Build a DMARC record that follows RFC 9989, with every tag explained, a dated plan from p=none to p=reject and the extra record a report mailbox on another domain needs. Load and check your published record. Free, no sign-up.
A DMARC record is a TXT record at _dmarc. plus your domain that tells receiving mail servers what to do with a message whose From domain is not confirmed by SPF or DKIM: deliver it, put it in the spam folder or reject it. It also names an address that receives daily reports about who sends mail with your domain. DMARC starts with v=DMARC1 and is defined in RFC 9989, which replaced RFC 7489 in May 2026.
DMARC is the only one of the three mail records that protects the address a reader actually sees. SPF and DKIM each check something, DMARC decides.
1. Start with p=none and a report address. Nothing changes for your recipients yet. Receivers start sending aggregate reports: which servers sent mail with your domain, and whether SPF and DKIM passed for them. Without the rua address this step is worthless, because nobody sees the result.
2. Fix every legitimate sender, then tighten. The reports show the newsletter tool that is missing from SPF and the help desk that does not sign with DKIM. Once two weeks of reports show no legitimate mail failing, move to quarantine, first with t=y, then without it.
3. Finish at reject. At p=reject a forged message with your domain in From is refused before it reaches anyone. That is the goal; p=none on its own only documents the problem.
The generator turns the start date you enter into a schedule with a ready record for every stage: four weeks of monitoring, two weeks of quarantine in test mode, four weeks of quarantine, then reject. Shorten the steps if the reports are clean sooner, lengthen them if they are not.
| Field | Value |
|---|---|
| Type | TXT |
| Name / Host | _dmarc (the panel appends the domain), or _dmarc.example.com. where the full name is required |
| Value | the record from the generator, without quotes |
| TTL | the default; 3600 seconds is fine |
The most frequent mistake is the name: a DMARC record placed on the domain itself instead of on _dmarc is never found. The second is a duplicate. Exactly one TXT record starting with v=DMARC1 may exist at _dmarc; with two, receivers ignore DMARC completely. “Load published record” shows every record found at that name.
If the report address lives on a different domain, for example a reporting service, that domain has to publish a record that agrees to receive your reports. The generator writes it for you: a TXT record at example.com._report._dmarc.reports-provider.net with the value v=DMARC1. Without it, most receivers silently drop the reports.
| Tag | Meaning | Generator default |
|---|---|---|
p |
Policy for the domain: none, quarantine or reject. Required. | none |
rua |
Where aggregate reports go, as mailto: addresses, comma separated. | your entry |
sp |
Policy for existing subdomains. Without it, subdomains follow p. | left out |
np |
Policy for subdomains that do not exist at all. New in RFC 9989. | reject |
adkim |
DKIM alignment: r (relaxed, subdomains count) or s (strict, exact match). | r |
aspf |
SPF alignment, same values. | r |
t |
Test mode: t=y applies the policy one level weaker. New in RFC 9989. | off |
ruf |
Where failure reports go. Optional, see below. | left out |
fo |
When failure reports are generated: 0, 1, d or s. | only with ruf |
np closes a gap attackers liked: mail from invented subdomains such as billing.example.com, which never existed and so had no policy of its own. Nobody sends legitimate mail from a name that does not exist, so np=reject is safe from the first day, even while p is still none. t=y is the new test switch. psd also arrived, but it is meant for operators of public suffixes, not for ordinary domains.
pct is gone. It was meant to apply the policy to a share of the mail and was implemented so differently by receivers that nobody could predict the result; t=y replaces it. rf and ri were removed as well. Records that still carry them keep working, because receivers ignore tags they do not know, but they no longer do anything. When you import such a record, the generator says which tags it dropped and why.
Reports sent to the ruf address can contain addresses, subject lines and parts of real messages. That makes them personal data under the GDPR, and most large mailbox providers do not send them at all. The generator leaves ruf empty by default and the checker on this site no longer recommends it. Aggregate reports under rua contain only counts per sending server and are what you actually need.
We read the DMARC records of the 1,000 highest-ranked .de domains in the Tranco list (list 467YX) on 19 October 2026.
| Finding | Domains |
|---|---|
| No DMARC record | 214 |
p=none, so no protection |
333 |
p=quarantine |
214 |
p=reject |
238 |
| DMARC without a report address | 148 of 786 |
Still carrying the removed pct tag |
250 of 786 |
Using the new np tag |
4 of 786 |
| Two DMARC records at once | 1 |
547 of 1,000 domains either have no DMARC at all or stop at p=none, which leaves their From address open to anyone. 148 publish a policy but no report address, so they cannot know when it would be safe to tighten it. And only four use np, the cheapest protection RFC 9989 offers.
quarantine asks the receiver to treat failing mail as suspicious, which in practice means the spam folder. A legitimate message that fails because of a forgotten sender can still be found there. reject asks the receiver to refuse the message during delivery; the sender gets a bounce, the recipient never sees it.
Quarantine is the safe intermediate step, reject the end state. Large mailbox providers have required DMARC from bulk senders since 2024, and a policy of reject is the clearest signal to them that mail in your name is authenticated. Stay at quarantine only for as long as the reports still show legitimate sources you have not fixed.
DMARC passes when SPF or DKIM passes for a domain that matches the From domain. It can only be as good as those two. Before you leave p=none, every service that sends with your domain should either be in the SPF record with matching envelope domain, or sign with a DKIM key for your domain. DKIM is the more robust of the two, because a signature survives forwarding and SPF does not.
Once DMARC is at quarantine or reject, the domain also qualifies for BIMI, the record that puts your logo next to your messages.
Aggregate reports arrive as zipped XML files, usually once a day from every large mailbox provider that received mail with your domain. Each file lists, per sending IP address, how many messages came from it, whether SPF and DKIM passed, and whether the domains they passed for were aligned with your From domain.
Three questions answer almost everything:
The XML is not meant for reading by hand. A report mailbox at a DMARC service or a self-hosted parser such as parsedmarc turns it into a table. If the mailbox is on a domain other than your own, publish the authorisation record the generator writes, or the reports never arrive.
Without sp, every subdomain inherits the policy of the main domain. That is what most domains want. Set sp only when a subdomain needs a different policy, typically a weaker one for a subdomain whose senders you have not fixed yet: p=reject; sp=quarantine.
np is different: it applies to subdomains that do not exist in DNS at all. A forged service.example.com that was never created gets the np policy, a real newsletter.example.com gets p or sp. Because a non-existent name cannot send legitimate mail, the generator sets np=reject from the start, even when the main policy is still none.
A subdomain can also publish its own _dmarc record, which then takes precedence over sp of the parent domain.
v=DMARC1; p=none; np=reject; rua=mailto: plus an address you read. That collects reports without changing delivery, and blocks mail from subdomains that do not exist. Move on to quarantine as soon as the reports show that your own services pass SPF or DKIM.
As a TXT record on the name _dmarc in front of your domain, so _dmarc.example.com. In most DNS panels you enter _dmarc as name and the panel adds the domain. A DMARC record on the domain itself is never read by any receiver.
No. The record is built in the browser. “Load published record” reads the public record at _dmarc of the domain through our resolver, and “Check” sends the record you built to the same validator the Email Security Check uses. Neither stores it.
With quarantine, receivers deliver failing mail to the spam folder; with reject, they refuse it during delivery and the sender gets a bounce. Quarantine is the safer step on the way, reject the protection you want in the end.
You can publish DMARC at p=none immediately, its reports are the fastest way to find out who sends for you. Before quarantine or reject, though, every legitimate sender needs SPF or DKIM aligned with your domain, otherwise your own mail lands in spam or is refused.
RFC 9989 removed it. Receivers applied a percentage so differently that the result was unpredictable. Use t=y while testing a stricter policy and remove it when the reports are clean. Old records with pct keep working; the tag is simply ignored by receivers that follow the new standard.
Usually one of three reasons: the record has no rua tag, the address is on another domain that has not published the authorisation record, or the record sits on the wrong name. The generator writes the authorisation record for external addresses, and “Load published record” shows where your record really is.
The record is assembled in the browser following RFC 9989: tags that the standard removed are never written, np and t are offered, and failure reports are opt-in. The rollout plan is plain date arithmetic from the start date you enter; it cannot see your reports, so the dates are a proposal, not a promise.
“Load published record” queries every TXT record at _dmarc of the domain and runs the validator of the Email Security Check, which scores the policy, the report address and the alignment settings. “Check” runs the same validator on the record you built, without any DNS query. Report addresses are checked for form, never contacted, and the authorisation record for an external address is generated but not looked up.
DMARC itself cannot tell you which of your senders fail. Only the aggregate reports can, and reading them is the real work of a DMARC rollout.