DMARC Record Generator: Set Up Email Authentication in Minutes

Key takeaways:

• A DMARC record tells receiving email servers what to do when someone sends email pretending to be you — without one, your domain is open to spoofing and phishing attacks.
• Setting up DMARC doesn’t require a developer. A DMARC record generator produces the correctly formatted DNS record in seconds — you just need to publish it.
• Start with a monitoring-only policy (p=none) before moving to enforcement. Going straight to p=reject without understanding your email traffic first will break legitimate sends.

If you’re sending cold email, running outbound sequences, or just using email for business, your domain’s reputation is one of your most valuable assets. And right now, if you don’t have DMARC set up, that asset is unprotected.

DMARC — Domain-based Message Authentication, Reporting, and Conformance — is an email authentication protocol that tells receiving mail servers how to handle messages that claim to come from your domain but fail authentication checks. Without it, anyone can send email that appears to come from your domain. With it, you control exactly what happens when they try.

The good news is that setting it up doesn’t require deep technical knowledge. A DMARC record generator handles the formatting and syntax — you fill in a few settings, copy the output, and add it to your DNS. The whole process takes less than 15 minutes if you know what you’re doing.

This guide will walk you through what DMARC actually does, how to use the generator to create your record, how to publish it correctly, and how to move from monitoring to full enforcement without breaking your legitimate email sends.

Why your domain needs DMARC

Most people think of email deliverability as a sending problem — open rates, spam filters, subject lines. DMARC is different. It’s a receiving-side protection that tells other mail servers how to handle email that claims to come from your domain.

Without DMARC, your domain is vulnerable to two specific problems:

• Email spoofing. Anyone can send an email with your domain in the From field. No technical access to your domain required — just a mail server and bad intent. These spoofed emails can be used to phish your customers, impersonate your team, or run scams that your recipients associate with your brand.
• Deliverability damage from spoofing. When spoofed emails sent from your domain generate spam complaints or get flagged, those signals can affect how legitimate email from your domain is treated. You suffer the reputation damage from someone else’s behavior.

DMARC doesn’t just protect against spoofing — it also creates a reporting system. When email is sent claiming to be from your domain, you receive reports showing where those sends originated, whether they passed authentication, and what the receiving server did with them. That visibility is valuable even before you move to enforcement.

Beyond protection, DMARC is increasingly becoming a baseline requirement for email delivery. Google and Yahoo require DMARC for bulk senders. Many enterprise mail servers use DMARC compliance as a signal in deliverability decisions. Not having it is becoming a practical liability, not just a security gap.

How a DMARC record generator works

A DMARC record is a line of text published in your domain’s DNS — specifically, a TXT record at _dmarc.yourdomain.com. The format has to be exact. A single syntax error means the record gets ignored entirely.

A DMARC record generator removes the formatting problem. You select your settings through a simple interface, and the tool builds the correctly formatted DNS record for you. No manual syntax required — just copy the output and publish it.

Here’s what that looks like in practice. Use the generator below:

The generator asks you to choose values for the key DMARC tags. Here’s what each one means in plain language:

p — Policy This is the most important setting. It tells receiving servers what to do with email that fails DMARC authentication.

• p=none — Do nothing. Monitor and report, but deliver the email normally. This is where you start.
• p=quarantine — Send failing email to the spam folder.
• p=reject — Block failing email entirely. This is the goal, but only after you’ve confirmed your legitimate sends are passing.

rua — Aggregate report address Where to send daily summary reports of all email claiming to be from your domain. Set this to an email address or a dedicated reporting service. Format: rua=mailto:[email protected]

ruf — Forensic report address Where to send individual failure reports. More detailed than aggregate reports, but not all providers send them. Optional, but useful during initial monitoring.

pct — Percentage What percentage of failing email to apply the policy to. Default is 100. If you’re moving from p=none to p=quarantine, you can start at pct=10 and increase gradually.

sp — Subdomain policy Separate policy for subdomains. If not specified, subdomains inherit the main domain policy.

adkim and aspf — Alignment modes Controls how strictly DKIM and SPF alignment is checked. r (relaxed) is the right default for most setups. s (strict) requires exact domain matching.

A basic DMARC record with monitoring policy looks like this:

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

A fully enforced record with reporting looks like this:

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

