What DMARC policy should I start with?

p=none, every time. It changes nothing about how receivers treat your mail and starts the reports flowing, which is the only way to discover every system that sends as your domain, and there are almost always more than you expect. Read those reports for two to four weeks, fix the legitimate senders that fail, then move to quarantine and finally to reject. Publishing reject first is how organisations block their own invoices and helpdesk mail on day one.

Will the reports this record asks for actually arrive?

Only if the address you chose is allowed to receive them, which is not something the record itself can tell you. When your rua address is on a domain you do not own (a DMARC vendor, an agency, a parent company), RFC 7489 §7.1 requires that domain to publish a record at yourdomain._report._dmarc.theirdomain before any receiver is permitted to send anything. Without it receivers must not send, so the record looks perfect and nothing ever arrives. A duller second cause is an address that is authorised but sits on a domain accepting no mail at all. This generator checks both against live DNS while you type the address, so you find out before you publish rather than after a fortnight of silence.

Where do I publish a DMARC record?

As a TXT record on the _dmarc subdomain, so the full name is _dmarc.yourdomain.com. Most DNS panels want just _dmarc in the host or name field and will append the domain for you, though a few want the whole thing. This trips people up because SPF is published on the root of the domain and DMARC is not: putting a DMARC record on the root does nothing at all, and no error is shown anywhere.

Should I set a subdomain policy when I build the record?

Almost always yes, and it costs nothing. Unlike SPF, DMARC has inheritance: a subdomain with no record of its own is covered by the organizational domain’s policy, so the sp tag lets you set a different policy for every subdomain at once without publishing anything on any of them. That makes sp the cheapest protection available: a subdomain that never sends mail is the easiest part of your estate to spoof, and sp=reject covers all of them even while your main domain is still safely at p=none. Pair it with np=reject, which covers the subdomains that do not exist at all.

Can DMARC reject my own legitimate email?

Yes, and that is the whole reason for the ladder. DMARC is a verdict on SPF and DKIM: mail that passes neither in an aligned way fails DMARC, and at p=reject it is refused outright. A domain whose SPF is missing, broken, or over the ten-lookup limit will fail its own mail the moment enforcement is switched on. This generator reads your SPF record before it offers you reject and warns when the policy is ahead of the domain.

Should I build my record with quarantine or reject?

Neither, on the first record. Start at p=none and read reports for two to four weeks. When you do move, go to quarantine before reject. Quarantine tells receivers to deliver failing mail somewhere the recipient can still find it, which in practice means the spam folder, so a legitimate sender you missed is recoverable rather than lost. Reject tells them to refuse it during the SMTP conversation, so it is never delivered at all. Reject is the destination, because it is the only policy that actually stops a spoofed message reaching anyone, and the only one Gmail and Yahoo treat as full compliance for bulk senders, but it is the last step, not the first.

Is DMARC required for sending email in 2026?

For bulk senders, effectively yes. Google and Yahoo both require a DMARC record on the sending domain for anyone sending in volume, alongside SPF and DKIM, and a policy of p=none satisfies the letter of that requirement. It does not satisfy the intent: none authorises nobody and blocks nothing. Treat the requirement as the reason to start the ladder rather than the finish line.

What does a DMARC record look like?

A DMARC record is a single line of text made of semicolon-separated tags. A first record looks like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; and an enforcing one like v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@yourdomain.com;. The v tag must come first and p second; everything after them may appear in any order. Only v and p are required by the specification, though a record with no rua address produces no reports and therefore tells you nothing. Every other tag has a default that applies when you leave it out, which is why a short record is usually the correct one.

What is the np tag in a DMARC record?

np sets the policy for subdomains that do not exist, meaning ones with no DNS records at all. It was added by RFC 9091 after the original DMARC specification, so many generators still do not offer it. It matters because inventing a plausible subdomain, something like invoices.yourdomain.com or hr-yourdomain.com, is one of the easiest spoofing routes available, and nothing legitimate can ever send from a subdomain that does not resolve. That makes np=reject the only enforcement setting with no rollout risk attached to it: there is no legitimate mail it can possibly block, so it is safe to publish on day one even while your main domain is still at p=none.

Should I turn on forensic reports with ruf?

