How to Create a DMARC Record: Step-by-Step Guide

Why You Need a DMARC Record

Without a DMARC record, your domain is vulnerable to spoofing. Attackers can send emails that appear to come from your organization, tricking customers and partners into revealing sensitive information. A DMARC record tells receiving mail servers exactly what to do when an email fails authentication — and sends you reports so you can monitor your domain's email traffic.

Since 2024, Google and Yahoo require all bulk senders to publish a DMARC record. Without one, your emails are more likely to land in spam or be rejected entirely. DMARC is no longer optional — it is a requirement for reliable email delivery.

If you want a deeper understanding of the protocol itself, read our complete guide to DMARC.

Understanding DMARC Tags

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. It consists of several tags that control policy, reporting, and alignment. Here is every tag you need to know:

• v — Version tag. Always set to DMARC1. This is required and must be the first tag.
• p — Policy for your domain: none (monitor only), quarantine (send to spam), or reject (block entirely).
• sp — Subdomain policy. Same options as p. If omitted, subdomains inherit the parent domain policy.
• rua — Aggregate report URI. Specifies where receiving servers send daily XML reports summarizing authentication results. Example: mailto:dmarc-reports@yourdomain.com
• ruf — Forensic report URI. Specifies where to send detailed failure reports for individual messages. Note: many providers do not support forensic reports due to privacy concerns.
• adkim — DKIM alignment mode. r (relaxed — allows subdomains) or s (strict — exact domain match required). Default is relaxed.
• aspf — SPF alignment mode. Same options as adkim. Default is relaxed.
• pct — Percentage of messages the policy applies to (1-100). Useful for gradual rollout. Default is 100.
• fo — Failure reporting options. Controls when forensic reports are generated: 0 (both SPF and DKIM fail), 1 (either fails), d (DKIM fails), s (SPF fails).

Step 1: Choose Your Policy

The most important decision is your DMARC policy. The recommended approach is a gradual progression:

1. p=none — Start here. This is monitoring mode. No emails are blocked, but you receive reports showing who is sending email on behalf of your domain. Run this for 2-4 weeks minimum.
2. p=quarantine — Once you have confirmed all legitimate senders pass authentication, move to quarantine. Failing emails go to the recipient's spam folder. Use the pct tag to start at 10-25% and gradually increase to 100%.
3. p=reject — The ultimate goal. Failing emails are blocked entirely. This gives your domain maximum protection against spoofing.

Step 2: Set Up Reporting

DMARC supports two types of reports:

• Aggregate reports (rua) — Sent daily in XML format. They summarize how many emails passed or failed SPF, DKIM, and DMARC alignment from each sending IP. This is the most important report type — always configure it.
• Forensic reports (ruf) — Sent in near real-time for individual failing messages. They contain more detail but are not supported by all providers (notably, Google does not send them). Configure if your provider supports it.

Set fo=1 to receive forensic reports when either SPF or DKIM fails (rather than only when both fail). This gives you better visibility during the monitoring phase.

Step 3: Configure Alignment

Alignment determines how strictly the domain in the From header must match the domain authenticated by SPF or DKIM. Relaxed alignment (the default) allows subdomains to match the parent domain — for example, mail sent from news.yourdomain.com would align with yourdomain.com.

Strict alignment requires an exact domain match. Use strict alignment only if you want to prevent subdomains from passing DMARC checks under the parent domain's policy. For most organizations, relaxed alignment is the right choice.

Step 4: Generate and Deploy Your DMARC Record

Use our free DMARC Generator to build your record. For a typical setup starting in monitoring mode, your record will look like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r; pct=100

Add this as a DNS TXT record with the host _dmarc at your DNS provider. DNS changes can take up to 48 hours to propagate, though most providers update within minutes.

Step 5: Monitor and Adjust

After deploying your DMARC record, actively monitor your aggregate reports. Look for legitimate senders that fail authentication and fix their SPF or DKIM configuration before tightening your policy. Common issues include third-party marketing platforms, CRM systems, or support tools that send email on your behalf without proper authentication.

A typical timeline looks like this: 2-4 weeks on p=none, then 2-4 weeks on p=quarantine with gradual pct increases, then finally p=reject at 100%.

Common DMARC Mistakes

• Skipping the monitoring phase. Going straight to p=reject without analyzing reports will block legitimate emails from services you forgot about.
• Not configuring rua reports. Without aggregate reports, you have no visibility into who is sending email as your domain.
• Publishing multiple DMARC records. Only one TXT record should exist at _dmarc.yourdomain.com. Multiple records cause unpredictable behavior.
• Forgetting subdomain policy. Without an sp tag, subdomains inherit the parent policy. Attackers frequently spoof subdomains that lack their own DMARC records.
• Ignoring third-party senders. Services like Mailchimp, SendGrid, or Zendesk need to be configured for SPF and DKIM alignment before you enforce a strict policy.
• Setting pct too low and forgetting it. If you set pct=10 during rollout, remember to increase it to 100 once you are confident.

Testing Your DMARC Record

After deploying your record, verify it with our free tools:

• DMARC Checker — Verify your DMARC record syntax, policy, alignment settings, and reporting configuration.
• SPF Checker — Validate your SPF record and ensure all authorized senders are included.
• DKIM Checker — Confirm your DKIM signatures are properly configured.