Free DMARC Record Generator
Create a DMARC policy record with the right enforcement level, reporting addresses, and alignment settings. Copy it straight to your DNS in seconds.
How to Use This Tool
Choose your policy
Start with p=none to monitor without blocking. Move to quarantine, then reject once your SPF and DKIM are verified and you're confident in your setup.
Add a reporting address
The rua address receives aggregate DMARC reports. Use a dedicated mailbox or a DMARC reporting service to review them.
Publish the TXT record
Add the generated record as a TXT record at _dmarc.yourdomain.com in your DNS provider.
What DMARC Is and Why It Completes the Authentication Picture
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication protocol that builds directly on top of SPF and DKIM. Where SPF checks whether the sending IP is authorised and DKIM verifies a cryptographic signature, DMARC connects both of those results to the domain in the visible From header — the address your recipients actually see. Without DMARC, an attacker can pass SPF using their own domain in the envelope while displaying your domain in the From header, a technique called display-name spoofing that phishing campaigns exploit routinely.
A DMARC record is published as a TXT record at the subdomain `_dmarc.yourdomain.com`. When a receiving server evaluates an inbound message, it performs SPF and DKIM checks, then applies DMARC alignment: it checks whether the domain authenticated by SPF or DKIM matches the organisational domain in the From header. If at least one aligned check passes, DMARC passes. If neither passes, DMARC fails — and the policy tag in your record tells the receiver what to do with that message. This is a meaningful enforcement layer that SPF and DKIM alone cannot provide.
DMARC also introduced a reporting mechanism that fundamentally changed how domain owners understand their email ecosystem. Aggregate reports (rua) are sent by participating receivers — including Google, Microsoft, Yahoo, and many others — as XML summaries showing every IP that sent mail claiming your domain, along with whether SPF and DKIM passed or failed for each source. This gives you visibility into both your own sending infrastructure and any third parties attempting to spoof your domain.
Policy Progression: Moving from None to Reject
The `p=` tag in your DMARC record sets the policy applied to messages that fail DMARC evaluation. The three values — `none`, `quarantine`, and `reject` — represent a deployment progression rather than arbitrary choices. You should almost never jump straight to `reject` on a domain that was not previously enforcing DMARC, because you will block legitimate mail from sources you had not discovered yet.
Begin with `p=none`, which instructs receivers to take no action on failing messages but still send you aggregate reports. Spend two to four weeks reading those reports carefully. You will likely find ESPs, internal apps, or subsidiary systems you had forgotten about. Add each legitimate sender to your SPF record or ensure its DKIM signatures align to your From domain. Once your DMARC pass rate for legitimate mail is consistently above 95 percent, move to `p=quarantine`, which routes failing mail to the spam folder. Monitor for another week or two, then advance to `p=reject`, which instructs receivers to discard messages that fail DMARC entirely.
The `pct=` field lets you apply your policy to a percentage of failing messages rather than all of them. Setting `pct=10` at quarantine, then `pct=50`, then `pct=100` gives you a staged rollout that limits blast radius if you missed a legitimate sender. This is particularly valuable for large organisations with many mail-sending services. The default is 100 when pct is omitted, so if you want a staged rollout you must explicitly set it.
Alignment, Reporting Tags, and Where to Publish
Alignment controls how strictly DMARC compares the authenticated domain to the From domain. For SPF, alignment is checked against the RFC5321.MailFrom (envelope-from) domain. For DKIM, it is checked against the `d=` domain in the DKIM-Signature header. The `aspf=` and `adkim=` tags each accept either `r` for relaxed or `s` for strict. Relaxed alignment allows subdomain matches — `mail.yourdomain.com` aligns with `yourdomain.com`. Strict alignment requires an exact match. Relaxed is the default and appropriate for most setups; strict is only needed when you want to prevent subdomain spoofing scenarios within your own domain.
The `rua=` tag specifies where aggregate reports are sent. Point it to a monitored mailbox or, better, a DMARC analytics service that can parse the XML and present it in readable form. The `ruf=` tag specifies where forensic (failure) reports go — individual message-level reports showing the full headers of failing messages. Note that many major receivers have stopped sending ruf reports due to privacy concerns, so do not rely on them as your primary diagnostic tool.
Your DMARC record must be published at exactly `_dmarc.yourdomain.com` — no variation. The common mistake of publishing it at `yourdomain.com` or `dmarc.yourdomain.com` means receivers cannot find it. Subdomains use the `sp=` tag to set a separate policy for organisational subdomains, which defaults to the main `p=` policy if omitted.
What DMARC Reports Reveal and How to Act on Them
Aggregate DMARC reports are among the most underused diagnostics available to email administrators. Each report comes from a participating receiver and covers a time window, typically 24 hours. Inside the XML you find: the source IP, the count of messages, the SPF and DKIM disposition results, and whether DMARC passed or failed. Aggregated across all receivers, this data tells you exactly which sending services are authenticated correctly and which are not.
Common findings include: your main ESP passes while a secondary automation tool fails because its DKIM is not configured; a transactional email subdomain has no SPF record; a cloud storage service sends notifications from your domain without authentication; an old IP range is still in your SPF record but the service was decommissioned. Each of these findings is something you would not discover without DMARC reports, and each represents either a deliverability risk or a security exposure.
Once you are at `p=reject`, DMARC reports also confirm enforcement is working correctly. You should see near-zero DMARC failures from your known legitimate senders, and any remaining failures will be genuine spoofing attempts or misconfigured edge cases to investigate. Treating DMARC reporting as an ongoing operational discipline — not a one-time configuration task — is what separates organisations with genuinely secure email domains from those who published a record and forgot about it.
Key Features
Policy Stage Selector
Choose none, quarantine, or reject with explanations of what each means for failing messages.
Percentage Rollout Control
Set the pct field to apply policy to a fraction of failing mail during staged deployment.
Alignment Mode Toggle
Configure relaxed or strict alignment separately for SPF and DKIM to match your domain structure.
Report Address Validation
Validates rua and ruf email addresses and warns about cross-domain reporting requirements.
Subdomain Policy Config
Optionally set sp= to apply a different policy to organisational subdomains independent of the root.
Correct Hostname Reminder
Reminds you to publish at _dmarc.yourdomain.com and shows the exact DNS label to use.
Frequently Asked Questions
Related Tools
Continue your email deliverability setup with these free tools.
Tools Are Just the Start
Once your domain is set up, mailtani handles sending, warmup, sequences, and rotation.
See How mailtani Compares
From the Blog
Full Deliverability Controls Built In
mailtani guides you through SPF, DKIM, and DMARC setup and monitors your sender reputation in real time — all included at a single one-time price.
- DMARC setup walkthrough included
- Aggregate report analysis
- Inbox warmup & rotation
- One-time price
14-day free trial · €89 lifetime access after