Usually not, and never as the first thing you do. Forensic reports are sent per failing message and can contain the message content and the recipient address, which makes enabling them a data-protection decision rather than a technical one, and in some jurisdictions it needs a lawful basis before you switch it on. Most large receivers, including Google, never send them at all, so the practical return is low. If you do enable it, the fo tag decides when a report is generated: the specification default of fo=0 only reports when SPF and DKIM both fail, which silently misses the most informative case, so this generator emits fo=1 instead. Aggregate reports via rua are what an actual rollout runs on.

Free tool · no signup

Free DMARC record generator

Build the DMARC record for your domain, and find out before you publish it whether the reports it asks for will actually reach you. Most DMARC records that produce no reports are correct. They were just never authorised.

Ungated · no email required · unlimited use

Enter your domain recommended
We read the DMARC record you already publish so you edit it rather than replace it blind, and we read your SPF record, because DMARC is a verdict on it.
Your domain
Without a domain the record still builds, but nothing can be verified: whether your reports will arrive is a question about your domain, not about the address.
Say where the reports go
The aggregate report address. This comes before the policy because it is what makes every later step safe: reports are how you find the senders you forgot about, and you cannot raise a policy you cannot measure.
3
Pick your rung on the ladder
DMARC is a position on a ladder, not a setting. Each rung has something that has to be true before you climb to it.
1. Monitor
2. Quarantine
3. Reject
p=noneMonitorStart hereReceivers change nothing about how they treat your mail, and send you reports on what they saw. Nothing can break, which is the point: this is the rung where you find out who sends as your domain.First: Nothing. Publish it today, then read reports for two to four weeks before moving.p=quarantineQuarantineOnce the reports are cleanMail that fails alignment goes to spam rather than the inbox. Legitimate senders you have missed become visible fast, and recoverably, because the message is findable rather than gone.First: Every legitimate sender you found in the reports now passes SPF or DKIM with alignment. Move a percentage at a time if you are unsure.p=rejectRejectThe destinationMail that fails alignment is refused at the door. This is the only policy that actually stops someone spoofing your domain, and the only one Gmail and Yahoo treat as full compliance for bulk senders.First: Weeks of clean reports at quarantine, and working SPF and DKIM. Publish it while either is broken and you block your own mail.
Advanced tags
Subdomain policy sp
Applies to subdomains instead of the main policy. Worth setting to reject even while your main domain is at none, because subdomains that never send are the easiest thing in your estate to spoof.
Non-existent subdomains np
Applies only to subdomains that do not resolve at all: the ones an attacker invents, like invoices.yourdomain.com. Nothing legitimate can ever send from a subdomain that does not exist, so np=reject is the one enforcement setting with no rollout risk attached, and it is safe on day one even while your main domain is still at none.
np=reject is the one enforcement setting that cannot break anything: a subdomain that does not resolve has never sent legitimate mail. Safe to publish today, even at p=none.
DKIM alignment adkim
SPF alignment aspf
Relaxed accepts a subdomain match, strict demands an exact one. Relaxed is the default and the right answer for almost everyone; strict breaks mail sent from subdomains you forgot about.
Forensic reports ruf
Per-message failure reports, which may contain content and recipient addresses. Most large receivers never send them. Treat turning this on as a data-protection decision, not a technical one.

Your DMARC record

Format

v=DMARC1; p=none;

The value on its own. This is what the host or value field of a DNS panel expects.

No report address, so this record produces nothing you can read. You will never find out who sends as your domain, which means you can never safely climb past monitoring. Add one in step 2.

Check it once published

Reading DMARC reports is where most rollouts stall

The reports arrive as XML from every receiver on the internet, and the work is finding the legitimate senders hiding in them. SmartReach keeps your sending domains authenticated and warmed so there is far less to find.

See the deliverability suite

4.6 on G25,000+ sales teams and agenciesGDPR · CAN-SPAM

One valid recordReports verified liveChecks §7.1 authorisationReads your SPF firstMerges what you haveNo reject on a broken domainEvery tag, including npBIND and tinydns outputCopy and publishFree and ungated

The order that matters

Reports first, policy second

Every other DMARC generator opens with the policy dropdown. Policy is the last decision, not the first: a record at p=reject published before anyone has read a report is how an organisation blocks its own invoices. The reports are what make each step up the ladder safe, so they come first here.

Start from what you publish

Enter your domain and we read the DMARC record already at _dmarc, plus the state of your SPF, so the record you build is an edit rather than a rival.

Say where the reports go

