DMARC Record Generator
Free DMARC record generator and checker for RFC 9989. Build or paste a record, see every tag explained, and get the records external report services need.
Updated
One per line. The mailto: prefix is optional.
A record, quoted strings, dig output, or a zone file line.
The domain in your From addresses.
Options
Failure reports
One per line.
Alignment
To check the records a domain publishes now, use the email security checker.
Pick a policy to build a record.
What Is a DMARC Record Generator?
The DMARC record generator builds a DMARC policy record for the _dmarc TXT name of a domain and checks any record you paste. It follows RFC 9989, the May 2026 standard that replaced RFC 7489: it writes the new t, np and psd tags, never writes the removed pct, rf and ri tags, and explains what receivers do with each tag in a pasted record, including invalid and historic values. When reports go to another domain, it shows the authorization record that domain must publish.
How to Use the DMARC Record Generator
- Enter your domain and pick a policy. Start with none and an aggregate report address if you do not yet know every service that sends your mail.
- Add report addresses, and set subdomain policies, alignment and testing if you need them.
- Copy the TXT value and publish it at the Host _dmarc of your domain. Publish any authorization record shown for an external report address, or ask your report service to.
- To check an existing record, switch to Check a record and paste it.
How It Works
A DMARC policy record is a TXT record at the name _dmarc followed by the domain in the From address. It is a list of tags separated by semicolons, with v=DMARC1 first. Receivers check that the From domain aligns with a domain that passed SPF or DKIM, and apply the record's policy to mail that does not: none, quarantine or reject. If a domain publishes more than one DMARC record, receivers discard all of them.
RFC 9989 replaced RFC 7489 in May 2026. It removed the pct, rf and ri tags and the report size limit in report addresses, and added t (test mode), np (policy for subdomains that do not exist) and psd. It also replaced the Public Suffix List with a DNS Tree Walk for finding the Organizational Domain. Receivers that still follow RFC 7489 ignore tags they do not know, so they ignore t, np and psd.
DMARC uses the DKIM tag-list syntax. Tag names are case-sensitive, and a tag that appears twice makes the whole record invalid. Unknown tags are ignored. An invalid value is replaced by the tag's default, except for the policy tags: if p, sp or np is invalid, receivers act as if the record said p=none when it has a valid rua address, and apply no DMARC processing otherwise. A record with no p is treated as p=none.
With t=y, receivers apply the policy one level lower: quarantine as none, and reject as quarantine. t has no effect on a policy of none.
When a report address is on a domain outside the record's Organizational Domain, receivers send reports there only if that domain publishes a TXT record at the name of the record's domain, then _report._dmarc, then the report domain, containing v=DMARC1. Without it, receivers ignore the address. The generator shows that record for each external report domain.
DMARC Tags in RFC 9989
| Tag | Values | When absent | Meaning |
|---|---|---|---|
| v | DMARC1 | Required, and must be first | DMARC version 1. It must be the first tag, written exactly as DMARC1. |
| p | none, quarantine, reject | Treated as none | Policy for failing mail that uses this domain, and its subdomains unless sp or np says otherwise. |
| sp | none, quarantine, reject | The p policy | Policy for failing mail from existing subdomains. |
| np | none, quarantine, reject | The sp policy, or p | Policy for failing mail from subdomains that do not exist. |
| t | y, n | n | Test mode. |
| adkim | r, s | r | DKIM alignment. |
| aspf | r, s | r | SPF alignment. |
| psd | y, n, u | u | Public suffix flag. |
| rua | Report URIs | No aggregate reports | Aggregate reports go to. |
| ruf | Report URIs | No failure reports | Failure reports go to. |
| fo | 0 or 1, with d and s | 0 | When to send failure reports. |
Standards
Scope
What It Checks
- +Builds a DMARC record with p, sp, np, t, adkim, aspf, psd, rua, ruf and fo, in the tag order RFC 9989 shows, with v first.
- +Checks a pasted record and explains every tag, the defaults that apply, and the policy receivers will use.
- +Flags the historic pct, rf and ri tags, duplicate tags, tag names in the wrong case, invalid values, and unknown tags with a likely correction.
- +Applies the RFC 9989 rules for a missing or invalid policy, and for t=y, which lowers the applied policy by one level.
- +Shows the authorization record a report address on another domain must publish, as RFC 9990 describes.
- +Reads records copied from dig, a zone file, or a DNS dashboard, and reports more than one DMARC record.
What It Does Not Check
- -It does not look up DNS, so it cannot see the record a domain publishes now or whether a report service has published its authorization record.
- -It compares report domains with the domain by shared parent name, not with the RFC 9989 DNS Tree Walk, so names under a shared suffix such as co.uk can be judged the same organization.
- -It does not check SPF or DKIM, which DMARC needs to pass.
- -It does not read or send DMARC reports.
Defensive Use
DMARC lets the owner of a domain tell receivers how to handle mail that uses the domain in the From address but fails authentication, and send reports on who sends mail as the domain. RFC 9989 has domain owners start with p=none and a rua address, read the aggregate reports, fix legitimate mail streams, and then decide whether to move to enforcement. The UK National Cyber Security Centre advises a DMARC policy of reject on domains that send no mail.
Frequently Asked Questions
What is a DMARC Record Generator?→
The DMARC record generator builds a DMARC policy record for the _dmarc TXT name of a domain and checks any record you paste. It follows RFC 9989, the May 2026 standard that replaced RFC 7489: it writes the new t, np and psd tags, never writes the removed pct, rf and ri tags, and explains what receivers do with each tag in a pasted record, including invalid and historic values. When reports go to another domain, it shows the authorization record that domain must publish.
What is the DMARC Record Generator used for?→
Publishing a first DMARC record in monitoring mode, moving a domain from p=none to quarantine or reject, locking down a domain that sends no mail, and checking an existing record for tags that RFC 9989 removed.
Is my data sent anywhere?→
No. The DMARC Record Generator runs in your browser. What you enter stays on this page and is not sent to ImmunitySec or anyone else.
How is the DMARC Record Generator used defensively?→
DMARC lets the owner of a domain tell receivers how to handle mail that uses the domain in the From address but fails authentication, and send reports on who sends mail as the domain. RFC 9989 has domain owners start with p=none and a rua address, read the aggregate reports, fix legitimate mail streams, and then decide whether to move to enforcement. The UK National Cyber Security Centre advises a DMARC policy of reject on domains that send no mail.
Which DMARC policy should I start with?→
RFC 9989 says domain owners usually start with p=none and a rua address, which it calls monitoring mode. The aggregate reports show the services that send mail as the domain. Once every legitimate source passes SPF or DKIM with alignment, the owner decides whether to move to quarantine or reject. RFC 9989 also warns that p=reject on domains whose users send everyday mail is likely to cause problems with mailing lists.
What changed in RFC 9989?→
RFC 9989, published in May 2026, obsoletes RFC 7489 and RFC 9091. It removes the pct, rf and ri tags and the report size limit in report addresses, adds the t, np and psd tags, and finds the Organizational Domain with a DNS Tree Walk instead of the Public Suffix List. Aggregate and failure reporting moved to RFC 9990 and RFC 9991.
What happened to the pct tag?→
RFC 9989 removed it. Receivers usually applied pct accurately only for 0 and 100, the default. The value 0 had become a signal for special handling such as rewriting the From header, so RFC 9989 keeps that use as t=y.
What is the difference between rua and ruf?→
rua lists the addresses for aggregate reports, summaries of the mail receivers saw for the domain. Without rua, receivers must not send aggregate reports. ruf lists addresses for failure reports about single messages that fail DMARC. Most receivers refuse to send failure reports because they can contain message content.
Do I need SPF and DKIM before DMARC?→
Yes. A message passes DMARC when SPF or DKIM passes for a domain that aligns with the From domain. RFC 9989 asks domain owners to send mail with at least one, and preferably two, aligned authenticated identifiers.
What is the difference between relaxed and strict alignment?→
With relaxed alignment, the default, the authenticated domain and the From domain need the same Organizational Domain, so mail.example.com aligns with example.com. With strict alignment they must be identical. adkim sets the mode for DKIM and aspf for SPF.
My reports go to a service on another domain. Do I need anything else?→
The report service must publish a TXT record that authorizes reports for your domain, at your domain followed by _report._dmarc and its own domain, containing v=DMARC1. Receivers ignore a report address on another domain when that record is missing.
Can a domain have more than one DMARC record?→
No. When receivers find more than one DMARC record at a name, they discard all of them, and the domain has no DMARC policy there.
Does Gmail require DMARC?→
Google requires SPF, DKIM and DMARC for bulk senders to Gmail, and says the DMARC enforcement policy can be set to none.
Tag definitions, defaults and receiver behavior come from RFC 9989, report authorization from RFC 9990, and tag-list syntax from RFC 6376. RFC 9989 obsoletes RFC 7489.