How to Set Up DMARC: Step-by-Step Guide (2026)

DMARC is the most powerful email security protocol available to domain owners — and one of the most misunderstood. Without it, anyone can forge your domain and send phishing emails that appear to come from your brand. With it fully enforced, those attempts are blocked before they ever reach an inbox.

Knowing how to set up DMARC correctly is now essential for every business that sends email. Since February 2025, Google and Yahoo have required DMARC for bulk senders. Microsoft Outlook followed with enforcement in May 2026. Domains without DMARC are being filtered, flagged, and increasingly rejected. Domains with DMARC at p=reject benefit from improved inbox placement, reduced spoofing exposure, and a measurable trust signal with every major inbox provider.

This guide walks you through the complete DMARC setup process: what each component does, how to create the DNS record, how to read your reports, and how to safely progress from monitoring mode to full enforcement — without accidentally blocking your own legitimate email.

What Is DMARC and How Does It Work?

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is a DNS-based protocol that builds on top of SPF and DKIM to give domain owners three capabilities they do not have without it:

1. Policy enforcement — DMARC lets you tell receiving mail servers what to do when an email claiming to come from your domain fails authentication. The options are: do nothing (p=none), send to spam (p=quarantine), or reject outright (p=reject).

2. Alignment checking — DMARC closes the spoofing loophole that SPF and DKIM alone leave open. An attacker can craft an email that passes SPF using a different domain while displaying your domain in the visible From: header. DMARC checks that the From: domain actually aligns with the domain used in SPF or DKIM — closing that gap entirely.

3. Reporting — DMARC instructs receiving servers to send you daily XML reports showing every source that sent email using your domain, along with whether SPF and DKIM passed or failed for each source. This gives you complete visibility into your email ecosystem — including sending tools or integrations you may have forgotten about.

The DMARC, SPF, and DKIM Relationship

DMARC does not work in isolation. It requires both SPF and DKIM to be in place and passing before you can move to enforcement. Think of it this way:

• SPF answers: Is this email from an authorised server?
• DKIM answers: Does this email carry a valid cryptographic signature?
• DMARC answers: Given the above, what should I do — and where should I send the report?

An email passes DMARC if it passes SPF with alignment or DKIM with alignment. It does not need to pass both — one passing check with the correct domain alignment is sufficient. This matters in practice: email forwarding breaks SPF (the forwarding server is not on your authorised list), but if DKIM passes with alignment, DMARC still passes.

If you have not yet configured SPF and DKIM, complete those first. The SPF, DKIM, and DMARC complete guide covers all three protocols end to end.

Before You Start: Prerequisites Checklist

Complete every item on this list before creating your DMARC record. Setting up DMARC without these in place will produce reports full of failures that do not reflect your true sending state.

• SPF record published at your root domain (@) and verified as passing
• DKIM configured in Migomail (and any other sending platforms) and verified as signing
• Access to your domain's DNS management panel (Cloudflare, GoDaddy, Route 53, Namecheap, etc.)
• A dedicated email address to receive DMARC aggregate reports — e.g. dmarc-reports@yourdomain.com
• Google Postmaster Tools set up and your sending domain verified

Step 1: Understand the DMARC DNS Record Syntax

A DMARC record is a TXT record published in your domain's DNS at the exact hostname _dmarc.yourdomain.com. Here is a complete example record with every common tag:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1; adkim=r; aspf=r; pct=100; sp=none"

Tag Reference Table

The Only Two Tags You Must Have

The minimum valid DMARC record requires only v and p:

"v=DMARC1; p=none"

This is technically valid but not useful — it applies the policy and does nothing else. Always add rua so you receive aggregate reports; without reports, DMARC is blind monitoring.

Step 2: Create Your Starting DMARC Record (p=none)

The correct starting point for every new DMARC implementation is p=none — monitoring mode. This applies zero policy to failing emails but begins sending you aggregate reports so you can understand your complete email-sending landscape before you enforce anything.

Your starting record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1; adkim=r; aspf=r

How to Publish the Record in Your DNS

The process is the same across all DNS providers — the interface labels differ but the steps are identical.

Step 2a — Log in to your DNS provider Access your domain's DNS management panel. Common providers: Cloudflare (DNS → Records), GoDaddy (DNS Management → DNS Records), Amazon Route 53 (Hosted Zones → Record Sets), Namecheap (Advanced DNS).

Step 2b — Add a new TXT record

