What is DMARC and why does it matter?

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that tells receiving mail servers what to do when they receive a message that claims to be from your domain but fails authentication checks.

Without DMARC, anyone can send email pretending to be from your domain — email spoofing. This is the technique behind most phishing attacks. DMARC stops that by letting you publish a policy that says: "if a message from my domain fails authentication, reject it."

Beyond security, DMARC also helps with deliverability. Domains with a published DMARC policy tend to have better inbox placement because providers like Gmail and Outlook treat them as more trustworthy.

DMARC works by layering on top of two existing standards:

  • SPF (Sender Policy Framework) — lists which servers are allowed to send email for your domain
  • DKIM (DomainKeys Identified Mail) — cryptographically signs your messages so receivers can verify they weren't tampered with

Both must be configured before DMARC will work properly.

Prerequisites: SPF and DKIM first

DMARC requires at least one of SPF or DKIM to pass and align with your domain's From: address. If neither is configured, DMARC will flag every message as failing, making the policy ineffective.

⚠️
Don't skip this: Publishing a DMARC record with p=reject before your SPF or DKIM is set up will cause your legitimate email to be rejected. Always start with p=none and check reports before enforcing.

1 Verify your SPF record

SPF is a DNS TXT record at your root domain (yourdomain.com) that lists allowed sending servers. Look it up with any DNS lookup tool or run:

Terminal
dig TXT yourdomain.com +short

You're looking for a record that starts with v=spf1. A typical SPF record looks like:

DNS TXT record — yourdomain.com
v=spf1 include:_spf.google.com include:sendgrid.net ~all

The include: tags list the services allowed to send for your domain. The ~all at the end means "softfail" anything not listed. Use -all (hardfail) once you're confident the list is complete. If you don't have an SPF record, add one to your DNS before proceeding.

2 Verify your DKIM record

DKIM records live at a selector subdomain under _domainkey. The selector name is set by your email provider (for example, Google Workspace uses google._domainkey). Check with your email provider's documentation for the correct selector, then verify:

Terminal
dig TXT google._domainkey.yourdomain.com +short

A valid DKIM record returns a long string starting with v=DKIM1; k=rsa; p=.... If you get no result, DKIM isn't set up — follow your email provider's setup guide to publish the DKIM record they provide.

3 Create your DMARC DNS record

A DMARC record is a TXT record published at _dmarc.yourdomain.com. Here is the minimum viable DMARC record to start with:

DNS TXT record — _dmarc.yourdomain.com
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Let's break down each tag:

  • v=DMARC1 — Required. Identifies this as a DMARC record.
  • p=none — The policy. none means "monitor only — don't take action on failing messages." This is safe to start with.
  • rua=mailto:... — Where to send aggregate (daily summary) reports. Use an address you actually check.

Understanding DMARC policies

The p= tag controls what receivers do with messages that fail DMARC. There are three values:

  • p=none — No action. Messages are delivered normally; you receive reports. Start here.
  • p=quarantine — Failing messages are sent to the spam/junk folder. Move here after 2–4 weeks of reviewing reports.
  • p=reject — Failing messages are rejected outright, never delivered. Use this as the end goal once all your legitimate senders are aligned.
💡
Best practice: Always move through none → quarantine → reject over 4–8 weeks, not straight to reject. Skipping steps will block legitimate email you forgot was being sent on your behalf.

Optional: add subdomain policy and reporting percentage

A more complete record might look like:

DNS TXT record — _dmarc.yourdomain.com (extended)
v=DMARC1; p=none; sp=none; pct=100; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; adkim=r; aspf=r
  • sp=none — Policy for subdomains (can differ from the root domain policy)
  • pct=100 — Apply the policy to 100% of failing messages (default; lower during testing if needed)
  • ruf=mailto:... — Failure reports (forensic reports, less common, may reveal sensitive content)
  • adkim=r — DKIM identifier alignment: r (relaxed, allows subdomains) or s (strict)
  • aspf=r — SPF identifier alignment: relaxed or strict

