DMARC record generator
Build a DMARC TXT record with each tag explained, warnings that match the full check, and a safe path from none to reject. Runs in your browser.
Your DMARC record
| Type | TXT |
|---|---|
| Host | _dmarc.example.com |
v=DMARC1; p=noneBefore you publish
- Warning
DMARC_INVALID_REPORT_URIA DMARC report address is not a valid URI, so reports are not delivered.
Recommendation: Write each report address as a mailto: URI, for example mailto:[email protected].
- Info
DMARC_NO_RUAThe DMARC record has no aggregate report address (rua).
Recommendation: Add a rua address that you monitor.
- Info
DMARC_TESTING_MODEThe DMARC policy is in testing mode (t=y).
Recommendation: Remove t=y once the reports show that legitimate mail passes.
- Info
DMARC_POLICY_NONEThe DMARC policy is p=none (monitoring only).
Recommendation: Use the aggregate reports to confirm that all legitimate mail passes before considering a stricter policy.
- Info
DMARC_UNSUPPORTED_REPORT_URIA DMARC report address uses a scheme other than mailto.
Recommendation: Use a mailto: address for reports.
- Warning
SPOOF_SUBDOMAINS_UNPROTECTEDThe DMARC policy is enforced for the domain but not for its subdomains.
Recommendation: Add an sp tag that enforces for subdomains, once you know which subdomains send mail.
p=reject without a report address: mail that fails is refused and you never see which senders broke.
Recommendation: Add a rua address before you move to reject, and keep it after.
sp or np is weaker than p, so mail that claims to come from a subdomain gets less protection than mail from the domain itself. The free email security check reports this as subdomains open.
Recommendation: Leave out sp and np, or give them the same policy as p, unless a subdomain still sends mail that fails DMARC.
- Info
t=y has no effect with p=none.
Recommendation: Leave testing mode off.
Failure report options are left out because there is no ruf address.
No warnings. This record is what the full check expects of an enforced domain.
What each tag does
v=DMARC1 | Version. Must be DMARC1 and come first, or receivers ignore the record. |
|---|---|
p=none | Policy none: monitor only. Receivers deliver failing mail as usual and send reports. |
Recommended path
- 1. Monitor with p=none for two to four weeks. Read the reports and fix every legitimate sender that fails.
v=DMARC1; p=none - 2. Move to p=quarantine when the reports show only forged mail failing. Watch for a few weeks more.
v=DMARC1; p=quarantine - 3. Finish with p=reject. Keep reading the reports, since new senders appear over time.
v=DMARC1; p=reject
Run the full email security check DMARC, SPF, DKIM, MX and MTA-STS in one free report.
How it works
DMARC tells receiving mail servers what to do with mail that claims to come from your domain but fails authentication. A message passes DMARC when SPF or DKIM passes and the domain it checked matches the domain in the From header. The record lives in DNS as a TXT record at _dmarc. followed by your domain.
The generator builds that record from the choices in the form. It starts with v=DMARC1 and the policy p, then adds only the tags that differ from their defaults: sp and np when subdomains should be treated differently, adkim and aspf when you want strict alignment, t=y if you turn on testing mode, and the report addresses in rua and ruf. Defaults are left out, because a shorter record is easier to read and has fewer places to go wrong.
The warnings use the same rules as the DMARC check and show the same finding codes, so a record that is clean here is clean in the full check. Each code links to its explanation in the findings reference. The DMARC guide covers alignment, the DNS tree walk and reports in more depth.
The safe path to reject
- Monitor. Publish
p=nonewith aruaaddress. Receivers keep delivering mail as before and send you daily aggregate reports. - Fix senders. The reports list every source that sends as your domain. Add the legitimate ones to SPF or set up DKIM signing for them, until only forged mail fails.
- Quarantine. Move to
p=quarantine. Failing mail goes to the spam folder instead of being lost, so a sender you missed is still recoverable. - Reject. Finish with
p=reject. Keepruain place: new services get added over time, and the reports are how you notice.
Common mistakes
- No report address. Without
ruayou have no idea which senders fail. Withp=rejectthat means legitimate mail is refused and nobody sees why. - A plain email address.
[email protected]is missingmailto:. The policy works, but no reports arrive. The generator adds the scheme, so check records you wrote by hand. - Testing mode left on.
t=ymakes receivers apply the policy one step lower, sop=reject; t=yprotects only as much as quarantine. - Two records. Adding a second DMARC record instead of editing the first makes receivers discard both.
- Strict alignment too early.
adkim=sandaspf=sfail mail that is signed by a subdomain or a provider's bounce domain. Relaxed alignment is right for most domains.
Frequently asked questions
Where do I publish the record?
As a TXT record on the host _dmarc under your domain, so _dmarc.example.com for example.com. Most DNS providers want only _dmarc in the name field and add the domain themselves. Publish exactly one DMARC record: with two or more, receivers ignore both (RFC 9989 section 4.10).
Should I start with p=reject?
Only if you know every service that sends mail as your domain and all of them pass SPF or DKIM in alignment. Most domains have a forgotten sender somewhere: a newsletter tool, a ticket system, an invoice service. Start with p=none and a rua address, read the reports, fix what fails, then move to quarantine and reject.
Why does the address need mailto:?
The rua and ruf tags take URIs, not plain addresses. [email protected] is not a valid URI, so receivers send no reports to it, although the policy still applies. Write rua=mailto:[email protected]. The generator adds mailto: for you when you type a bare address. The full check reports a missing scheme as DMARC_INVALID_REPORT_URI.
Can reports go to another domain?
Yes, but the receiving domain must agree to it. It publishes a TXT record such as example.com._report._dmarc.reports.example.net with the value v=DMARC1. Report services set this up for you. Without it, receivers do not send reports to the external address.
What happened to pct?
RFC 9989 replaced RFC 7489 and made pct historic, so receivers that follow RFC 9989 ignore it. Receivers that still follow RFC 7489 keep using pct and ignore the new t=y tag. The generator leaves pct out and suggests no t=y: roll out with p=none, then p=quarantine, then p=reject, guided by the reports.
Is anything sent to Lookproof?
No. The generator runs only in your browser. Nothing you type leaves the page, and there is no account. To check the record once it is live, run the email security check.