Step 2c — Save and wait for propagation DNS propagation typically completes within 10–30 minutes but can take up to 48 hours globally. During this window, some receiving servers will see the record and others will not — this is normal.

Provider-Specific Notes

Cloudflare: Enter _dmarc in the Name field (Cloudflare appends your domain automatically). Make sure the proxy status is set to DNS Only (grey cloud) — DMARC TXT records must not be proxied.

GoDaddy: Use _dmarc as the host. The value field sometimes strips quotes — enter the record string without surrounding quotes if the interface adds them automatically.

Google Domains / Squarespace: Use _dmarc as the host. Select TXT as the type. The interface accepts the full record value as a single string.

cPanel / WHM: Navigate to Zone Editor, select your domain, click Manage, and add a TXT record with _dmarc as the name.

Step 3: Verify Your DMARC Record Is Published Correctly

Before moving forward, confirm the record is live and syntactically valid.

Option A — Command Line (fastest)

Open Terminal (Mac/Linux) or Command Prompt (Windows) and run:

nslookup -type=TXT _dmarc.yourdomain.com

Or using dig:

dig TXT _dmarc.yourdomain.com +short

A correctly published record returns your full DMARC string wrapped in quotes. If the response is empty or returns NXDOMAIN, the record has not propagated yet or was entered incorrectly.

Option B — MXToolbox

Visit mxtoolbox.com/dmarc.aspx, enter your domain, and click DMARC Lookup. The tool parses every tag, flags syntax errors, and confirms whether the record is reachable.

Option C — Send a Test Email

Send an email from your domain to a Gmail address. Open the message, click the three-dot menu → "Show original". In the Authentication-Results header, look for:

dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

dmarc=pass confirms the record is live and authenticating correctly. Note that p=NONE in this output refers to the policy level displayed in the header — it does not mean DMARC failed.

Step 4: Read and Understand Your DMARC Aggregate Reports

Aggregate reports (RUA) are the core value of running DMARC at p=none. They arrive as XML files, typically one per receiving domain per day, compressed into .zip or .gz archives. Gmail, Outlook, Yahoo, and every major inbox provider that received email using your domain during the previous day will send a report.

What the XML Report Contains

Each report tells you:

• Source IP address — the server that sent the email
• Count — how many emails were sent from that IP using your domain
• SPF result — pass or fail
• DKIM result — pass or fail
• DMARC disposition — none, quarantine, or reject (what action was taken based on your current policy)
• Header from domain — the domain displayed in the From: header

What to Look For in Your Reports

In the first 1–2 weeks of monitoring, your goal is to identify every source sending email using your domain. Group your findings:

Legitimate senders that are passing — your ESP (Migomail), Google Workspace, Microsoft 365. These should show SPF pass or DKIM pass with your domain in alignment. No action needed.

Legitimate senders that are failing — a CRM, a support ticketing tool, a form tool, or a transactional email service you use but had not yet added to your SPF record or configured DKIM for. These need to be fixed before you move to enforcement — otherwise they will be affected by your DMARC policy.

Unknown or suspicious senders — IP addresses you do not recognise. These could be attackers spoofing your domain, or services you genuinely forgot about. Investigate each one before progressing to enforcement.

Using a DMARC Report Reader

Raw XML is not human-readable at scale. Migomail's hosted DMARC service automatically processes incoming aggregate reports and presents the data in a clean dashboard — showing you every sending source, pass/fail rates, volume trends, and a recommended action for each source. This removes the need to download, decompress, and parse XML files manually.

Step 5: Fix All Failing Legitimate Senders

This is the most important step — and the one most people skip too quickly.

Before moving your DMARC policy to p=quarantine or p=reject, every legitimate sending source must be passing SPF or DKIM with your domain in alignment. A single overlooked tool (a scheduling platform, a third-party CRM, a legacy email service) will have its emails quarantined or rejected once you enforce.

Common Legitimate Sources to Check

SPF Record Consolidation Warning

Each tool you add to your SPF record consumes one DNS lookup from a maximum of 10 allowed. If you have more than 6–7 sending sources, you may need to flatten your SPF record (replace include: statements with the actual IP ranges they resolve to) to stay under the 10-lookup limit. Exceeding the limit causes SPF to return permerror — which counts as a fail.

Use an SPF flattening tool or Migomail's SPF validator to check your lookup count before adding new include: statements.

Step 6: Progress to p=quarantine

Once your DMARC reports show that all legitimate senders are consistently passing (allow at least 7–14 days of clean reports), you are ready to move to p=quarantine.

