Build a DMARC record with a safe rollout path from monitoring to enforcement, and check the policy a domain publishes today.

Build a policy on the left with a rollout path from monitoring to enforcement, or switch to the checker to read the DMARC record a domain publishes, tag by tag.

Policy

What receivers should do with mail that claims to be from your domain but fails both SPF and DKIM alignment.

Leave on inherit unless subdomains need a different rule.
Below 100 the rest falls back to the weaker policy. Useful when ramping up.
Reporting

Aggregate reports are the whole point of starting with DMARC: they show you every source sending as your domain.

Daily XML summaries. If this address is on another domain, that domain must publish an authorization record.
Per-message failure copies. Optional — most receivers no longer send them.
Alignment

How closely the SPF or DKIM domain must match the visible From domain. Relaxed suits most setups.

Your DMARC record
Record type
TXT
Name / host
_dmarc
TTL
3600
Recommended rollout

Never jump straight to reject: you will block your own newsletters, invoices and helpdesk. Move one step at a time, reading your reports between each.

  1. Weeks 1–4: watch p=none; pct=100 Publish with monitoring only and read the aggregate reports. Find every legitimate sender and get SPF or DKIM aligned for each.
  2. Weeks 5–6: quarantine a quarter p=quarantine; pct=25 Move to quarantine on a fraction of mail. Watch for complaints and for anything legitimate landing in spam.
  3. Weeks 7–8: quarantine everything p=quarantine; pct=100 Raise it to all mail. Reports should now show failures only from sources you do not recognise.
  4. Week 9 onwards: reject p=reject; pct=100 Switch to full enforcement, and keep reading the reports — new senders appear whenever a team signs up for a new tool.
Published record
Record tags explained
TagValueWhat it means
External report destinations
Destination domainAuthorization recordStatus
What we found

About DMARC Record Generator & Checker

The DMARC Record Generator & Checker builds the `_dmarc` TXT record that tells receivers what to do when mail claiming to come from your domain fails both SPF and DKIM alignment — and, just as importantly, where to send the reports that show you who is sending as you. Since February 2024, Gmail and Yahoo have required a DMARC record from anyone sending bulk mail to their users.

The generator covers the policy, the subdomain policy, the percentage, the report addresses, the alignment modes, the failure options and the reporting interval, and lays out the rollout most domains should follow: monitor first, then quarantine a fraction, then quarantine everything, then reject. Jumping straight to reject is how organisations block their own invoices, newsletters and helpdesk replies.

The checker reads the record a domain publishes, explains every tag in plain language and validates it against RFC 7489. It reports a missing record, several records (which receivers treat as no policy at all), a version tag out of place, malformed or unknown tags, a `p=none` that has been sitting there for months, a `pct` below 100, and — a subtle one that silently loses your reports — a `rua` address on another domain that has not published the external destination authorization record RFC 7489 §7.1 requires. It also follows the organizational-domain fallback, so checking a subdomain shows the policy that actually applies to it.

How to use DMARC Record Generator & Checker

  1. Start on the Generator tab with the policy set to monitor only, and enter an address for aggregate reports.
  2. Leave alignment on relaxed unless you know a sender needs strict matching, and leave pct at 100.
  3. Publish the record as a TXT record named _dmarc on your domain.
  4. Read the aggregate reports for a few weeks and get SPF or DKIM aligned for every legitimate sender they reveal.
  5. Move to quarantine, then to reject, checking the reports between each step.
  6. Use the Checker tab at each stage to confirm the record parses and that your report destinations are authorized.

Frequently asked questions

Nothing is blocked: it only asks receivers for reports. It is the right first step, because those reports show you every source sending as your domain — but a record left at p=none forever gives you no protection against spoofing.

Yes. DMARC works by checking that a message passes SPF or DKIM and that the passing domain aligns with the visible From address. Publish and verify SPF and DKIM first, then add DMARC in monitoring mode.

Most often because the rua address is on a different domain from the one publishing the record. RFC 7489 requires that domain to publish a TXT record at yourdomain._report._dmarc.theirdomain containing v=DMARC1. Without it, receivers silently drop your reports. The checker tests this for you.

Relaxed lets any subdomain of your organizational domain count as aligned — so a bounce domain like mail.example.com aligns with example.com. Strict requires an exact match. Relaxed suits almost every setup.

Without sp, subdomains inherit the main policy, which is usually what you want. Spoofers like unused subdomains, so if you set anything, make it stricter rather than weaker — and consider np=reject for subdomains that do not exist at all.

Around four weeks at monitoring, then two weeks at each quarantine step, is a common pace. What matters is not the calendar but the reports: move on only when every failure you see comes from a source you do not recognise.


Popular searches
dmarc record generator dmarc checker dmarc record check dmarc lookup dmarc validator generate dmarc record dmarc policy reject dmarc p=none meaning dmarc rua report address setup dmarc for domain
Need help?
Found an issue with this tool? Let our team know.
Report an issue

Add this free tool to your own website — copy and paste the code below.