DMARC Record Generator

DMARC connects the From address people see to the checks that happen behind it. A message passes DMARC when SPF or DKIM passes for a domain that matches the domain in From (“alignment”). Your DMARC record tells receivers two things: what to do with mail that fails, and where to send reports about all mail that uses your domain.

The record is a TXT record at _dmarc. plus your domain, for example:

v=DMARC1; p=none; rua=mailto:[email protected]

This DMARC record generator writes it from a few choices. The policy is picked as a stage, because that is how DMARC is safely rolled out:

1. Monitor (p=none): receivers change nothing and send you daily reports. Stay here until the reports show that all your own mail passes.
2. Test quarantine (p=quarantine; t=y; pct=0): the policy is published, but receivers are asked to treat failing mail as if it were still none while you watch the reports.
3. Quarantine (p=quarantine): failing mail goes to spam.
4. Reject (p=reject): failing mail is refused. This gives the strongest protection against others sending mail as your domain, at receivers that check DMARC.

The generator follows RFC 9989, published in May 2026, which replaced the original DMARC specification (RFC 7489). Compared with RFC 7489 it has no pct, rf or ri tags, and it has t (test mode), np and psd. The one exception is test mode, where we add pct=0 for receivers that still follow the old rules.

The record is checked by the same rules a receiver applies when it reads it: tag order, valid values, report addresses written as mailto: links with the characters DMARC requires encoded, and tags that would have no effect. With JavaScript on, nothing you type leaves your browser. Without JavaScript, the button sends the form to our server once, the record is built there and the page comes back with it; we do not store what you typed (privacy policy).

The panel above the record is the verdict of the generated record: a colored icon and a short label. Pass: ready to publish. Warning: it works, but something needs your attention, most often a missing report address. Fail: no valid record can be built from this input, so none is shown. Notes marked Pass explain what the record will do.

Monitoring or enforcement

With p=none the result reminds you that this is monitoring mode: receivers deliver mail as before and only report. With p=quarantine or p=reject it reminds you to check the reports first. Mail that you send through a service that does not sign with your domain, or mail forwarded by mailing lists, can fail DMARC even though it is legitimate. A policy value other than none, quarantine or reject is refused.

Test mode: t=y and pct=0

In the Test quarantine stage the record carries t=y. Under RFC 9989 it asks receivers to apply one level less than the policy: quarantine is treated as none, and reject as quarantine (§4.7). Test mode changes nothing while every policy is none, so it is left out then, with a warning.

Receivers that still follow RFC 7489 do not know t and must ignore unknown tags, but they do read the older pct tag. With pct=0 they apply the next weaker policy to all failing mail, which is the same thing t=y asks for. That is why the test record has both. By the text of both standards, the two tags lead to the same behavior (pct=0 in RFC 7489 §6.6.4, t=y in RFC 9989 §4.7); we have not measured it on live receivers. Remove t=y and pct=0 together when you move on.

There is no separate percentage setting: RFC 9989 removed pct, and a record with, say, pct=50 is read differently by old and new receivers.

Report addresses

• No aggregate report address (rua) is a warning. Without it receivers send no reports, and with p=none the record then does nothing useful at all.
• Addresses must be email addresses. You can type [email protected] or mailto:[email protected]; the record always contains the mailto: form. Other schemes such as https: are refused, because receivers are only required to send reports by email. An address that is not a valid email address is refused too.
• Failure reports (ruf) are per-message reports. Not every receiver sends them; Microsoft 365, for example, says it does not send them at all.
• Failure reporting options (fo) only matter with a failure report address, so without one they are left out with a warning. 0 and 1 cannot be combined; the other options are d and s.

Reports to an address on another domain