Update your DMARC record by changing only the p tag:

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

What this does: Emails that fail DMARC alignment are now directed to the recipient's spam or junk folder instead of being delivered normally. Legitimate emails that are correctly authenticated are completely unaffected.

Using pct= for a Gradual Rollout

If you are cautious about moving directly to p=quarantine for 100% of failing emails, use the pct tag to apply the policy to a percentage of failing emails:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; fo=1; pct=10

This applies quarantine to only 10% of failing emails. After 3–5 days with no unexpected impact on legitimate mail, increase to pct=50, then pct=100. Note: pct only affects the policy applied to failing emails — your authenticated legitimate mail is never affected regardless of the pct value.

What to Monitor During p=quarantine

For 7–14 days after moving to quarantine:

• Check your own spam/junk folder for any legitimate emails that should not be there
• Ask your team to do the same — internal emails caught by DMARC are a sign of a misconfiguration
• Review your aggregate reports — look for any new sources that appear and are failing
• Monitor your email deliverability best practices KPIs — complaint rate, bounce rate, open rate — for any unexpected changes

Step 7: Move to p=reject — Full DMARC Enforcement

p=reject is the gold standard. Emails that fail DMARC alignment are blocked entirely — not delivered to spam, but rejected at the server level before they reach any folder. This is complete protection against domain spoofing.

Update your DMARC record one final time:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1; adkim=r; aspf=r

Move to p=reject only after:

• At least 7–14 days of clean p=quarantine monitoring with no legitimate mail caught
• All known sending sources confirmed as passing in aggregate reports
• No new unrecognised senders appearing in reports

Benefits of p=reject

• Spoofing protection: Any email failing authentication is rejected, not just filtered
• Inbox placement improvement: Major inbox providers reward domains at p=reject with higher trust scores, which improves placement for your legitimate campaigns
• Brand protection: Phishing campaigns using your domain fail before reaching any inbox
• Google and Yahoo compliance: Both providers indicate that p=reject senders receive the highest deliverability treatment

Step 8: Configure Subdomain Policy

By default, your DMARC policy at yourdomain.com does not automatically cover subdomains unless you add the sp= tag. A subdomain like mail.yourdomain.com or newsletter.yourdomain.com is evaluated independently.

Subdomain Options

Apply the same policy to all subdomains:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1

Publish a separate DMARC record for a specific subdomain:

_dmarc.newsletter.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1"

A subdomain-specific record overrides the sp= tag in the root record for that subdomain. This is the approach to use when a subdomain has its own sending infrastructure (e.g., a dedicated IP for your newsletter. subdomain that has its own warm-up schedule).

Protect parked or inactive domains: Domains you own but do not send email from should still have a strict DMARC record to prevent them from being used for spoofing:

v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r

No rua address is needed for non-sending domains — there will be no legitimate traffic to report on.

Step 9: Maintain and Monitor Ongoing

DMARC is not a set-and-forget configuration. New sending tools are added to your tech stack. DNS records expire or get accidentally modified. Attackers continuously probe domains for spoofing opportunities.

Monthly Maintenance Tasks

• Review aggregate reports for any new or unexpected sending sources
• Check SPF record lookup count — each new tool you add could push you over the limit
• Verify DKIM is still signing in all sending platforms (key rotation or platform updates can break this silently)
• Run your sending domain through Migomail's blacklist monitoring to confirm it is not listed

Annual Tasks

• Rotate DKIM keys (recommended every 6–12 months as a security best practice)
• Review all authorised sending sources — remove any tools you no longer use from your SPF record
• Re-evaluate alignment mode (relaxed vs strict) if your subdomain structure has changed

DMARC Compliance Ongoing Reporting

Migomail's hosted DMARC service provides automated weekly summaries, instant alerts for new failing sources, and a policy progression assistant that recommends when you are ready to move from one policy level to the next — based on your actual report data, not a fixed time schedule.

DMARC Setup: Complete Step-by-Step Summary

Total time from start to p=reject: 4–8 weeks for most organisations.

Common DMARC Mistakes and How to Avoid Them

Starting at p=reject without monitoring first The most damaging mistake. Without running p=none and reviewing reports, you have no visibility into which of your sending sources are failing authentication. Moving directly to p=reject can silently block password reset emails, transactional receipts, or entire CRM sequences from reaching customers.

