What is DMARC? A Complete Setup Guide for Beginners

What Is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. It is an email authentication protocol that gives domain owners a way to control what happens to emails that fail authentication checks. Published as a simple DNS TXT record, DMARC tells receiving mail servers how to handle messages that claim to come from your domain but don't pass SPF or DKIM verification.

Before DMARC, even if you had perfectly configured SPF and DKIM records, each receiving mail server decided independently whether to accept, quarantine, or reject unauthenticated email. This inconsistency meant that phishers could still spoof your domain, and some recipients would see those fake emails while others blocked them. DMARC eliminated that inconsistency by letting you — the domain owner — set the policy.

DMARC was standardized in 2012 as RFC 7489 and has since been adopted by every major email provider. Gmail, Yahoo, Microsoft 365, and others now check DMARC records on every inbound message, and domains without a DMARC policy are increasingly treated as suspicious.

Why DMARC Matters

Email spoofing is trivially easy to execute. The SMTP protocol, which powers email delivery, includes no built-in mechanism to verify that the sender's address in the "From" field is legitimate. Any attacker can forge your domain name and send emails that look like they came from your CEO, your IT department, or your customer support team.

These spoofed emails are the backbone of:

• Business Email Compromise (BEC) — Attackers impersonate executives to trick employees into wiring funds or sharing sensitive data. The FBI's 2023 Internet Crime Report recorded over $2.9 billion in BEC losses.
• Phishing campaigns — Spoofed emails from trusted brands like PayPal, Amazon, or Microsoft trick recipients into entering credentials on fake login pages.
• Brand impersonation — Attackers send emails pretending to be your company to your own customers, damaging trust and leading to data breaches.

DMARC stops these attacks by giving receiving servers a clear, authoritative instruction: when an email fails authentication, quarantine it or reject it. Without DMARC, your domain can be impersonated with impunity and you may never know it's happening.

How DMARC Works: The Three Policy Levels

A DMARC record is a DNS TXT record at _dmarc.yourdomain.com. It contains a policy directive (p=) that sets the action for emails that fail authentication. There are exactly three policy levels, each representing a step toward maximum protection.

p=none — Monitor Only

p=none tells receiving servers to take no action against unauthenticated email. The message is delivered normally, but the server sends you a report about it. This is the starting point for every DMARC implementation — it lets you see who is sending email as your domain without risking any disruption to legitimate email delivery.

Use p=none for the first 1-2 weeks while you gather data. The reports you receive will show every server that sends email claiming to be from your domain, including legitimate services you may have forgotten to authorize in your SPF or DKIM configuration.

p=quarantine — Send to Spam

p=quarantine instructs receiving servers to route unauthenticated messages to the recipient's spam or junk folder. The email isn't blocked entirely, but it's isolated where most users won't see it.

This is the intermediate step after you've reviewed your p=none reports and added any missing legitimate senders to your SPF and DKIM configurations. Quarantine gives you an additional safety net — if you missed a legitimate sender, the email still reaches the recipient (just in spam) while you fix the gap.

p=reject — Block Completely

p=reject is the strongest DMARC policy. It tells receiving servers to block unauthenticated email entirely — the message is not delivered at all. This is the end goal for every domain.

With p=reject, spoofed emails never reach recipients. Not their inbox, not their spam folder — they are rejected at the server level. This is the standard required by the UK's NCSC, the Australian Signals Directorate, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) for government domains.

Additional DMARC Tags

Beyond the policy directive, a DMARC record includes several optional tags that fine-tune its behavior:

• rua — Email address(es) for aggregate reports (daily XML summaries of authentication results)
• ruf — Email address(es) for forensic reports (detailed data on individual failures)
• sp — Policy for subdomains (separate from the main domain policy)
• adkim — DKIM alignment mode (strict or relaxed)
• aspf — SPF alignment mode (strict or relaxed)
• pct — Percentage of messages to filter (default 100)

Example DMARC record:v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=r; aspf=r

DMARC vs. SPF vs. DKIM — What's the Difference?

A common point of confusion is how DMARC relates to SPF and DKIM. The simplest way to understand it is as a three-layer system:

1. SPF (Sender Policy Framework) checks the envelope — it verifies the sending server's IP address is authorized. Think of it as the guest list at the door.
2. DKIM (DomainKeys Identified Mail) checks the content — it uses cryptographic signatures to verify the email wasn't tampered with. Think of it as a tamper-proof seal.
3. DMARC is the policy that ties them together — it tells the receiver what to do if the guest list check or the tamper seal check fails. It also enforces identifier alignment, meaning the domain in the "From" address must match the domains checked by SPF and DKIM.

SPF and DKIM are prerequisites for DMARC. You cannot publish a meaningful DMARC policy without having both SPF and DKIM configured first. DMARC doesn't replace them — it builds on them.

For DMARC to pass, either SPF or DKIM must pass and the domain used must align with the "From" address domain. This is why configuring all three is essential: if SPF breaks (e.g., on forwarded email), DKIM can still pass DMARC, and vice versa.

Step-by-Step DMARC Setup Guide