The aggregate report address comes first because it is what makes every later step safe. We check live that the destination is authorised to receive your reports and can accept mail at all.

Pick your rung on the ladder

Monitor, quarantine or reject, with what has to be true before each. The tool will tell you when the rung you picked is ahead of the domain you picked it for.

Publish, then watch

Copy the record into one TXT record at _dmarc on your domain, wait for the TTL, then check it with the DMARC checker and start reading what arrives.

The three rungs

What has to be true before each policy

Start here

p=none · Monitor

Receivers change nothing about how they treat your mail, and send you reports on what they saw. Nothing can break, which is the point: this is the rung where you find out who sends as your domain.

First: Nothing. Publish it today, then read reports for two to four weeks before moving.

Once the reports are clean

p=quarantine · Quarantine

Mail that fails alignment goes to spam rather than the inbox. Legitimate senders you have missed become visible fast, and recoverably, because the message is findable rather than gone.

First: Every legitimate sender you found in the reports now passes SPF or DKIM with alignment. Move a percentage at a time if you are unsure.

The destination

p=reject · Reject

Mail that fails alignment is refused at the door. This is the only policy that actually stops someone spoofing your domain, and the only one Gmail and Yahoo treat as full compliance for bulk senders.

First: Weeks of clean reports at quarantine, and working SPF and DKIM. Publish it while either is broken and you block your own mail.

The rung most people skip is the one that costs nothing: RFC 7489 §6.6.3 gives DMARC inheritance that SPF does not have, so sp=reject protects every subdomain you have, including the ones that never send mail and are the easiest thing in your estate to spoof, while your main domain is still safely monitoring.

Deliberate omissions

What this generator will not emit

DMARC's failure mode is not a silent permerror. It is your own invoices being refused. These six are left out for a reason from the specification rather than a house preference.

p=reject

It will not hand you reject on a broken domain

DMARC is a verdict on SPF and DKIM, so enforcement on a domain whose SPF is missing or over the lookup limit rejects your own mail. We read your SPF record in the same pass and say so before you copy anything.

no rua

It will not build a record with nowhere to report

A policy you cannot measure is a policy you cannot safely raise. Without a rua address you get no reports, so you never learn who sends as your domain and you can never move past monitoring with any confidence.

ruf

It will not add forensic reporting by default

Failure reports can carry message content and recipient addresses, which makes them a data-protection question rather than a technical one. Most large receivers never send them anyway. It is available under the advanced options with that warning attached, not switched on quietly.

pct

It will not emit pct with p=none

The percentage tag says what share of failing mail gets the policy applied. At p=none nothing is being applied to any of it, so the tag reads as caution while doing nothing at all.

unverified rua

It will not pretend an unauthorised address will work

When your reports go to a domain you do not own, RFC 7489 §7.1 requires that domain to publish an authorisation record before any receiver will send anything. We check for it live, and a missing one is shown as the blocker it is rather than left to be discovered by an empty dashboard.

It will not emit tags that only restate a default

rf=afrf is the only report format anyone implements, and adkim=r and aspf=r are already what receivers assume. Emitting them adds length and gives a reader something to wonder about without changing what any receiver does. The shortest record that says what you mean is the correct one.

The one worth reading twice is the report authorisation. RFC 7489 §7.1 puts the requirement on the DESTINATION, not on you: your record can be perfect and your vendor can simply never have published the record that lets them receive anything. Receivers are not permitted to send in that case, so the failure is total, silent, and invisible from your own DNS.

Take it with you

Put this generator on your own site

Free to embed, on any site, with no permission needed and nothing to sign. It carries a visible credit back here, which is the whole arrangement. The report addresses are still verified against live DNS inside the frame, so an embedded copy checks exactly what this one does.

Paste this where you want it

<iframe
  src="https://smartreach.io/tools/embed/dmarc-generator/"
  title="Free DMARC record generator by SmartReach.io"
  width="100%" height="1100" loading="lazy"
  style="border:1px solid #e3e9f2;border-radius:12px"></iframe>

The frame scrolls internally, so the height is a starting point rather than a requirement. Raise it if you would rather the whole tool be visible at once.

Deliberate by default

What this generator puts in, and what it leaves out

DMARC defines twelve tags. Two are required and the rest all have defaults, so the shortest record that says what you mean is usually the correct one, which is why the record you just built is shorter than the specification. This is every tag, and the rule that decides whether it appears. For what each one means, the DMARC checker carries the full reference.