Publishing two DMARC records for the same domain Like SPF, you can only have one DMARC record per domain (or subdomain). Two records at _dmarc.yourdomain.com produce undefined behaviour — receiving servers may use either, both, or neither. Check for duplicates with dig TXT _dmarc.yourdomain.com before publishing.

Ignoring the rua= report address The aggregate report inbox receives daily XML zip files. If you never set one up, you are running DMARC blind — applying policy without ever seeing what is being caught or passed. Even at p=none, reports are the primary source of deliverability intelligence.

Confusing DMARC pass with DMARC policy An email can show dmarc=pass in the headers while your policy is p=none. This means the email passed the authentication checks — it is not related to whether the policy is enforced. p=none does not block anything; it only monitors.

Using strict alignment too early adkim=s and aspf=s require the From: domain to exactly match the DKIM d= domain and the SPF envelope-from domain. Subdomains do not satisfy strict alignment. Using strict alignment before verifying all your sending sources can cause legitimate emails to fail DMARC even when SPF and DKIM individually pass. Start with adkim=r; aspf=r (relaxed) and move to strict only after thorough testing.

Frequently Asked Questions

What does DMARC p=none mean? p=none is DMARC monitoring mode. When your DMARC record is set to p=none, receiving mail servers take no action against emails that fail DMARC authentication — they are delivered normally regardless of whether they pass or fail. The policy instructs receiving servers to send you aggregate reports so you can see what is sending email using your domain, but it applies zero enforcement. p=none is the correct starting point for every new DMARC implementation and should be maintained for 2–4 weeks before progressing to p=quarantine.

How long does DMARC setup take? Publishing the initial DNS record takes 15–30 minutes, and the record propagates globally within 10–48 hours. The full DMARC implementation — from publishing p=none through to p=reject — takes 4–8 weeks for most organisations. The majority of that time is spent in the monitoring and fixing phases: reviewing aggregate reports to identify all sending sources, fixing any that are failing authentication, and verifying clean results before moving to enforcement.

Will setting up DMARC affect my existing email delivery? Starting at p=none has absolutely no effect on email delivery — it only enables reporting. Moving to p=quarantine or p=reject affects only emails that fail authentication alignment. Your legitimate emails, properly authenticated through SPF or DKIM, are not affected by any DMARC policy level. The risk period is moving to enforcement before all legitimate sources are authenticated — which is why thorough monitoring at p=none is mandatory before progressing.

Do I need DMARC if I already have SPF and DKIM? Yes. SPF and DKIM each address specific parts of email authentication but leave a critical gap: neither protocol checks that the From: header domain matches the authenticated domain. An attacker can craft an email that passes SPF using their own domain while displaying your domain in the visible From header — a technique called display-name spoofing. DMARC closes this gap through alignment checking. Without DMARC, your domain remains vulnerable to this type of impersonation even with perfect SPF and DKIM configuration.

What is DMARC alignment and why does it matter? DMARC alignment is the requirement that the domain in the visible From: header matches the domain used in SPF authentication (envelope-from) or DKIM signing (d= tag). This is what prevents spoofing attacks where the From: header shows your domain but the email is actually sent from a different domain. Relaxed alignment (r) allows subdomains to satisfy the check — newsletter.yourdomain.com aligns with yourdomain.com. Strict alignment (s) requires an exact domain match — newsletter.yourdomain.com does not satisfy alignment with yourdomain.com in strict mode.

Next Steps After DMARC

Once you are at p=reject, three additional protocols extend your email security stack further:

MTA-STS enforces TLS encryption for all emails delivered to your domain, preventing downgrade attacks where attackers intercept email by negotiating unencrypted delivery. It pairs with TLS-RPT for failure reporting.

BIMI (Brand Indicators for Message Identification) lets you display your verified brand logo next to your emails in Gmail and Apple Mail. It requires a p=quarantine or p=reject DMARC policy as a prerequisite, plus a Verified Mark Certificate (VMC) from a qualified issuer.

Monitoring for lookalike domains — DMARC protects your exact domain but not lookalike registrations like m1gomail.com or miigom4il.com. Brand monitoring services watch for newly registered domains that resemble yours and can trigger takedown procedures before they are used in phishing campaigns.

For a complete view of how DMARC fits into your overall sending infrastructure, read our email deliverability best practices guide or explore why emails go to spam for the full diagnosis framework.

Start your free trial to access Migomail's one-click DMARC record builder, automated aggregate report processing, and policy progression assistant — everything you need to go from p=none to p=reject in the safest, fastest path possible.