DMARC Explained: Protect Your Domain from Email Phishing

Every day, criminals send millions of emails pretending to be your company, your bank, or your domain. They forge the From address, and without the right DNS records in place, mail servers around the world have no way to know those messages are fake. DMARC — Domain-based Message Authentication, Reporting, and Conformance — is the DNS-based policy that closes that gap. It builds on SPF and DKIM to give receiving mail servers explicit instructions: if a message claims to be from your domain but fails authentication, reject it, quarantine it, or at minimum report it. This article walks through exactly how DMARC works, why it matters, and how to deploy it correctly without accidentally breaking your own email.

What DMARC Actually Does

DMARC is a TXT record you publish in DNS under the subdomain _dmarc.yourdomain.com. When a receiving mail server gets a message that claims to be from your domain, it checks that record and follows your policy. The policy is enforced only when at least one of two alignment checks passes: SPF alignment (the domain in the Return-Path matches your From domain) or DKIM alignment (the domain in the DKIM signature matches your From domain). If neither aligns, the receiver applies whatever policy you specified.

The three policy levels are:

• none — Monitor only. Messages still deliver. You receive aggregate reports but no enforcement happens.
• quarantine — Failing messages go to the spam or junk folder.
• reject — Failing messages are refused outright at the SMTP layer. They never reach the inbox.

The critical distinction between DMARC and a plain SPF record is alignment. SPF alone can pass even when the visible From address is spoofed, because SPF only validates the hidden envelope sender. DMARC closes that loophole by requiring the visible From domain to align with whatever passes authentication.

Why Your Domain Is at Risk Without DMARC

If you have no DMARC record, or a policy of p=none, anyone can send email that appears to come from your domain and most mail servers will deliver it. This is called direct-domain spoofing, and it is one of the most common vectors for business email compromise (BEC) attacks. Attackers use your brand reputation to trick your customers, partners, or employees into clicking malicious links, wiring money, or handing over credentials. The attack requires zero access to your systems — just a mail server and your domain name in the From field.

Google and Yahoo now require a DMARC policy for bulk senders, and Microsoft's Outlook has tightened its filtering against unauthenticated mail. Beyond deliverability, the regulatory and reputational damage from a successful spoofing campaign against your domain can be severe. Publishing a DMARC record at even the p=none level gives you visibility into who is sending mail claiming to be you, which is the essential first step.

Prerequisites: SPF and DKIM Must Be in Place First

DMARC cannot do its job if SPF and DKIM are not already configured and passing. Before you publish a DMARC record, confirm both are working.

Check Your SPF Record

Your SPF record is a TXT record on your bare domain that lists all the servers authorized to send mail on your behalf. A typical SPF record looks like this:

The ~all (softfail) is fine for now, but once DMARC is at p=reject, consider changing it to -all (hardfail) to signal explicit rejection. Use our DNS Lookup tool to query your TXT records and verify your SPF record is published and syntactically correct before moving on.

Check Your DKIM Record

DKIM adds a cryptographic signature to outgoing messages. Your mail provider generates a key pair; you publish the public key as a TXT record at a selector subdomain, typically something like google._domainkey.yourdomain.com or s1._domainkey.yourdomain.com. Confirm with your email platform (Google Workspace, Microsoft 365, Mailchimp, SendGrid, etc.) that DKIM signing is enabled and the DNS record is live.

Building Your DMARC Record Step by Step

A DMARC record is a TXT record with specific tag-value pairs. Here is a minimal starting record:

Break that down:

• v=DMARC1 — Required. Identifies this as a DMARC record.
• p=none — Policy: monitor only, no enforcement yet.
• rua=mailto: — Aggregate report destination. You will receive daily XML summary reports from every major mail provider showing authentication results for mail claiming to be from your domain.

Additional tags you should know:

• ruf=mailto: — Forensic (failure) reports. Individual message-level reports sent on every DMARC failure. Not all providers send these, and they can contain sensitive message content, so use with caution.
• pct= — Percentage of messages subject to the policy. Defaults to 100. Setting pct=10 during a rollout applies enforcement to only 10% of failing mail, reducing risk.
• sp= — Subdomains policy. If you want a different policy for mail from subdomains, set this separately. Example: sp=reject.
• adkim= — DKIM alignment mode. r (relaxed, default) or s (strict). Relaxed allows a subdomain match; strict requires an exact domain match.
• aspf= — SPF alignment mode. Same relaxed/strict options.

Deploying DMARC: A Phased Rollout

Jumping straight to p=reject is the fastest way to accidentally block your own legitimate mail. A phased approach protects you during the discovery process.

Phase 1: Monitor (Weeks 1 to 4)