Setting up DMARC involves publishing a single DNS TXT record, but the preparation and monitoring that surrounds it is what determines success. Follow these steps carefully.

Prerequisites: SPF and DKIM

Before adding DMARC, confirm that your domain has working SPF and DKIM records. Without both, DMARC has nothing to check. Use our SPF/DKIM/DMARC Record Viewer to check your current configuration.

Step 1: Set Up a Dedicated DMARC Email Address

DMARC reports are sent as XML files to the email address you specify in the rua tag. Create a dedicated mailbox like [email protected] to receive these reports. Many organizations use a free DMARC analysis service instead, which parses the XML and provides a dashboard.

Step 2: Publish a p=none DMARC Record

Add the following DNS TXT record at _dmarc.yourdomain.com:

This record sets your policy to monitor-only and asks receiving servers to send aggregate reports to your DMARC mailbox. The pct=100 tag means 100% of messages are evaluated (you can lower this during testing, but starting at 100% is standard).

After adding the record, wait for DNS propagation (a few minutes to 48 hours, depending on your DNS provider's TTL settings). Use our DMARC Analyzer to verify your record is live and correctly formatted.

Step 3: Monitor Reports (1-2 Weeks)

During the monitoring phase, you'll receive daily aggregate reports from participating receivers (Gmail, Yahoo, Microsoft, etc.). These reports contain:

• The IP addresses of servers sending email as your domain
• Whether each message passed SPF, DKIM, or both
• The volume of messages from each source
• The DMARC disposition (none, quarantine, or reject) applied

Look for legitimate senders that are failing authentication. Common discoveries include forgotten marketing platforms, HR systems, expense reporting tools, and customer portals. Add each missing sender to your SPF record and configure DKIM for them before progressing to stricter policies.

Step 4: Progress to p=quarantine

Once you've identified and fixed all legitimate senders, update your DMARC record to quarantine mode:

At this stage, unauthenticated email goes to spam instead of the inbox. Monitor for another 1-2 weeks. Check that no legitimate email is being quarantined. If you see a legitimate sender failing authentication, fix their configuration before moving to the next step.

Step 5: Enforce with p=reject

When you're confident all legitimate senders are properly authenticated, update to the strongest policy:

This record sets p=reject for the main domain and sp=reject for all subdomains, with relaxed alignment for both DKIM and SPF. Spoofed emails will now be blocked at the server level — they never reach the recipient.

Step 6: Add Subdomain Policy (sp= Tag)

The sp= tag lets you set a separate DMARC policy for subdomains. If you don't include it, subdomains inherit the main domain's policy. Setting sp=reject ensures that attackers can't spoof subdomains you haven't configured yet. This is especially important if you use subdomains for marketing campaigns, landing pages, or third-party services.

Common Pitfalls and How to Avoid Them

Pitfall 1: DMARC Without SPF or DKIM

The most common mistake is publishing a DMARC record without having SPF and DKIM configured first. DMARC doesn't authenticate anything by itself — it only acts on the results of SPF and DKIM checks. Without those, your DMARC record does nothing. Always verify SPF and DKIM are working before adding DMARC.

Pitfall 2: Skipping the Monitoring Phase

Going straight to p=reject without monitoring is the fastest way to break your email delivery. You will inevitably discover services you forgot to authorize — and those password reset emails, invoices, and customer notifications will be silently blocked. Always start with p=none, review reports for at least a week, then progress gradually.

Pitfall 3: Misconfigured Identifier Alignment

DMARC requires that the domain in the "From" header aligns with the domain checked by SPF or DKIM. If you use a subdomain in your "From" address but your SPF and DKIM are configured for the parent domain, DMARC will fail. Use the adkim and aspf tags to control alignment strictness: r (relaxed, default) allows subdomain matches, while s (strict) requires an exact match.

Pitfall 4: Forgetting About Third-Party Senders

It's easy to remember your main email provider (Google Workspace or Microsoft 365) but forget the other services that send email as your domain. Common overlooked sources include marketing platforms (Mailchimp, Constant Contact, Klaviyo), transactional email services (SendGrid, Amazon SES, Mailgun), CRM systems (HubSpot, Salesforce), and IT monitoring tools (PagerDuty, Datadog). Your DMARC reports at p=none will reveal every source — use that data.

Pitfall 5: Not Setting a Subdomain Policy

If you only set p=reject for your main domain without using the sp= tag, subdomains inherit the reject policy — which sounds good, but only if you want that. If you use subdomains for services that send email (e.g., marketing.yourdomain.com), make sure those subdomains have their own SPF, DKIM, and DMARC configured. Alternatively, explicitly set sp= to the policy you want for subdomains.

Pitfall 6: Ignoring DKIM Key Rotation

When you rotate DKIM keys — which you should do periodically — publish the new public key in DNS before switching your mail server to the new private key. If you rotate the key on your mail server first, emails signed with the new key will fail DMARC until the DNS record is updated. This gap can cause several hours of authentication failures.

Tools to Check Your DMARC

BizSecurityTools provides a free suite of tools to help you set up, test, and monitor your DMARC configuration end-to-end.