How to Set Up a DMARC Record for Your Domain

Prerequisites: SPF and DKIM

DMARC builds on two older protocols — SPF and DKIM. Without them, DMARC has nothing to evaluate. If you want to understand the principles first, read What is DMARC and How Does It Work. Before setting up your DMARC record, verify:

1. SPF record is published and includes all authorized senders. If you need background, read What is an SPF Record, then follow How to Create an SPF Record Step by Step.
2. DKIM signing is active for all services sending email from your domain. You can verify using the DKIM analyzer.

SPF and DKIM should be functioning for at least 48 hours before you publish a DMARC record — you need confidence that legitimate emails pass authentication.

Map all your email senders

Before deploying DMARC, you need a complete inventory of who sends email from your domain. A missing sender means deliverability problems once you enforce the policy.

Common senders:

• Primary email service (Google Workspace, Microsoft 365, self-hosted mail server)
• Marketing platforms (Mailchimp, HubSpot, Constant Contact)
• Helpdesk and CRM systems (Freshdesk, Zendesk, Salesforce)
• Invoicing and billing systems (QuickBooks, FreshBooks, Stripe)
• Transactional email (SendGrid, Amazon SES, Mailgun)

Each service must be included in your SPF record and configured for DKIM signing with your domain. If you're unsure which services send email on your behalf, DMARC reports will reveal exactly that — which is why you start with the monitoring policy p=none.

Build your DMARC record

A DMARC record is a TXT record in DNS published at the _dmarc subdomain. For the domain example.com, you create a record for _dmarc.example.com.

Minimum record to start

v=DMARC1; p=none; rua=mailto:example.com@rua.spfmonitor.com

The address example.com@rua.spfmonitor.com sends reports to SPF Monitor, which automatically processes, visualizes, and alerts you to issues — no need to manually parse XML files. This record tells receiving servers: "Send me reports about emails from my domain, but don't take action on them yet." The three parts:

Recommended record with extended configuration

v=DMARC1; p=none; rua=mailto:example.com@rua.spfmonitor.com; ruf=mailto:example.com@ruf.spfmonitor.com; fo=1; adkim=r; aspf=r

Extended tags:

Relaxed alignment (r) is the right choice to start with. Strict alignment (s) requires exact domain match — this can cause issues with services that send from subdomains.

Combining SPF Monitor reports with your own address

You can send reports to multiple addresses at once — separate them with a comma. This gives you automatic processing in SPF Monitor and a copy of the raw reports at your own email:

v=DMARC1; p=none; rua=mailto:example.com@rua.spfmonitor.com,mailto:dmarc@example.com; ruf=mailto:example.com@ruf.spfmonitor.com,mailto:dmarc-forensic@example.com; fo=1

Cross-domain report authorization

When the reporting address belongs to a different domain than yours (as is the case with SPF Monitor — example.com@rua.spfmonitor.com belongs to spfmonitor.com), the target domain must explicitly authorize this. SPF Monitor has this authorization configured — there's nothing for you to set up.

If you want to send reports to your own separate domain (e.g., dmarc@monitoring.com for example.com), publish a TXT record on monitoring.com:

example.com._report._dmarc.monitoring.com TXT "v=DMARC1"

Without this record, receiving servers won't send reports to an external domain — this is a protection against abuse defined in RFC 7489, Section 7.1.

Publish the record in DNS

Log into your domain's DNS management and create a new TXT record:

Watch for DNS provider specifics:

• Some providers automatically append the domain to the record name — enter just _dmarc, not _dmarc.example.com.
• Enter the record value without quotes — most panels add them automatically. Double quotes in the value cause errors.
• If the DNS panel requires selecting a record type, choose TXT.

Verify your DMARC record

After publishing, wait for DNS propagation (usually minutes to hours, up to 48 hours). Then verify:

Using our DMARC analyzer

Check your DMARC record with our analyzer — it verifies the record exists, validates syntax, checks reporting address validity, and flags potential issues.

Alternatively, using the command line

dig TXT _dmarc.example.com +short

Expected output:

"v=DMARC1; p=none; rua=mailto:example.com@rua.spfmonitor.com"

On Windows:

nslookup -type=TXT _dmarc.example.com

Analyze reports

With p=none, you'll start receiving aggregate reports (rua) within 24–72 hours from providers like Gmail, Yahoo, and Outlook. Reports arrive in XML format and contain:

