Skip to main content

DMARC Record Generator

Build a correct DMARC record for your domain, with the mistakes flagged before you publish.

This tool builds the TXT record you publish at _dmarc.<domain>, following RFC 9989 — the current DMARC standard. Everything runs in your browser; nothing you type is sent to Malware Security or anyone else.

The domain you send mail from. Replace example.com with yours.
New in DMARCbis (RFC 9989): the policy for subdomains that do not exist, which are commonly used in spoofing.
Failure report options (fo)Only relevant when a failure report address (ruf) is set.
One or more mailto: addresses, comma or newline separated.
Optional. Failure reports contain personal data — use with care.
Host
_dmarc.example.com
Value
v=DMARC1; p=quarantine; np=reject; rua=mailto:[email protected]
Why this default

This record starts at p=quarantine with np=reject. Quarantine is a strong posture that still delivers legitimate mail while you review the aggregate reports; RFC 9989 §7.4 warns that domains whose users post to mailing lists should not move straight to p=reject. Non-existent subdomains have no legitimate senders, so rejecting them is safe from day one.

Deployment notes

  • Publish this as a single TXT record. Do not split the value across multiple records.
  • A TTL of 3600 seconds (1 hour) is a common starting point; lower it before changes so they propagate quickly.
  • DNS changes can take up to the record's TTL to propagate. Verify before moving to a stricter policy.
  • Only one DMARC record may exist at _dmarc.<domain>. A second record causes the policy to be ignored.
What DMARCbis changed

RFC 9989 replaced RFC 7489 in May 2026

The current DMARC standard is RFC 9989, which obsoletes RFC 7489 and RFC 9091 and splits reporting into RFC 9990 (aggregate) and RFC 9991 (failure). Two changes matter when you write a record: the pct tag has been removed (it was deprecated in favour of staged rollout at the policy level), and a newnp tag lets you set a distinct policy for subdomains that do not exist. This generator follows RFC 9989 and will never emit pct.

What The Tags Mean

p
The policy applied to mail that fails authentication: monitor (none), quarantine, or reject.
sp
A separate policy for subdomains of your domain. Inherits fromp when omitted.
np
The policy for subdomains that do not exist. New in RFC 9989.
adkim / aspf
How strictly DKIM and SPF must align with your domain: relaxed (r, default) or strict (s).
fo
When to generate a failure report. Only relevant when aruf address is set.
rua / ruf
Where aggregate (rua) and failure (ruf) reports are sent. Reporting to an external domain requires an authorisation record.

Publishing a record is the easy part. Email Posture takes you from monitoring to enforcement and keeps watch over every sending source.

> EXPLORE EMAIL POSTURE_