Build a DMARC record step by step, from monitoring to full protection, and check that your reports will actually arrive before you publish it.
DMARC is the DNS record that tells receiving mail servers what to do with a message that claims to come from your domain but fails authentication: deliver it anyway, send it to spam, or refuse it. It also asks them to send you reports, which is how you find out who is sending as your domain.
This generator builds the record and checks the two things that most often make a DMARC rollout fail without anyone noticing: reports that are sent to another domain without permission, and a strict policy published on a domain that is not ready for it.
Every DMARC rollout should move through the same three policies. p=none changes nothing about delivery; it only switches on the reports. Leave it there for a few weeks and read what comes back. You will almost certainly find a service sending on your behalf that you had forgotten about, and it needs SPF or DKIM fixed before you tighten anything.
p=quarantine asks receivers to put failing mail in spam. p=reject asks them to refuse it outright, which is the setting that actually stops someone sending convincing phishing as your domain. Many organisations stop at p=none and believe they are protected. They are not: at none, spoofed mail is still delivered.
The optional pct tag lets you apply a stricter policy to a percentage of failing mail first. It only has an effect with quarantine or reject.
rua is where aggregate reports go. These are daily XML files from each large receiver summarising how much mail they saw from your domain, from which servers, and whether it passed. They contain no message content, and they are the part of DMARC you will actually use. Raw XML is hard to read, so most people send them to a reporting service or a dedicated mailbox and use a parser.
ruf asks for failure reports about individual messages. They can contain parts of the message itself, so they raise privacy questions, and many of the largest mailbox providers do not send them at all. Leave ruf empty unless you have a specific reason to want them.
If your rua address is at a different domain, for example a reporting service or your agency, receivers will only send reports there if that domain agrees to accept them. The check (RFC 7489, section 7.1) is a TXT record at yourdomain.com._report._dmarc.theirdomain.com containing v=DMARC1. If it is missing, the reports are silently discarded and you will wonder why your new DMARC setup never reports anything.
Reporting services normally publish that record automatically once you add your domain to their dashboard. If you are sending reports to a second domain of your own, you need to add it yourself. Enter your domain above and this tool checks it for you.
DMARC only counts an SPF or DKIM pass if the domain that passed matches the domain in the visible From address. Relaxed alignment (the default) accepts a subdomain, so mail signed by mail.example.com aligns with example.com. Strict alignment requires an exact match.
Strict sounds safer, but in practice it mostly breaks legitimate mail sent through services that sign or bounce through a subdomain. Keep relaxed unless you have a specific reason not to.
Check that every service sending as your domain passes either SPF or DKIM with alignment. The aggregate reports show this directly. DKIM is the one to rely on, because it survives forwarding and SPF does not. If your domain has no SPF record at all and you publish p=reject, any of your own mail that is not DKIM-signed will be refused, which is why this generator warns about it.
Since February 2024, Gmail and Yahoo require a DMARC record (at least p=none) from anyone sending large volumes to their users, so publishing one is no longer optional for most businesses that send email in bulk.
As a TXT record named _dmarc on your domain, so the full name is _dmarc.yourdomain.com. In most DNS panels you type _dmarc in the name field and the domain is added for you.
No. It only turns on reporting. Receivers still deliver mail that fails, so spoofed messages still arrive. It is the right first step and the wrong place to stay.
The most common reasons are a missing rua tag, a typo in the address, or reports addressed to another domain that has not published the authorisation record at yourdomain._report._dmarc.theirdomain. Reports also only arrive once a day, from receivers that saw mail claiming to be from you.
Not usually. A subdomain without its own record inherits the policy of the main domain, and the sp tag lets you set a different policy for subdomains from the same record.
It applies quarantine or reject to only that percentage of failing mail, treating the rest as one step weaker. It is useful for a gradual rollout and has no effect when the policy is none.
You can publish p=none at any time, and it is a good way to find out what you need to fix. Before quarantine or reject, every legitimate sender must pass SPF or DKIM with alignment, otherwise you will block your own mail.