Domain has no DMARC record

What it is

Your domain has no _dmarc.example.cz DNS record of type TXT. DMARC tells receiving mail servers (Gmail, Seznam, Outlook) what to do when they get a message that claims to be from example.cz but fails both the SPF and DKIM checks.

Without DMARC, the answer is “decide for yourself” — and in practice the big providers deliver the spoofed message.

Why it’s a problem

Anyone can send email in your domain’s name. Specifically:

How to fix it

Roll DMARC out in stages. Jumping straight to an enforcing policy before you have read your reports will hurt your legitimate mail.

Phase 1 (1–2 weeks) — monitoring

Create a DNS TXT record:

Name:  _dmarc.example.cz
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.cz; fo=1

p=none expresses no preference about what receivers should do with failing mail (RFC 9989, section 4.7) — each of them keeps filtering as it sees fit. What this record actually asks for is the reports: rua is the email address where providers will send you aggregate reports.

Phase 2 (after 1–2 weeks) — quarantine

From the reports you can see all the legitimate servers sending in your name (Mailchimp, Mailgun, Microsoft 365, your own server). Add them to SPF and DKIM. Then escalate:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.cz

p=quarantine is an enforcing policy in its own right (RFC 9989, section 3.2.9) — mail that fails DMARC lands in spam instead of the inbox.

Do not add pct=10 here. Older guides use pct= to ramp a policy up over a percentage of failing mail, but the pct tag was removed from DMARC in RFC 9989 (May 2026) and a conformant receiver ignores it. At any receiver that has moved to RFC 9989, p=quarantine; pct=10 is therefore applied to 100 % of failing mail, not 10 % — and a pct=0 “safe test” is full enforcement there. Since you do not control which receivers have already moved, pct cannot be relied on to stage a rollout at all.

For a test run, RFC 9989 section 4.7 defines the t= tag instead. At a receiver that has moved to RFC 9989, t=y asks for one level below the published policy while reports keep arriving: p=quarantine; t=y is handled as p=none, and p=reject; t=y as p=quarantine.

t= and pct are not the same thing, though: pct is gone from the protocol and receivers that follow RFC 9989 ignore it, while t= is its valid replacement — it just only works at receivers that have moved to RFC 9989. The tag is new in RFC 9989 (Appendix A.6), and section 4.8 requires a receiver to ignore tags it does not know: one that has not moved to RFC 9989 applies your published policy in full — there p=quarantine; t=y quarantines everything that fails DMARC. Publish t= only on top of a policy whose full effect you are prepared to accept; p=none stays the only phase that enforces nothing anywhere. Drop the tag (or set t=n) when you are done testing.

Phase 3 (optional) — reject

v=DMARC1; p=reject; rua=mailto:dmarc@example.cz

With p=reject the receiver refuses the spoofed message outright. RFC 9989 section 7.4 attaches two conditions to it: a domain publishing p=reject must apply valid DKIM signatures to its mail and must not rely on SPF alone (SPF breaks when mail is forwarded), and domains that host users who might post to Internet mailing lists should not publish p=reject at all.

If either of those applies to you, staying at p=quarantine is a legitimate end state, not an unfinished rollout.

Verification

After each phase, verify the record with a fresh scan at vulscan.app — the DMARC check (together with SPF) is part of the free scan. The aggregate reports arrive at the rua address as XML attachments; to get oriented, it is enough to watch which servers are sending mail that fails DMARC.

References