Which policy should I start with?

p=none. It changes nothing about delivery but turns reporting on. Two to four weeks of reports will show who sends mail as your domain and what fails authentication. Only then does moving to quarantine, and later reject, make sense.

Do I have to fill in rua?

Not formally, but DMARC loses most of its value without it. Aggregate reports are the only way to see what is really happening. Going to p=reject with no reports means you may block your own campaigns and hear about it from customers.

What if the report address is on another domain?

RFC 7489 requires that domain to authorise the reports by publishing a TXT record at yourdomain._report._dmarc.theirdomain with the value v=DMARC1. Without it most senders deliver nothing, and there is no error to notice, just silence. Our DMARC checker tests this automatically.

Relaxed or strict alignment?

Alignment governs how closely the authenticated domain must match the From header the recipient sees. relaxed is the default, allows subdomains, and suits almost everyone. strict demands an exact match and breaks setups where a subdomain signs mail for the parent.

Do I need the sp tag?

Only when subdomains need a different policy from the parent. Without sp they inherit p. The dangerous combination is a strict p alongside sp=none: the main domain is protected while subdomains stay open, and those are what an attacker will use.

DMARC Record Generator

Fill in the fields and we will assemble a valid record, explaining what each tag does. Default values are left out of the record, so it comes out shorter, with fewer places to make a typo.

Policy for the domain

Start with none. After two to four weeks, once reports show all your own mail passes, tighten it.

Policy for subdomains

Where to send aggregate reports (rua)

The main benefit of DMARC. Without this address you never learn who sends mail as your domain. If it lives on another domain, that domain must authorise the reports with its own record.

Forensic failure reports (ruf)

Share of mail under the policy

Below 100 only makes sense while phasing in a strict policy.

Reporting interval, seconds

86400 means once a day, which is the standard value.

Identifier alignment

relaxed is the default and suits almost everyone. strict stops subdomains from authenticating mail for the parent domain.

Generated record

v=DMARC1; p=none

How to publish it
Type	Name	TTL
TXT	_dmarc	3600

Three stages of rollout

p=none. Delivery is unchanged, reports accumulate. Usually held for two to four weeks.
p=quarantine. Failing mail goes to spam. Enable once no legitimate senders appear as failing in the reports.
p=reject. Failing mail is rejected outright. The end goal, and what Gmail and Yahoo expect from bulk senders.

Where to publish it

As a TXT record at _dmarc.yourdomain. Most panels only need _dmarc in the name field and append the domain themselves. The leading underscore is mandatory and is the most common typo.

A record on the organisational domain also covers subdomains that have none of their own. A subdomain needs its own record only when it needs a different policy.

What DMARC does not do

It does not inspect message content, and it does not protect against look-alike domains. Against examp1e.com instead of example.com DMARC is powerless, because that is a different domain, and your policy does not apply to it. It also does nothing without SPF or DKIM in place, since there would be nothing to align against.

Where the reports go

The address in rua= is the only reason p=none is worth publishing at all. Without it the policy blocks nothing and shows nothing, which adds up to doing nothing.

The volume is modest: one or two files a day from each large provider. The format is machine-oriented, though, so give it a dedicated mailbox or feed it to an analyser. Reading the XML by hand is fine for a week and tiresome after that.

If reports go to a different domain, that domain has to authorise it: a TXT record at your-domain._report._dmarc.their-domain containing v=DMARC1. Without it providers silently send nothing, and it looks exactly like DMARC not working.

Tags you usually do not need

pct= — the share of mail the policy applies to. Useful while ramping into quarantine, then removed. BIMI does not work on p=reject with a pct below 100.
sp= — a separate policy for subdomains, which otherwise inherit p. Worth setting only when you are deliberately keeping subdomains softer, which is normally a temporary state.
adkim/aspf — alignment strictness. The relaxed default suits nearly everyone; strict mode s breaks sending from subdomains.
ruf= — forensic reports. Almost nobody sends them because of the personal data inside.
fo, ri, rf — reporting options that in practice nobody changes.

The record goes on _dmarc

The record name is _dmarc.yourdomain; most panels only need _dmarc in the name field. The underscore is mandatory, and this is a frequent source of failure: a record placed at the domain root next to SPF is simply never found.

Checking the result immediately after publishing tells you nothing, so let DNS propagate, which takes anywhere from minutes to an hour depending on TTL. The first reports arrive within a day, and they already show whether every sender is accounted for.

Subdomains inherit the policy

Unlike SPF and DKIM, DMARC applies to subdomains: a policy on example.com covers news.example.com even without a record of its own. Convenient for protection, dangerous for delivery, and moving to p=reject starts rejecting mail from subdomains that have no authentication configured.

The sp= tag lets you give subdomains a separate, softer policy. Treat it as a temporary measure during rollout: left in place long term it turns subdomains into exactly the open door that DMARC was deployed to close.

Questions

Nearby

Clean the list before tightening the policy

A strict DMARC policy damages domain reputation when campaigns go to dead addresses and spam traps. uChecker verifies your list before you send, and the first 100 addresses are free.

Check your list