DMARC Record Generator: Build Yours Step by Step

A DMARC record generator builds the exact DNS TXT value you publish at _dmarc.yourdomain.com so mailbox providers know what to do with email that fails authentication. You still need to know what the output means before you paste it into DNS, because a wrong p= value or a missing rua= address can silently block your own mail or leave you with zero visibility into who is sending as your domain.

This guide walks through building a correct DMARC record by hand, so you understand every field a generator fills in for you, then publishing and validating it, plus the mistakes that break real sending domains.

Key takeaways

• A DMARC record is one DNS TXT record at _dmarc.yourdomain.com, made of semicolon-separated tags: v=DMARC1; p=none; rua=mailto:... is the minimum useful version.
• SPF and DKIM must already be passing and aligned with your "From" domain before DMARC can do anything useful. DMARC does not replace them, it grades them.
• Start at p=none for at least two to four weeks to collect aggregate reports before you enforce anything. Jumping straight to p=reject is the most common way to lose legitimate mail.
• Google and Yahoo have required DMARC for any domain sending 5,000+ messages a day since February 2024, and Microsoft added the same requirement for consumer inboxes (outlook.com, hotmail.com, live.com) in 2025. Below that volume it is still strongly recommended, not optional in practice.
• rua (aggregate reports) is the tag that matters most day to day. ruf (forensic, per-message reports) is largely ignored by Gmail, Yahoo, and Microsoft now for privacy reasons, so do not build a monitoring plan around it.
• One domain gets exactly one DMARC record. Two records at the same _dmarc host means receivers may ignore both, which looks identical to having no DMARC at all.

What a DMARC record actually contains

A DMARC record is a DNS TXT record, published as a subdomain host named _dmarc. For a domain like example.com, the full DNS host is _dmarc.example.com, and the value is a single string of tag-value pairs separated by semicolons.

Minimum viable record:

v=DMARC1; p=none; rua=mailto:[email protected]

That single line does three things: v=DMARC1 marks it as a DMARC record (this is a mandatory literal string, not a variable), p=none tells receivers to take no action on messages that fail, and rua= tells them where to send you a daily summary of what happened.

The tags you will actually use

You do not need most of these on day one. v, p, and rua cover the record that gets you visibility without touching deliverability.

Step 1: Confirm SPF and DKIM are live first

DMARC is a grading layer on top of SPF and DKIM, not a replacement for either. If neither is set up and aligned with your visible "From" domain, every message fails DMARC by default.

Before you write a DMARC record:

1. Confirm you have an SPF TXT record at your root domain (example.com, not _dmarc.example.com) listing every service allowed to send as you: your mail provider, your marketing platform, and any transactional sender like Amazon SES.
2. Confirm DKIM signing is turned on for each of those same senders, and that the DKIM d= domain matches or aligns with your From address domain.
3. Send a real test email through each sending source and check the authentication results in the received message headers (Authentication-Results: should show spf=pass and dkim=pass).

If you have not done this part yet, our SPF, DKIM, and DMARC explained walkthrough covers building the SPF and DKIM records first, in plain language, before you touch DMARC.

Step 2: Decide your reporting address

Aggregate reports (rua) arrive daily as XML files, one per receiving mailbox provider, summarizing every sending IP that used your domain and whether it passed or failed. Raw XML is not readable on its own, so most teams either:

• Point rua at a dedicated inbox ([email protected]) and read the raw XML manually or with a free parser, or
• Point rua at a DMARC analyzer or monitoring service that ingests the XML and renders it as a dashboard.

For a first record, a dedicated inbox is enough. You are looking for one thing in these reports: sending IPs you do not recognize, or sources you do recognize failing when they should pass. That second case usually means a legitimate service, a help desk tool, a CRM, a marketing platform, is sending as your domain without being in your SPF record or without DKIM configured.

Step 3: Choose your policy, starting conservative

The p= tag is the only tag that changes what happens to mail. Everything else is reporting and tuning.

• p=none: monitor only. Failing mail is delivered normally. This is where every domain should start, full stop, regardless of how confident you are in your setup.
• p=quarantine: failing mail is routed to spam/junk instead of the inbox.
• p=reject: failing mail is rejected outright at the receiving server.

The realistic path is none for several weeks while you read aggregate reports and fix any sender that is failing, then quarantine, then reject, each stage held long enough to confirm nothing legitimate is breaking. Moving straight to reject on an unmonitored domain is the most common way DMARC setups go wrong: a legitimate sender never added to SPF gets its mail bounced completely, often silently.

If you want to enforce gradually rather than as a hard switch, pct= lets you apply the policy to a percentage of failing mail rather than all of it, for example pct=25 to start enforcing on a quarter of failures while you confirm the rest is clean.

Step 4: Build the record

Here is a realistic progression for a SaaS company moving from nothing to full enforcement over a few months.

Week 1, monitoring only:

v=DMARC1; p=none; rua=mailto:[email protected]

After 2 to 4 weeks of clean reports, move to quarantine at a low percentage:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

After confirming no legitimate mail is affected, raise enforcement:

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]

Full enforcement, once every sending source has been verified clean:

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Note there are no spaces inside any tag value (p=none, never p= none), and every line ends without a trailing semicolon requirement, though a trailing semicolon is harmless.

Step 5: Publish it in DNS

