DMARC Record Builder: The Complete Guide to Stopping Email Spoofing
Learn how to create and publish a DMARC DNS TXT record with the free DMARC Record Builder — configure p, sp, rua, ruf, adkim, aspf, and pct tags correctly.
Table of Contents
Email spoofing remains one of the most damaging attack vectors on the internet. Attackers forge the From address to impersonate your domain, tricking customers into surrendering credentials, finance teams into paying fake invoices, and partners into trusting malicious links. The good news is that there is a DNS-level fix. DMARC — Domain-based Message Authentication, Reporting and Conformance, standardized in RFC 7489 — lets you tell receiving mail servers exactly what to do when a message claims to be from your domain but fails authentication. Built on top of SPF and DKIM, it is the single most effective defense against domain impersonation.
The catch is that DMARC records are easy to get wrong. A mistyped tag, a missing reporting address, or an aggressive policy deployed too early can silently break legitimate email — or leave you without the data you need to roll out safely. The free DMARC Record Builder removes that risk. It walks you through every DMARC tag — p, sp, rua, ruf, fo, adkim, aspf, ri, and pct — and generates the exact TXT record string to publish at _dmarc.yourdomain.com, with a live preview so you always see what will land in your DNS.
This guide explains how the builder works, what every tag means, and how to plan a safe rollout from monitoring to full enforcement — whether you protect a single startup domain or dozens of client domains.
Why Use the DMARC Record Builder?
- No syntax guesswork. DMARC records are a single line of semicolon-separated tags, and one typo can invalidate the whole record. The builder assembles valid syntax for you.
- Every tag covered. Configure the policy, subdomain policy, reporting URIs, failure options, alignment modes, report interval, and rollout percentage from one form.
- Safe defaults. Start with p=none and relaxed alignment — the recommended monitoring setup — then tighten as your confidence grows.
- Live TXT preview. Watch the exact record update in real time as you change options, and copy it with one click.
- Publish-ready output. Get the precise string to paste into your DNS provider as a TXT record at _dmarc.yourdomain.com.
- Free and instant. No account and no server-side processing — everything runs in your browser.
Key Features
| Feature | What it controls |
|---|---|
| Policy (p) | How receivers treat mail that fails DMARC: none (monitor), quarantine (spam folder), or reject (block). |
| Subdomain policy (sp) | The policy applied to subdomains, which can differ from the root domain. |
| Aggregate reporting (rua) | Where daily XML aggregate reports about all mail claiming your domain are sent. |
| Forensic reporting (ruf) | Where per-message failure reports are sent when authentication fails. |
| Failure options (fo) | When forensic reports fire: 0 all failed, 1 any failure, d DKIM failure, s SPF failure. |
| Alignment (adkim / aspf) | Relaxed (r) or strict (s) matching between the From domain and the authenticated domain. |
| Report interval (ri) | How often receivers send aggregate reports, in seconds (default 86400). |
| Percentage (pct) | The share of failing messages the policy applies to, for gradual rollouts. |
| Live preview + copy | A real-time TXT record preview with one-click copy, ready for any DNS provider. |
- Reporting-first design. The builder encourages you to set rua from day one, because aggregate reports are the only way to see who is sending mail as your domain before you start blocking anything.
- Alignment made simple. Instead of memorizing RFC definitions, pick relaxed or strict from a dropdown and see the resulting adkim and aspf tags immediately.
- Rollout controls built in. Combine pct with quarantine to apply policy to, say, 10% of failing mail while you watch reports — then ramp up.
How to Use
- Open the builder. Visit the DMARC Record Builder and enter your domain. The tool uses it to show the exact DNS host name (_dmarc.yourdomain.com) where the record will be published.
- Choose your policy. Select none, quarantine, or reject for your main domain, and optionally set a separate subdomain policy with sp. If you are just starting, pick none.
- Add reporting addresses. Enter one or more mailto: addresses for rua (aggregate reports) and, if you want per-message detail, ruf (forensic reports). Choose the fo option that matches when you want failure reports.
- Tune alignment and rollout. Leave adkim and aspf at relaxed unless you have a specific reason for strict, keep ri at the 86400 default, and set pct if you are ramping a quarantine or reject policy gradually.
- Copy and publish. Review the live TXT preview, click copy, and paste the value into a new TXT record at _dmarc in your DNS provider. Propagation usually takes minutes — verify it with any DNS lookup tool.
Understanding DMARC Tags
A valid DMARC record always begins with v=DMARC1 and must contain at least a p tag. Everything else is optional but important. Here is the full set the builder supports:
| Tag | Name | Notes |
|---|---|---|
| v | Version | Always DMARC1; the record is ignored without it. |
| p | Policy | none, quarantine, or reject for the organizational domain. |
| sp | Subdomain policy | Same values as p, applied to subdomains; defaults to the p value if omitted. |
| rua | Aggregate report URI | Comma-separated mailto: URIs that receive daily XML reports. |
| ruf | Forensic report URI | mailto: URIs that receive per-message failure reports. |
| fo | Failure options | 0 (default): report only if both SPF and DKIM fail; 1: any failure; d: DKIM only; s: SPF only. |
| adkim | DKIM alignment | r relaxed (default) or s strict. |
| aspf | SPF alignment | r relaxed (default) or s strict. |
| ri | Report interval | Seconds between aggregate reports; default 86400 (24 hours). |
| pct | Percentage | 0–100; the share of messages the policy applies to. Default 100. |
Relaxed vs. strict alignment
Alignment is what ties authentication results to the domain the recipient actually sees. With relaxed alignment (adkim=r, aspf=r), a DKIM signature from mail.example.com or an SPF pass from a subdomain still aligns with example.com. Strict alignment (s) demands an exact domain match. Relaxed is the right choice for most senders — it tolerates newsletters, CRMs, and billing platforms that send from subdomains or third-party infrastructure. Strict is occasionally needed for high-security domains, but it will fail legitimate mail sent through subdomain-based services.
The none → quarantine → reject rollout
DMARC is a rollout, not a switch:
- p=none — Receivers authenticate but take no action. You collect rua reports and build a map of every service sending mail as your domain, then fix SPF and DKIM for each legitimate sender.
- p=quarantine — Failing mail goes to spam. Start with a low pct (say 10–25%) and raise it as reports confirm no legitimate mail is failing.
- p=reject — Failing mail is blocked outright. This is the end state: spoofed mail from your domain no longer reaches inboxes.
Skipping straight to reject is how legitimate email gets bounced. The reporting phase is what makes enforcement safe.
Practical Use Cases
A SaaS company protecting its domain from phishing
A SaaS product sends transactional mail from example.com and marketing mail from mail.example.com. Attackers spoof example.com directly in password-reset phishing campaigns. The team publishes p=none with rua pointed at their security mailbox, spends two weeks getting their ESP, CRM, and support desk aligned under SPF and DKIM, then moves to p=quarantine with pct=25, and finally to p=reject. Within a quarter, spoofed mail from their domain effectively disappears from customer inboxes.
An agency monitoring client domains
A marketing agency manages email for 30 client domains. Using the builder, they generate a p=none record for each domain with rua pointed at a shared reporting inbox or a DMARC analytics service. The aggregate reports reveal shadow IT — forgotten subdomains, a legacy newsletter tool, a founder's personal Gmail sending as the company — all of which get properly authenticated before any enforcement begins.
Stopping invoice-spoofing BEC attacks
A finance team is hit by business email compromise: a fraudster spoofs the CFO's domain and requests an urgent wire transfer. With p=reject in place, receiving servers that honor DMARC refuse those messages before they reach employees. The rua reports also give the security team evidence of the attempts — volume, source IPs, and which authentication check failed.
A new domain that sends no email yet
Even a domain that sends no mail should publish v=DMARC1; p=reject; rua=mailto:[email protected]. If you never send email, any message claiming to be from your domain is fraudulent by definition, and reject shuts the door immediately.
Best Practices
- Start with p=none. Monitor before you enforce — you cannot fix senders you do not know about.
- Always set rua. Aggregate reports are your visibility into everything sending as your domain. Without them you are enforcing blind.
- Verify SPF and DKIM first. DMARC only passes when at least one of them authenticates and aligns. Publish correct SPF and DKIM records for every legitimate sender before turning on quarantine or reject.
- Mind the 255-character TXT limit. A single DNS TXT value is limited to 255 characters. Long rua lists with many addresses can exceed it — keep reporting URIs concise or use a reporting service's single address.
- Ramp pct gradually. When moving to quarantine or reject, apply the policy to a small percentage first and increase it as reports stay clean.
- Keep monitoring after enforcement. Legitimate senders change infrastructure. A rua inbox or reporting dashboard catches new failures before your customers do.
Start Protecting Your Domain Today
Email spoofing is solvable at the DNS level — but only if your record is correct and your rollout is measured. Open the DMARC Record Builder, generate your record in under a minute, and publish it today. Start with p=none, watch the reports roll in, and work your way to p=reject. Your domain's reputation — and your customers' inboxes — will thank you.
Related Tools You Might Like:
- SPF Record Builder — Create an SPF TXT record listing every service authorized to send mail for your domain.
- DKIM Record Generator — Generate DKIM keys and TXT records so your outgoing mail carries a verifiable signature.
- DNS Lookup — Query live DNS records to verify your DMARC, SPF, and DKIM records are published and propagated.
Happy securing!