4 Set up a DMARC report mailbox

The rua address receives daily XML reports from every major email receiver (Gmail, Outlook, Yahoo, etc.). These XML files tell you exactly which sources are sending email for your domain and whether they're passing authentication.

You have two options for receiving and reading these reports:

  • Manual — Use any email address you control. The reports arrive as XML attachments (often gzipped). You'll need to parse them yourself or with a tool.
  • Automatic with uinbx — uinbx automatically polls your DMARC report mailbox, parses the XML files, and shows you a live compliance dashboard. No manual parsing needed. Learn how DMARC monitoring works in uinbx →
💡
If you use uinbx, set rua=mailto:dmarc@yourdmarc-mailbox.com where that address is connected to your uinbx workspace. uinbx handles the rest automatically — parsing, classification, and trend tracking.

5 Publish the record and verify

Log in to your DNS provider (Cloudflare, Route 53, GoDaddy, Namecheap, etc.) and add a new TXT record:

  • Name / Host: _dmarc (some providers auto-append your domain)
  • Type: TXT
  • Value: v=DMARC1; p=none; rua=mailto:your-report-address@yourdomain.com
  • TTL: 3600 (1 hour) to start; you can increase after it's stable

DNS changes typically propagate within minutes but can take up to 48 hours. Verify it's live:

Terminal
dig TXT _dmarc.yourdomain.com +short

You should see your DMARC record returned. If not, wait and try again — propagation may be incomplete.

6 Monitor reports and tighten policy

Once the record is published, receiving mail servers will start sending daily aggregate reports to your RUA address within 24–48 hours. Each report covers a 24-hour window and lists:

  • Every IP address that sent email claiming to be from your domain
  • How many messages each source sent
  • Whether SPF and DKIM passed for those messages
  • Whether the overall DMARC result was pass or fail

Look for unexpected senders — these are either services you forgot were sending email for your domain (marketing tools, CRMs, transactional email providers) or attackers spoofing your address. For legitimate services that are failing, configure SPF/DKIM for those services. For unknown senders, note them — once you move to p=reject, they'll be blocked.

The path to full enforcement

  • Weeks 1–2: Monitor with p=none. Identify all legitimate senders. Fix any that are failing authentication.
  • Weeks 3–4: Move to p=quarantine. Watch your inbox for false positives (legitimate email in spam). Fix any remaining issues.
  • Week 5+: Move to p=reject. Your domain is now fully protected from spoofing.

Skip the XML parsing — use uinbx DMARC monitoring

uinbx automatically ingests your DMARC reports, parses them, and shows you a live compliance dashboard — compliant senders, failing senders, and trend over time. No spreadsheets, no XML.

Start free — no credit card required

Frequently asked questions

What is a DMARC record?

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com that tells email receivers what to do when they receive a message claiming to be from your domain but failing SPF or DKIM authentication. It also tells receivers where to send aggregate reports about email activity on your domain.

Do I need SPF and DKIM before setting up DMARC?

Yes. DMARC relies on SPF and DKIM to authenticate messages. At least one of them must pass and align with your From domain for a message to pass DMARC. Verify both are correctly configured before publishing your DMARC record.

What DMARC policy should I start with?

Always start with p=none. This tells receivers to take no action on failing messages but still send you reports. Monitor for 2–4 weeks, review which senders are failing, then move to p=quarantine and eventually p=reject once you're confident all your legitimate senders are aligned.

How do I read DMARC reports?

DMARC aggregate reports are gzipped XML files. The raw format is hard to read manually. Use a DMARC monitoring tool like uinbx to automatically parse and visualize them, or a standalone parser if you prefer the raw data.

How long does DMARC take to set up?

Publishing the DNS record takes under 10 minutes. Getting to full p=reject enforcement typically takes 4–8 weeks of monitoring and iterating on your sending configuration.