• Sending server IP addresses — reveals who sends email from your domain
• SPF and DKIM check results — shows which services pass and which fail
• Alignment — whether the domain in the "From" header matches the SPF/DKIM domain

What to look for:

1. Legitimate senders failing — a service you use that's missing from your SPF record or doesn't have DKIM configured. Fix the configuration.
2. Unknown IPs passing authentication — could be a forgotten service or abuse. Investigate.
3. Unknown IPs failing — likely spoofing. These emails will be blocked once you enforce the policy.

Keep the monitoring phase (p=none) running for at least 2–4 weeks. You need to catch all senders — some services send emails only occasionally (monthly invoices, quarterly newsletters).

Tighten the policy

Once reports show that all legitimate emails pass authentication, gradually tighten the policy.

Step 1: Quarantine with gradual rollout

v=DMARC1; p=quarantine; pct=10; rua=mailto:example.com@rua.spfmonitor.com

The pct=10 tag means the quarantine policy applies to only 10% of unauthenticated emails — the remaining 90% are not subject to the stated policy. This limits the impact of any configuration mistakes.

Monitor reports. If no issues appear, increase gradually: pct=25 → pct=50 → pct=100 (or remove the pct tag entirely — the default is 100).

Step 2: Reject with gradual rollout

v=DMARC1; p=reject; pct=10; rua=mailto:example.com@rua.spfmonitor.com

The reject policy tells receiving servers to reject unauthenticated emails at the SMTP level — they won't be delivered at all. Again, start with pct=10 and increase gradually.

Step 3: Full protection

v=DMARC1; p=reject; rua=mailto:example.com@rua.spfmonitor.com; ruf=mailto:example.com@ruf.spfmonitor.com; fo=1

This is the target state. All unauthenticated emails from your domain will be rejected. Your domain is protected against spoofing and phishing.

Secure your subdomains

The DMARC record on your main domain applies to subdomains too, unless they have their own record. But without explicit configuration, subdomains can be a weak spot.

The sp= tag sets the policy for subdomains:

v=DMARC1; p=reject; sp=reject; rua=mailto:example.com@rua.spfmonitor.com

Recommended approach:

• Subdomains that send email (e.g., newsletter.example.com) — set up a dedicated DMARC record with the appropriate policy and ensure SPF + DKIM are configured.
• Subdomains without email — sp=reject on the main domain blocks them. Attackers frequently abuse non-existent subdomains for spoofing.

Common mistakes when setting up DMARC

Skipping the monitoring phase

Deploying p=reject without prior monitoring (p=none) is the most common mistake. You risk blocking legitimate emails — invoices, notifications, or marketing campaigns — from services you forgot to include in SPF or configure for DKIM.

Missing report address

A DMARC record without rua= technically works, but you have no feedback. You can't see who sends email from your domain or whether authentication works correctly. Without reports, you can't safely tighten the policy.

Multiple DMARC records on the domain

A domain must have at most one DMARC record. If DNS contains two TXT records for _dmarc.example.com, per RFC 7489, Section 6.6.3, DMARC processing terminates — receiving servers apply no policy, as if the DMARC record didn't exist.

Syntax errors

Most common syntax issues:

• v=DMARC1 not in the first position
• Missing semicolons between tags
• Typos in tag names (e.g., p=quarintine instead of p=quarantine)
• Quotes in the record value (when the DNS panel adds them automatically)

Ignoring subdomains

Attackers can spoof emails from any subdomain of your domain. If you have p=reject on the main domain but haven't set sp=, subdomains inherit the main domain's policy. Explicitly setting sp=reject improves readability and clearly documents the domain owner's intent.

Ongoing monitoring

Setting up a DMARC record is not a one-time task. Your domain evolves — new services are added, infrastructure changes, DKIM keys rotate. Without ongoing monitoring, you'll only learn about problems when customers report undelivered emails.

Keep track of:

• DMARC reports — regularly analyze for new failures from legitimate senders
• DNS changes — after every SPF or DKIM record change, verify that DMARC authentication still works
• New sending services — when deploying a new tool (helpdesk, billing system), add its records to SPF and configure DKIM before launch

Run a complete analysis of your domain to check SPF, DKIM, and DMARC configuration in one place.