Publish p=none with an aggregate report address. For the first few weeks, do nothing except read the reports. The reports arrive as gzip-compressed XML files — use a DMARC report processor (Postmark's free DMARC analyzer, dmarcian, or Valimail) to parse them into readable dashboards. Look for:

• All legitimate sending sources your organization uses (CRM, marketing platform, ticketing system, payroll notifications)
• Any sources that are failing SPF or DKIM alignment
• Third-party services sending on your behalf that you forgot about

Phase 2: Quarantine (Weeks 4 to 8)

Once you have authorized all legitimate senders in your SPF record and confirmed DKIM is signing correctly for each, move to quarantine. Start with a low percentage to limit blast radius:

Watch your reports for the next week. If legitimate mail is not landing in quarantine and your report data looks clean, increase pct progressively — 25, 50, 100.

Phase 3: Reject (Week 8 and Beyond)

Full enforcement. Spoofed messages claiming to come from your domain are rejected at the SMTP connection. Legitimate mail from properly configured senders is unaffected.

This is the goal. A DMARC record at p=reject makes direct-domain spoofing of your brand effectively impossible against major mail providers.

Publishing the Record in Your DNS Zone

How you add the record depends on your DNS host or registrar, but the fields are always the same.

1. Log in to your DNS management interface (Cloudflare, Route 53, GoDaddy, Namecheap, cPanel, etc.).
2. Create a new TXT record.
3. Set the Name/Host field to _dmarc (your provider may auto-append the domain, or you may need to enter _dmarc.yourdomain.com — check their documentation).
4. Paste your DMARC policy string into the Value/Content field.
5. Set TTL to 3600 (1 hour) while testing; you can increase it later.
6. Save the record.

How to Verify DMARC Is Working

Verification has two layers: confirming the record exists in DNS, and confirming that actual mail is passing authentication end to end.

DNS Verification

Run a dig or nslookup command from any machine:

You should see your policy string returned. If you get no response, the record is either not published yet, the hostname is wrong, or propagation is still in progress.

Send a Test Message

Send an email from each of your sending platforms to a Gmail or Outlook account you control. Open the message and view the original headers. Look for the Authentication-Results header:

All three — dkim, spf, and dmarc — should show pass. If dmarc shows fail with a disposition of none (because you are still in p=none), that is expected and tells you enforcement would have triggered. Investigate which alignment is failing and fix the upstream SPF or DKIM configuration before advancing to quarantine.

Common DMARC Mistakes to Avoid

• Skipping the monitor phase. Publishing p=reject immediately without knowing all your sending sources will block legitimate transactional emails, HR notifications, and third-party SaaS tools that send on your behalf.
• Forgetting third-party senders. Platforms like Salesforce, HubSpot, Zendesk, and Mailchimp often send mail From your domain. Each needs either an SPF include or its own DKIM signing setup. Check your aggregate reports carefully.
• Pointing rua to an external domain without authorization. If your reports go to dmarc@reportingservice.com rather than an address on your own domain, the reporting service's domain must publish a DNS record authorizing your domain to send reports there. This is the DMARC external destination verification record at yourdomain.com._report._dmarc.reportingservice.com. Most commercial DMARC platforms handle this for you automatically.
• Multiple DMARC records. You can only have one DMARC record per domain. Multiple TXT records at _dmarc will cause DMARC processing to fail entirely.
• Ignoring subdomain policy. If users send mail from marketing.yourdomain.com, the parent domain DMARC policy applies by default. Be explicit with sp= if subdomains have different needs.

DMARC for Domains That Never Send Email

If you own a domain that is purely used for a website or brand protection and never sends email, you still need a DMARC record — one that tells the world no legitimate mail should ever come from this domain:

Pair this with an SPF record of v=spf1 -all and a null MX record (0 .) to fully close the door on spoofing attempts.

Staying on Top of Your DMARC Health

DMARC is not a set-it-and-forget-it control. Your sending environment changes — new marketing tools are added, email providers are switched, developers build notification systems. Any change to your mail infrastructure can break alignment and cause legitimate mail to fail DMARC silently. Revisit your aggregate reports at least monthly. Set up alerting in your DMARC reporting platform for sudden spikes in failures, which can indicate a misconfigured new sender or an active spoofing campaign. Treat your DMARC policy as a living part of your DNS configuration, reviewed alongside SPF and DKIM whenever your email stack changes.

Reaching p=reject with clean reports across all your sending sources is one of the highest-impact, lowest-cost security improvements available to any domain owner. The investment is a few hours of setup and a few weeks of monitoring — and the payoff is eliminating an entire class of phishing attack that targets your brand and your users.