The mechanics are identical across DNS providers, only the interface changes:

1. Log in to whichever service hosts your domain's DNS (your registrar, Cloudflare, Route 53, or wherever your nameservers point).
2. Add a new record with type TXT.
3. Set the host or name field to exactly _dmarc (most providers append your root domain automatically, so this becomes _dmarc.yourdomain.com).
4. Paste the full record string as the value.
5. Save, and check for an existing _dmarc TXT record first. A domain should have exactly one. Two DMARC records at the same host is invalid and many receivers will treat it as if no record exists at all.

DNS propagation for a new TXT record is typically fast, minutes to a few hours, but can take up to 48 hours depending on your provider's TTL settings.

Step 6: Validate before you trust it

Once published, confirm the record resolves correctly before you assume it is working. A dig or nslookup query against _dmarc.yourdomain.com for TXT records should return your string exactly as written, with no truncation and no duplicate records. From there, wait for your first aggregate report (usually within 24 hours) and read it for anything unexpected. If you are also working through blacklist or spam-folder issues on the same domain, run those checks in parallel: a clean email blacklist status and a correct DMARC record solve different problems, and neither substitutes for the other.

Common mistakes that break a DMARC rollout

• Jumping to p=reject on day one. You have no data yet on who is legitimately sending as your domain, so marketing tools, help desks, and internal scripts can get silently blocked.
• Forgetting a sending source in SPF. DMARC only passes if SPF or DKIM passes and aligns. A forgotten sender, a new transactional provider or an old marketing tool nobody decommissioned, fails DMARC even though the mail is legitimate.
• Publishing two DMARC records. Whether from a leftover default record or a duplicate added by a second team member, more than one _dmarc TXT record makes the whole setup unreliable.
• No rua address, or one nobody reads. A record with p=quarantine and no monitoring means you find out about a broken sender only when someone complains their email landed in spam.
• Treating ruf as a real monitoring channel. Gmail and Yahoo largely stopped honoring forensic reports for privacy reasons, and Microsoft's support is limited. Build visibility around rua, not ruf.
• Assuming DMARC fixes deliverability by itself. It stops spoofing and gives you visibility. It does not improve sender reputation, list hygiene, or engagement, which stay separate, ongoing work.

Why this matters beyond "checking a box"

Since February 2024, Google and Yahoo have required a DMARC record (at minimum p=none) for any domain sending 5,000 or more messages a day to their users, alongside SPF/DKIM alignment and a sub-0.3% spam complaint rate; non-compliant mail is deferred or rejected. Microsoft extended a comparable authentication requirement to its consumer inboxes (outlook.com, hotmail.com, live.com) in 2025. Below the bulk-sender threshold, none of the major providers technically block you for lacking DMARC, but it is the baseline every legitimate sender is now expected to have, and its absence is one of the first things a spam filter or a technical prospect checks.

For a SaaS company, this sits underneath the product-facing decisions your growth or marketing team makes about lifecycle email and broadcasts. Getting authentication right is table stakes, not a differentiator. If DMARC and SPF/DKIM are new territory, our email deliverability guide covers the full stack in one place, DMARC is one input into your broader sender reputation, and Google Postmaster Tools is worth setting up alongside it since it shows Gmail-specific reputation data that DMARC reports do not.

This is also the layer we had to get right building Meisa: sender identities and domain verification (SPF/DKIM/DMARC) are part of the platform because a founder should not have to hand-build DNS records to send trustworthy lifecycle email from their own AWS SES setup. That is a small, honest piece of a much bigger authentication job, and it does not replace understanding what you are publishing, which is exactly what the record above does.

FAQ

What is the difference between SPF, DKIM, and DMARC?

SPF lists which mail servers are allowed to send for your domain. DKIM adds a cryptographic signature to prove a message was not altered in transit and really came from an authorized sender. DMARC sits on top of both: it tells receiving servers what to do when a message fails SPF or DKIM, and it aligns the result with the domain shown in the "From" address. All three work together; none of them alone stops spoofing reliably.

Do I need a DMARC record if I send low volume?

Google, Yahoo, and Microsoft only formally require DMARC once you cross roughly 5,000 messages a day to their users, but there is no real downside to publishing p=none at any volume. It costs nothing, breaks nothing, and starts collecting visibility into who is sending as your domain.

What does p=none actually do?

Nothing to delivery. Messages that fail DMARC are delivered exactly as they would be without a DMARC record at all. The only effect is that receiving mail servers start sending you aggregate reports, which is why p=none is the correct starting point rather than a placeholder to skip.

How long should I stay on p=none before enforcing?

Two to four weeks is a reasonable minimum to see a full pattern of your legitimate senders, though larger organizations with many sending tools often monitor for longer. The signal you are waiting for is a stretch of reports with no unexplained failing sources, not a fixed calendar date.

Can one DMARC record cover subdomains too?

Yes, using the sp= tag, which sets a separate policy for subdomains if you want it to differ from your main policy. Without sp=, subdomains inherit the p= policy from the organizational domain's DMARC record.

Why do I have two DMARC records and which one wins?

This usually happens when a hosting provider or app added a default record and you added your own later without removing it. Receivers do not merge them or reliably pick one, they may treat the domain as having no valid DMARC record at all. Check your DNS for a duplicate _dmarc TXT entry and remove one before troubleshooting anything else.