DMARC Setup Guide: Protect Your Domain From Email Spoofing

Your domain's From address is the most visible part of any email you send. It's what recipients see before opening a message, what they look at when deciding whether to trust it, and what attackers impersonate when they want to steal credentials or launch phishing campaigns. DMARC — Domain-based Message Authentication, Reporting, and Conformance — is the standard that lets you control what happens to email that fails authentication and claims to come from your domain.

Where SPF checks whether the sending server is authorized, and DKIM checks whether the message was signed by your domain, DMARC ties both of those checks to the From: header that users actually see. It's the policy layer that makes email authentication enforceable against spoofed mail.

How DMARC Works

DMARC introduces two core concepts: alignment and policy.

Alignment means that the domain in the visible From: header must match the domain used in SPF or DKIM checks. This closes the gap that would otherwise allow someone to put your real domain in the From: header while sending from a server authorized for a completely different domain.

There are two types of alignment:

• Relaxed alignment (the default): the organizational domain must match. mail.yourdomain.com aligns with yourdomain.com.
• Strict alignment: the domains must be an exact match. mail.yourdomain.com would not align with yourdomain.com.

Policy tells receiving servers what to do when a message fails the DMARC check:

• p=none — take no action; just collect and send reports
• p=quarantine — deliver to the spam or junk folder
• p=reject — reject the message outright at the SMTP level

The DMARC DNS Record

DMARC is configured as a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:forensic@yourdomain.com; pct=100

The key fields explained:

• v=DMARC1 — required; identifies this as a DMARC record
• p= — the policy (none, quarantine, or reject)
• rua= — where to send aggregate reports (daily XML summaries)
• ruf= — where to send forensic reports (samples of individual failures)
• pct= — the percentage of failing mail to apply the policy to (useful for gradual rollout)
• adkim= and aspf= — alignment mode (r for relaxed, s for strict)

Rolling Out DMARC Safely

The most common mistake with DMARC is jumping straight to p=reject without understanding your full email environment first. If you have sending sources that aren't properly authenticated — a marketing tool, a helpdesk platform, a third-party notification service — a reject policy will cause legitimate email to be silently dropped.

The safe approach is to roll out in stages:

1. Start with p=none and configure aggregate reporting. This monitors without blocking anything.
2. Collect reports for two to four weeks. DMARC aggregate reports show you exactly which sources are sending as your domain and whether they're passing authentication.
3. Fix authentication gaps. Add any missing SPF includes or DKIM selectors for legitimate senders you discover in the reports.
4. Move to p=quarantine with a low pct= value (starting around 10%) to catch any remaining issues without wide impact.
5. Gradually increase to p=reject; pct=100. Once your reports show clean authentication across all your sending sources, move to full enforcement.

Reading DMARC Aggregate Reports

DMARC aggregate reports arrive as XML files — not light reading in their raw form. Third-party DMARC report parsers turn the raw XML into readable tables showing which IPs are sending as your domain, pass and fail rates, and which authentication methods are passing or failing per source.

Even a quick monthly review of these reports is valuable. They'll show you:

• Legitimate senders you haven't authenticated yet
• Unauthorized parties attempting to send as your domain
• SPF or DKIM failures from your own sending infrastructure

If you see large volumes of failing mail from IPs you don't recognize, that's evidence of active spoofing against your domain. A DMARC quarantine or reject policy will protect your recipients from those messages immediately.

DMARC and Subdomains

Your DMARC policy covers your primary sending domain, but subdomains need separate handling. The sp= tag controls the policy for subdomains:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com

If sp= is omitted, the parent domain policy applies to subdomains as well. For organizations that use subdomains for different email types, make sure those subdomains have their own SPF and DKIM configured before applying a strict DMARC policy.

Google and Yahoo Sender Requirements

In 2024, Google and Yahoo began requiring DMARC authentication for bulk senders — defined as domains sending more than 5,000 messages per day to Gmail addresses. The requirements mandate at least p=none DMARC in place, along with SPF and DKIM alignment. These changes have made DMARC a practical necessity for any significant sender, not just a best practice for security-conscious teams.

Even if you send lower volumes today, implementing DMARC is worthwhile. It protects your domain's reputation from spoofing, gives you visibility into your full sending landscape, and positions you well as receiver-side requirements continue to evolve.

For a complete walkthrough of setting up SPF, DKIM, and DMARC together, visit the MailDog DNS security guide. The MailDog documentation includes copy-paste DNS records for each authentication layer. If you're using MailDog's SMTP infrastructure, authentication setup is streamlined through your account dashboard. Questions about the rollout process? The MailDog support team can walk you through it.