If a report address is on a domain outside yours, for example a DMARC report service, receivers send reports there only if that domain agrees to receive them. It does so with a TXT record v=DMARC1; at yourdomain.com._report._dmarc. plus its own domain (RFC 9990 §4). Report services usually publish it for every customer; the result shows the exact record so you can ask. Your own other domains need this record too: receivers compare organizational domains, not owners, so reports for example.com sent to an address at example.net need the record at example.com._report._dmarc.example.net. The generator works offline and cannot look up organizational domains, so it also warns about a sibling subdomain, such as reports.example.com for shop.example.com. That one needs no record if example.com publishes its own DMARC record (and this record has no psd=n): receivers then take example.com as the organizational domain of both names. If example.com has no DMARC record, receivers that follow RFC 9989 treat the two names as separate organizational domains, and the record is needed. If the name of that record would be longer than DNS allows, the reports cannot be authorized at all.

Alignment: relaxed or strict

adkim and aspf say how closely the DKIM and SPF domains must match the From domain. Relaxed (r, the default) accepts a subdomain, such as a DKIM signature by mail.example.com for mail from example.com. Strict (s) requires the exact same domain. Leave both unset unless you have a reason. Other values are refused.

Subdomain policies: sp and np

sp sets the policy for subdomains that exist, np for subdomains that do not exist, which attackers like to invent. Unset, sp follows p and np follows sp. For example, p=quarantine; np=reject sends failing mail from your real domain to spam and refuses mail from made-up subdomains outright.

The psd tag

psd=y is only for operators of public suffixes, such as a country-code registry, and shows a warning. psd=n states that this domain is an organization's own domain. Most domains leave the tag out. Values other than y, n and u are refused.

The domain name

Enter the domain from the From address, such as example.com. A domain so long that _dmarc. plus the domain would exceed the 253 characters a DNS name can have is refused.

Size limits

The generator takes at most 1,000 report addresses and refuses a record too big to fit in a DNS answer. Real records need one or two addresses.

1. Set up SPF and DKIM first. DMARC passes only when one of them passes for your domain. Google advises waiting 48 hours after setting them up before adding DMARC.
2. Create a mailbox or group for reports, such as [email protected], or use a report service's address.
3. Publish the Monitor record as a TXT record with the host _dmarc at the company that runs your domain's DNS (the one its NS records point to, often where you bought the domain). If a record starting with v=DMARC1 already exists there, replace it: with two DMARC records receivers ignore both.
4. Read the reports for a few weeks. Find every service that sends as you and make sure it passes SPF or DKIM with your domain.
5. Move one stage at a time: Test quarantine, Quarantine, Reject. Come back here and generate the next record each time.

Google Workspace

Google publishes no DMARC record for you; you add it at your DNS provider at _dmarc.example.com. Google recommends starting with p=none, moving to quarantine or reject over time, and receiving reports in a group or a dedicated mailbox. Turn on DKIM signing first, in the Google Admin console under Apps > Google Workspace > Gmail > Authenticate email.

Microsoft 365

For a custom domain, Microsoft 365 has no setting for DMARC: create the TXT record with the host name _dmarc at your DNS provider. Enable DKIM signing for the domain in the Microsoft Defender portal first. For the onmicrosoft.com domain Microsoft gives you, add the record in the Microsoft 365 admin center under Settings > Domains, on the domain's DNS records tab: Add record, type TXT, name _dmarc. Microsoft's examples still include pct=100; that tag was removed in RFC 9989 and 100 was its default, so the generator leaves it out.

Zoho Mail

Publish the record at your DNS provider as above. For DMARC to pass on DKIM, set up DKIM for the domain in the Zoho Mail Admin Console under Domains, on the Email Configuration tab.

SendGrid, Mailgun and Amazon SES

Sending services do not publish your DMARC record; they make their mail align with it. Set up domain authentication in SendGrid, DKIM for your domain in Mailgun, and Easy DKIM (optionally with a custom MAIL FROM subdomain) in Amazon SES, so that their mail is signed with your domain. Without that, mail from these services fails DMARC once you move past Monitor.

Cloudflare

On the DNS Records page select Add record, type TXT, Name _dmarc, paste the record into Content and select Save.

GoDaddy

In the domain's DNS settings select Add New Record, type TXT, Name _dmarc, paste the record into Value and select Save.

Namecheap

On the Advanced DNS tab select Add New Record, choose TXT Record, Host _dmarc (without your domain), paste the record into Value and select Save all changes.