DMARC Record Generator
Build a correct DMARC record in seconds. Pick your policy, add your reporting address, and copy the exact TXT record to publish in DNS. Free, no signup.
Used to show the exact host name to publish. The record itself doesn't contain it.
Start at none to observe, then tighten once reports look clean.
Where daily XML summaries are sent. Comma-separate multiple addresses.
Advanced options (sp, alignment, ruf)
Subdomains inherit p unless you set this. Attackers love unused subdomains: reject is a strong choice once you're at enforcement.
Relaxed allows subdomain matches (mail.yourdomain.com signs for yourdomain.com). Strict requires an exact match. Most domains should stay relaxed.
Same idea for the SPF (Return-Path) domain.
Per-message failure samples. Rarely sent by large providers; contains message data.
Your DMARC record
Publish this as a TXT record in your DNS.
_dmarc.yourdomain.comv=DMARC1; p=none;Click the record to select all of it.
Record type: TXT · TTL: your provider’s default (e.g. 3600) is fine.
After you publish
- Add the TXT record at your DNS host and allow up to an hour for propagation.
- Verify it with the free DMARC checker.
- Watch your aggregate reports, fix SPF and DKIM for every legitimate sender, then step up to quarantine and reject.
No rua address: this record will collect no reports
Reports are the whole point of starting DMARC. Palisade gives you a monitored address, reads every report, and publishes the record for you.
Get my reports readWhat is a DMARC record generator?
A DMARC record generator builds that record for you from plain-language choices, so you never hand-write the syntax. A DMARC record is a single TXT entry in your DNS that tells receiving mail servers what to do with messages that fail SPF and DKIM alignment, and where to send reports about them. The syntax is simple but unforgiving: a misplaced tag or a missing mailto: prefix and receivers ignore the record entirely. This generator assembles the record from plain-language choices, flags the mistakes we see most often (no reporting address, a reporting address on another domain, an invalid mailbox), and gives you the exact host and value to paste into your DNS provider. Once it’s live, verify it with the DMARC checker and read the full guide to setting DMARC up.
What the generator does, and warns you about
| Note | What it means | What to do |
|---|---|---|
| No rua address set | The record will publish, but no receiver will send you aggregate reports, so you get no evidence about who sends as your domain. | Add a reporting address before you publish. Reports are the input to every later policy decision. |
| Ignored invalid address | An address that isn't a valid mailbox is dropped from the record rather than published in a broken form. | Fix the typo and re-add it. A malformed reporting address in a live record can invalidate the tag. |
| p=none selected | Monitoring mode: receivers report on failures but still deliver everything, including spoofed mail. | Correct as a starting point. Move to quarantine, then reject, once reports show legitimate mail passing. |
| ruf (forensic) address added | Forensic reports carry message-level data, and most large receivers do not send them at all. | Add it only with a specific investigative need and a mailbox prepared for sensitive content. |
| Reporting address on another domain | Sending reports off-domain requires the receiving domain to publish an authorization record, or receivers will refuse to send them. | Publish the external reporting authorization record on the destination domain, or use an address on your own. |
| No pct, rf, or ri tag offered | RFC 9989 retired those tags. The generator does not emit them, so records it produces stay current. | If an older guide tells you to add pct, ignore it, stage enforcement by moving the policy instead. |
What this generator can and can't do
It assembles a syntactically correct record from your choices and flags the mistakes that most often make a published record useless. Everything happens in your browser. It performs no lookup, so it does not know what your domain currently publishes, and it cannot publish anything for you.
It also cannot tell you whether your mail is ready for a stricter policy. That answer only comes from aggregate reports, which is why the safe sequence is publish at p=none, read what comes back, and tighten once every legitimate sender aligns. Confirm the published record with the DMARC checker once it is live.
Related checks and terms
p=nonep=quarantinep=rejectspadkim / aspfDMARC software that does the work
Palisade organizes DMARC report evidence into prioritized sender and alignment work, helping operators review changes and move domains toward enforcement from one console.
1 domain free up to 1,000 emails/month
Email authentication knowledge base
Every tag you can put in a DMARC record, explained.
- vVersion
- The Version tag is essential in a DMARC record and must strictly be set to ‘DMARC1’. If this value is not correctly specified or if the tag is absent, the DMARC record will not be considered valid and will be disregarded.
- pDMARC policy
- The DMARC policy setting is crucial and accepts three possible values: ‘none’, ‘quarantine’, or ‘reject’. By default, it is set to ‘none’, which means it doesn’t actively intervene with emails that fail authentication. This setting primarily serves to gather DMARC reports, aiding in understanding the existing email traffic and its authentication status. On the other hand, the ‘quarantine’ option flags unauthenticated emails as dubious, and ‘reject’ outright prevents their delivery.
- ruaAggregate report destination
- The destination for sending aggregate reports is specified using a ‘mailto:’ URI, which Email Service Providers (ESPs) utilize to dispatch failure reports. While this tag is not mandatory, omitting it means you will not receive any reports.
- rufForensic report destination
- The destination for Forensic (Failure) report transmission is designated by a ‘mailto:’ URI, which is employed by Email Service Providers (ESPs) for the delivery of failure reports. Although this tag is not obligatory, failing to include it will result in not receiving any reports.
- spSubdomain policy
- The policy for subdomains defaults to inheriting the main domain’s policy tag (p=), as previously described, unless explicitly stated otherwise. Similar to the domain policy, the permissible values for subdomains are ‘none’, ‘quarantine’, or ‘reject’. However, this option is not commonly employed in current practices.
- adkimDKIM alignment
- The alignment of the DKIM signature, indicated by this tag, refers to the congruence between the DKIM domain and the originating domain in the ‘Header From’. The acceptable values for this tag are ‘r’ for relaxed and ‘s’ for strict. The default setting, ‘r’, permits a partial match between these domains, whereas the ‘s’ setting demands an exact match of the domains.
- aspfSPF alignment
- This tag pertains to the SPF alignment, which concerns the compatibility between the SPF domain (the sender) and the domain in the ‘Header From’. It allows two settings: ‘r’ for relaxed and ‘s’ for strict. By default, it is set to ‘r’, which tolerates a partial match between the domains. In contrast, the ‘s’ setting necessitates an exact correspondence of the domains.
- foForensic reporting options
- The options for forensic reporting include ‘0’, ‘1’, ‘d’, and ‘s’. The default setting is ‘0’, which triggers a forensic report only when both SPF and DKIM alignments do not pass. Use ‘1’ if the outcome of either SPF or DKIM is anything other than a pass. The option ‘d’ is selected to generate a report specifically for DKIM validation failures, and ‘s’ is used for SPF-related issues. To actually receive these forensic reports, it’s necessary to specify the ‘ruf’ tag.
- rfFailure report format
- The format for failure report generation can be set to either ‘afrf’ or ‘iodef’, as these are the two permissible options.
- pctPercentage (historic)
- The legacy Percentage tag asked receivers to apply a quarantine or reject policy to only part of the mail that failed DMARC. RFC 9989 removed pct because receivers implemented partial enforcement inconsistently. New records should omit it and stage rollout with aggregate reports, whole-policy changes, and low-volume subdomains.
- riReporting interval
- The Reporting interval specifies how often XML reports are received, measured in seconds. The standard setting is 86400 seconds, which equates to daily reporting. However, it’s important to note that despite the specified interval, Internet Service Providers (ISPs) typically send these reports on their own schedules, which in most cases, is also once a day.