Tag	When this generator emits it
v=required	Always, first. RFC 7489 §6.3 requires it there.
p=required	Always, second, for the same reason.
rua=	Whenever you give an address, and each one is checked against live DNS first, because a report address that is not authorised produces silence rather than an error.
ruf=	Only when you switch it on. Failure reports can carry message content, which makes enabling them a data-protection decision rather than a technical one.
sp=	Only when you set it. Worth setting on almost every domain.
np=	Only when you set it. Worth setting to reject on day one, because it is the one enforcement setting with no rollout risk attached.
adkim=	Only when you choose strict. Relaxed is already what receivers assume.
aspf=	Only when you choose strict, for the same reason.
pct=	Only below 100, and never at p=none, where a percentage of a policy that applies to nothing reads as caution while doing nothing at all.
fo=	Only alongside ruf, and defaulted to 1 rather than the specification default of 0, which reports only when SPF and DKIM both fail.
ri=	Only when you change it from daily, which receivers may ignore anyway.
rf=	Never. afrf is the only value in real use, so emitting it adds length and changes nothing.

The one most records are missing is np, added by RFC 9091 after the original specification and still absent from most generators. It sets the policy for subdomains that do not resolve at all: the ones an attacker invents. Nothing legitimate can ever send from a subdomain that does not exist, so np=reject is the only enforcement setting with no rollout risk attached, and it is safe on the same day you publish p=none.

Once it is published

DMARC only works on top of the other two

A DMARC policy does not authenticate anything by itself. It decides what happens when SPF and DKIM have already spoken. Check the published record, then check the two records it passes judgement on.

What happens when a check fails

DMARC Checker

DMARC tells receivers whether to quarantine or reject mail that fails SPF and DKIM, and where to send the reports. Check your policy, alignment and reporting address.

What it looks like

v=DMARC1; p=reject; pct=100

Check my DMARC record

Which servers may send as you

SPF Checker

SPF lists the servers allowed to send mail for your domain. Check that yours is published, resolves, and stays under the ten-lookup limit that silently breaks it.

What it looks like

v=spf1 include:_spf.google.com ~all

Check my SPF record

Proof the message is really yours

DKIM Checker

DKIM signs every message with a key only you hold. Check that the public key is published, parses, is not revoked, and is long enough to be trusted.

What it looks like

v=DKIM1; k=rsa; p=MIIBIjANBgkq…

Check my DKIM record

Or start from a domain that already enforces

The ladder, already climbed

Every rung above monitoring depends on SPF and DKIM being right on every system that sends as you. SmartReach hands you sending domains and mailboxes with all three records in place, so there is nothing to fix before you can enforce.

Sending domains and mailboxes bought and authenticated in minutes, no IT ticket
SPF, DKIM and DMARC configured for you, so there is no record to hand-edit
Warmup, inbox rotation and ESP matching across unlimited sending accounts
Every address verified free before a campaign sends, so bounces never touch your domain

See how sending setup works →

“This software is focused on the end receiver as much as the user.”Matt McQuin · Co-founder, Coldlytics

Every rule on this page is checked against RFC 7489, the specification that defines DMARC. Last reviewed 24 August 2026. The report authorisation check runs against live DNS every time you use it, not against anything stored here.

FREQUENTLY ASKED QUESTIONS

DMARC record questions, answered

Publish one TXT record on the _dmarc subdomain of your domain, starting with v=DMARC1, followed by a p tag saying what receivers should do with mail that fails, and a rua tag saying where to send the aggregate reports. A first record usually looks like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. The v tag must come first and p must come second; the rest may be in any order. The generator on this page assembles it and checks that the report address will actually receive anything.

Stop fixing deliverability one DNS record at a time.

SmartReach buys and authenticates your sending domains and mailboxes with SPF, DKIM and DMARC already in place, then warms them, rotates them, and verifies every address before you send.

✓ 14-day free trial✓ No credit card✓ All features included✓ Unlimited sending inboxes

Start free trial Book a demo

In short

Enter your domain recommended

Say where the reports go

Pick your rung on the ladder

Reports first, policy second

What has to be true before each policy

What this generator will not emit

Put this generator on your own site

What this generator puts in, and what it leaves out

DMARC only works on top of the other two

The ladder, already climbed

DMARC record questions, answered

Stop fixing deliverability one DNS record at a time.