The generator builds this output for you based on the options you select. You don’t need to write it manually.

DMARC, SPF, and DKIM — how they work together

DMARC doesn’t work alone. It depends on two other authentication protocols being in place first — SPF and DKIM. Understanding how they connect is important before you generate dmarc records and publish them.

• SPF (Sender Policy Framework) specifies which mail servers are authorized to send email from your domain. When a receiving server gets an email from your domain, it checks your SPF record to see if the sending server is on the approved list.
• DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your outgoing emails. The receiving server checks that signature against a public key published in your DNS to confirm the email hasn’t been tampered with and genuinely originated from your domain.
• DMARC sits on top of both. It checks whether the email passed SPF or DKIM authentication, and whether the domain in those checks aligns with the domain in the From field. If the email passes at least one of those checks in alignment, it passes DMARC. If it fails both, your DMARC policy determines what happens next.

The practical implication: before you use a DMARC builder to create and publish your record, make sure your SPF and DKIM records are already set up and working correctly. DMARC built on top of broken SPF or DKIM will flag your own legitimate email as failing — and if you jump straight to p=reject, those emails will be blocked.

How to generate and publish your DMARC record

Here’s the full process from opening the generator to having a working DMARC record published and monitoring your email traffic.

Step 1: Confirm SPF and DKIM are in place

Before you generate dmarc record configuration, check that SPF and DKIM are already set up for your domain. Use a tool like MXToolbox or Google Admin Toolbox to run a lookup on your domain and confirm both records exist and are valid.

If either is missing or broken, fix that first. Publishing DMARC without working SPF and DKIM is like installing an alarm system on a house with open windows — the authentication layer it depends on isn’t there.

Step 2: Open the DMARC record generator and set your policy

Open the generator and start with p=none. This is the monitoring-only policy — it doesn’t block or quarantine anything, it just generates reports so you can see what’s happening with email that claims to be from your domain.

Do not start with p=reject. Even if your setup looks clean, there may be legitimate sending sources — marketing tools, CRMs, third-party platforms — that you’ve forgotten about. Moving to reject before you understand your traffic will block those sends and create support problems you didn’t expect.

Step 3: Set up your reporting address

Enter an email address or a dedicated DMARC reporting service address in the rua field. This is where your aggregate reports will be delivered.

DMARC aggregate reports arrive as XML files — readable but not pretty. If you’re going to actually use the data, consider a DMARC reporting service (there are free options) that parses the XML and presents it as a readable dashboard. The raw reports are hard to interpret without tooling.

Step 4: Copy the generated record

The free DMARC generator produces a formatted TXT record string. Copy it exactly — the syntax has to be precise, and any modification to the generated output could break it.

The record will look something like this:

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

Step 5: Publish the record in your DNS

Log into your DNS management interface — wherever your domain’s DNS is managed (Cloudflare, GoDaddy, Namecheap, your hosting provider, etc.).

Add a new TXT record with these settings:

• Host/Name: _dmarc (your DNS provider may add the domain automatically, or you may need to enter _dmarc.yourdomain.com)
• Type: TXT
• Value: the full record string you copied from the generator
• TTL: 3600 (1 hour) is fine to start

Save the record. DNS propagation can take up to 48 hours, but usually completes within a few hours.

Step 6: Verify the record is live

Use a DMARC lookup tool — MXToolbox DMARC lookup, Google Admin Toolbox, or similar — to confirm the record is published and readable. Paste in your domain and check that the tool returns the record you just published with the correct values.

If the lookup returns nothing or returns an error, check the Host/Name field in your DNS. The most common mistake is entering _dmarc.yourdomain.com in a field that already appends the domain, resulting in _dmarc.yourdomain.com.yourdomain.com.

Step 7: Monitor for 2–4 weeks before moving to enforcement

Leave p=none in place and let the reports accumulate. After 2–4 weeks, review your aggregate reports and look for:

• Which sources are sending email from your domain
• Whether those sources are passing SPF and DKIM
• Whether there are any unexpected sending sources — tools or services you didn’t know were sending as your domain

Once you’re confident all your legitimate sends are passing, you can move to p=quarantine and eventually p=reject.

Reading your DMARC reports

DMARC aggregate reports are XML files that receiving mail servers send to your reporting address daily. They contain records of every email that claimed to be from your domain, grouped by sending IP.

