DMARC has been part of the email authentication stack since 2012, but most senders treated it as optional for years. That changed in early 2024 when Google and Yahoo announced new requirements making SPF, DKIM, and DMARC mandatory for bulk senders. Suddenly, setting up a DMARC record wasn’t a nice-to-have, it was table stakes for getting your email delivered.

Use this free DMARC record generator to build a valid DNS TXT record based on your settings. Choose your policy, add your reporting addresses, and copy the output directly into your DNS zone. No guessing the syntax.

[alterable_dmarc_record_generator]

How to use this DMARC record generator

The tool asks for a few key inputs. Here’s what each one means:

  1. Policy (p=): The core of any DMARC record. Choose none to start monitoring, quarantine to send suspicious emails to spam, or reject to block unauthenticated mail outright.
  2. Reporting address (rua=): Where aggregate reports get sent. This is the email address that receives daily summaries of authentication activity across your domain. Use it.
  3. Forensic reporting address (ruf=): Where individual failure reports go. These are more detailed but not all receivers send them due to privacy concerns.
  4. Subdomain policy (sp=): If you want a different policy for subdomains than your main domain, set it here. Useful if your subdomains have different sending setups.
  5. Non-existent subdomain policy (np=): What to do with mail from subdomains that don’t exist in DNS. Nothing legitimate comes from those, so reject is a safe choice from the start.
  6. Testing mode (t=): Set t=y to have receivers apply your policy one level down while you watch the reports. This replaces the old pct= tag, more on that below.

Once you’ve configured your settings, copy the generated record and add it as a TXT record in your DNS, on the host _dmarc.yourdomain.com.

What is a DMARC record and why does it matter?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It’s a DNS record that tells receiving mail servers what to do when an incoming message fails SPF or DKIM authentication.

Think of SPF and DKIM as the authentication checks. DMARC is the policy that acts on those results.

Without a DMARC record, even a failed authentication check might result in delivery. The receiving server has no instruction. With DMARC in place, you’re telling Gmail, Outlook, and every other provider: “If this email doesn’t pass authentication, here’s exactly what to do with it.”

That’s meaningful for two reasons. First, it protects your domain from being spoofed. If someone tries to send phishing emails pretending to be you, a p=reject policy stops those emails from reaching inboxes. Second, it builds your domain’s authentication reputation over time, which matters for deliverability.

We’ve seen senders skip DMARC entirely because they had SPF and DKIM configured and figured they were done. They weren’t. The authentication triangle only closes when all three are in place.

Understanding DMARC policy levels

p=none: Start here.

Monitor mode. DMARC reports get sent to your rua address, but no action is taken on failing mail. This is where every sender should begin, because your first reports will almost certainly surface legitimate sending sources you forgot about: your CRM, a transactional email provider you set up years ago, a third-party form tool. None of that should fail before you know about it.

Spend a few weeks at p=none. Read the reports. Fix the gaps.

p=quarantine: The middle ground.

Emails that fail DMARC go to the spam folder instead of the inbox. It’s a softer enforcement than rejection, recipients can still find the mail if they look, but it signals to mailbox providers that you’re serious about authentication. Move here once you’re confident your legitimate sending sources are all passing.

p=reject: The gold standard.

Unauthenticated mail is rejected outright. It never reaches the recipient. This is the level Google, Microsoft, and every major security-minded organization recommends as the eventual goal.

Don’t rush to p=reject. We’ve watched senders jump straight to it and then spend two weeks troubleshooting why a critical transactional flow stopped working. The rollout exists for a reason: none → quarantine → reject, with reporting reviewed at each step.

What changed with DMARCbis (RFC 9989)

In May 2026 the IETF published RFC 9989, the first update to DMARC since 2015. The record still starts with v=DMARC1 and existing records keep working, but a few tags changed, and this generator follows the new spec.

pct= is gone. The old way to soften a rollout was to publish p=reject; pct=10 so the policy only applied to a slice of failing mail. RFC 9989 removed pct (along with rf and ri), and receivers that follow the new spec ignore tags they don’t know. That means a lowered pct no longer softens anything on those receivers. It’s enforced in full.

t=y replaces it. Testing mode tells receivers to apply the policy one level below what you published. reject is treated as quarantine, quarantine as none. Reports are unaffected, so you still see everything. It’s a cleaner version of what pct was for: publish the policy you’re aiming at, flip t=y while you verify, and remove it once the reports look clean.

np= is new. It sets the policy for subdomains that don’t exist in DNS. Since no legitimate mail comes from those, np=reject is safe to publish immediately, even while the main policy is still none.

One caveat: receivers that haven’t implemented RFC 9989 yet ignore t=y and enforce your full policy, the same way new receivers ignore pct. Treat testing mode as a safety net, not a guarantee, and keep reading the reports.

DMARC alignment: a detail worth knowing

One thing the generator handles automatically but is worth understanding: DMARC doesn’t just require SPF or DKIM to pass, it requires alignment. The domain in the From: header needs to match (or be a subdomain of) the domain used in SPF or DKIM signing.

This is why sending through an ESP that hasn’t properly configured custom authentication for your domain can cause DMARC failures even if their SPF technically passes. The alignment check is what catches that.

Relaxed alignment (the default) allows subdomain matches. Strict alignment requires an exact domain match. For most senders, relaxed is the right call.

Getting your DMARC record right is a solid first step. The next one is making sure everything else in your authentication setup is working alongside it. Our free Email Deliverability Test checks your SPF, DKIM, and DMARC configuration all at once, so you can see the full picture.

And if you send personalized campaigns through Alterable, strong domain authentication is what gives your content the best chance of reaching the inbox. It’s the infrastructure everything else sits on.