Each record shows:

• The sending IP address
• How many messages were sent from that IP
• Whether SPF passed or failed
• Whether DKIM passed or failed
• What the DMARC result was
• What action was taken (none, quarantine, or reject)

What you’re looking for in the first few weeks:

• Your own sending sources — Your primary mail server, your email marketing platform, your CRM, any third-party tools that send on your behalf. These should all be passing SPF and DKIM. If any are failing, investigate why before moving to enforcement.
• Unexpected sending sources — IPs you don’t recognize sending email claiming to be from your domain. Some of these will be legitimate (a tool you forgot about). Others will be spoofing attempts. Your DMARC policy determines what happens to the latter once you move past p=none.

If reading raw XML isn’t practical, connect your reporting address to a DMARC monitoring service. Most offer a free tier that covers basic visibility.

Who needs a DMARC record?

Anyone who owns a domain and sends email from it. But the urgency level varies:

Best practices

• Always start with p=none — Monitor first, enforce later. Jumping straight to p=reject without understanding your sending sources is how you accidentally block your own email.
• Set up reporting before you publish — A DMARC record without a reporting address is blind. Set up the rua address before you publish so you start collecting data immediately.
• Use a reporting service for readability — Raw XML aggregate reports are hard to work with. A free DMARC reporting service turns them into readable dashboards that make the monitoring phase practical.
• Fix SPF and DKIM before enabling DMARC — DMARC is only as good as the authentication it relies on. If SPF or DKIM is broken or incomplete, sort those first.
• Move to enforcement gradually — Go from p=none to p=quarantine to p=reject. Use pct to roll out enforcement incrementally if you’re managing a large or complex email environment.
• Review reports regularly during the monitoring phase — The monitoring phase is only useful if you actually look at the data. Set a reminder to review reports weekly for the first month.
• Don’t forget subdomains — If you use subdomains for sending (mail.yourdomain.com, outreach.yourdomain.com), make sure they’re covered either by your main DMARC record or by their own records.

Full process at a glance:

Troubleshooting

My DMARC record isn’t showing up in lookups. Check the Host/Name field in your DNS entry. If your provider automatically appends your domain, entering _dmarc.yourdomain.com results in a duplicate — _dmarc.yourdomain.com.yourdomain.com — which won’t resolve correctly. Try entering just _dmarc and see if the lookup finds it.

I published DMARC but I’m not receiving any reports. Reports only get sent when email is being sent claiming to be from your domain — so if you’ve just published the record and aren’t sending yet, reports may be sparse. Also confirm the rua address is correct and the mailbox is accepting email. Some reporting services require you to add a DNS record granting them permission to receive reports on your behalf.

DMARC reports show my own emails failing. This means SPF or DKIM isn’t passing correctly for one or more of your sending sources. Pull the report data to identify which sending IPs are failing, then check whether those IPs are included in your SPF record and whether DKIM is configured for those sending sources. Don’t move to enforcement until these are resolved.

I moved to p=reject and now some of my emails aren’t being delivered. A sending source — a tool, platform, or service sending email on your behalf — isn’t passing SPF or DKIM authentication. Move back to p=quarantine or p=none temporarily, identify the failing source from your reports, fix its authentication, and then move back to enforcement.

The record the generator produced is showing a syntax error. Copy the generated record exactly, including all semicolons and spacing. Don’t modify the output manually. If your DNS interface strips characters or modifies formatting on save, try wrapping the record in quotes or using a different interface.

Conclusion

DMARC is one of those things that seems technical until you actually do it — and then it turns out to be a 15-minute job that you should have done six months ago.

The record itself is just a line of text in your DNS. A DMARC record generator handles the syntax so you don’t have to learn the format by hand. What requires care is the process: making sure SPF and DKIM are working first, starting with p=none to monitor before you enforce, and reading your reports before you move to p=reject.

Get the monitoring phase right and the enforcement phase is straightforward. Skip it and you risk blocking your own email.

Set it up today, monitor for a month, then move to enforcement. Your domain’s reputation — and your prospects’ inboxes — will be better for it.

For teams running cold email outreach at scale, Reply.io handles sequence management, deliverability monitoring, and contact verification in one place — so your technical email setup and your outbound workflow stay connected.