How to Set Up DMARC Policy to Protect Your Domain

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is how you stop attackers from spoofing your domain. Without a DMARC policy, anyone can send email that looks like it came from you. That hurts your ability to deliver messages your customers actually trust. Here is how to set up a DMARC policy that protects your domain without breaking legitimate email flow.

What is a DMARC policy and why do you need one?

DMARC builds on SPF and DKIM. It tells receiving mail servers what to do when an email fails those checks. You set a policy — none, quarantine, or reject — and receivers follow it. DMARC also gives you reports about who is sending email using your domain.

Without DMARC, a phisher can send email from your CEO’s address. Your customers get tricked. Your domain reputation drops. Even legitimate email from you can land in spam. A DMARC policy forces senders to authenticate, and it lets you see the whole picture.

Before you start: Prerequisites

You need SPF and DKIM already working. DMARC uses them to check alignment. If SPF or DKIM misconfigured, DMARC will flag your own email. If you haven’t set them up yet, fix that first.

You also need access to your domain’s DNS management. You will add a TXT record. And you need an email address to receive DMARC aggregate reports — usually something like dmarc@yourdomain.com.

Step 1: Publish a DMARC record with p=none

Your first DMARC record should have a policy of “none.” This tells receivers to take no action on failing email. They still deliver it. But you start getting reports about what’s being sent from your domain.

Here is what the record looks like:

_dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; pct=100"

Breaking it down:

• v=DMARC1 — version tag, always required.
• p=none — policy for none, quarantine, or reject. Start here.
• rua — email address for aggregate reports (XML format).
• ruf — email address for forensic reports (use same or separate).
• pct=100 — percentage of email the policy applies to. Keep at 100.

Aggregate reports come daily or weekly from major receivers (Google, Yahoo, Microsoft). They show the volume of email, authentication results, and source IPs. You need to parse these reports to understand your sending ecosystem.

Step 2: Analyze DMARC reports

DMARC reports are XML files. Most people use a third-party tool to parse them. But you can also use open-source parsers. The goal is to find every source of email coming from your domain.

Common sources include:

• Your primary email platform (Gmail, Outlook, etc.)
• Marketing email services (Mailchimp, HubSpot, etc.)
• Transactional email services (SendGrid, AWS SES, etc.)
• CRMs and other third-party apps
• Your own on-premise mail servers

For each source, check whether SPF and DKIM pass and whether they align with your domain. Alignment means the domain in the From header matches the domain in SPF or DKIM. If a source fails alignment, you need to fix either the sending infrastructure or your SPF/DKIM records.

Step 3: Fix failing sources

When a source fails DMARC, you have two options:

• Add its IP to your SPF record (if it uses envelope sender with your domain)
• Configure DKIM signing for that service with your domain

Many third-party services have documentation on how to set up DKIM. For example, a marketing email service will give you a DKIM key to add to your DNS. Once set, that service signs emails with your domain, and DMARC passes.

If a source cannot be fixed — for instance, a legacy system you are phasing out — you may need to stop using it or migrate to an authenticated alternative. The goal is to have every email from your domain pass both SPF and DKIM alignment.

Step 4: Tighten policy to p=quarantine

Once you have confirmed that all legitimate email sources pass DMARC, change your policy to quarantine. This tells receivers to send failing email to the spam folder instead of the inbox.

_dmarc.yourdomain.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; pct=100"

Keep monitoring reports. You may discover new sources you missed. Some senders only emerge after you tighten the policy. Stay at quarantine for at least a week.

Step 5: Enforce with p=reject

p=reject is the strongest policy. It tells receivers to block all email that fails DMARC entirely. This is the gold standard. Attackers cannot spoof your domain because their email will be rejected.

_dmarc.yourdomain.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; pct=100"

Before moving to reject, make absolutely certain you have covered every legitimate source. A missed source will stop delivering email to your customers. That includes internal email, marketing, and transactional messages.

Common mistakes and how to avoid them

Skipping p=none. Jumping straight to reject is risky. You will break something and not know why. Always start with monitoring.

Not checking subdomains. DMARC policies can apply to subdomains via the sp tag. If you do not set it, the main policy applies. Be intentional about subdomain email.

Using a single email for reports that gets overwhelmed. Aggregate reports can be large. Use a dedicated mailbox or a service that can handle XML processing. Do not use a personal inbox.

Forgetting the pct tag. You can start with pct=10 to test impact on only 10% of email. But that adds complexity. Most people use 100 from the start.

Comparison of DMARC policies

Policy	Action on failed DMARC	Use case
p=none	Deliver normally	Monitoring, initial setup
p=quarantine	Send to spam	Intermediate after fixing issues
p=reject	Block entirely	Full protection, final goal

Each step reduces the risk of spoofing while giving you time to fix problems. The whole process can take weeks to months depending on the complexity of your email infrastructure.

What about DMARC reports for subdomains?

Subdomains need attention too. You can set a separate DMARC record on each subdomain, or use the sp tag in the main record to apply a policy to all subdomains. The sp tag value can be none, quarantine, or reject. If you omit it, subdomains inherit the main policy.

Many companies start with p=none on subdomains to discover what sends from them. Then they tighten. If you do not send email from subdomains at all, setting p=reject for them is a good security practice.

Maintaining your DMARC policy

Setting DMARC is not a one-time task. New email sources appear as you add services. Continue to monitor reports regularly. Check for new IPs or domains that fail authentication. Adjust SPF, DKIM, and DMARC records as needed.

Also review your report email inbox for forensic reports. They contain details on individual failures. They can help you spot phishing attempts early.

Finally, coordinate with your team. If a marketing team signs up for a new email tool without telling IT, that service might not be authenticated. Build a process for adding new sending services so authentication is set up from day one.

For more on email authentication fundamentals, read our guide on Email Deliverability: A Beginner’s Guide for B2B Marketers. And if you run into common pitfalls, check out Common Email Authentication Mistakes That Hurt Deliverability. For step-by-step SPF setup, see How to Set Up SPF Records Without Breaking Email.

DMARC is the final layer that makes SPF and DKIM work for protection. Setting it up correctly reduces spoofing risk and protects your domain reputation. Take it slow, monitor, and tighten gradually. Your domain will thank you.

Frequently asked questions

Do I need both SPF and DKIM before setting up DMARC?

Yes. DMARC uses SPF and DKIM to verify email. If you do not have both set up, DMARC will not work properly because it checks alignment against those records. Configure SPF and DKIM first, then add DMARC.

What does the pct tag in DMARC do?

The pct tag controls the percentage of email to which the policy applies. For example, pct=50 means only half your email is subject to the policy. It is useful for testing, but most administrators use pct=100 from the start to get full coverage.

How often should I check DMARC reports?

Check aggregate reports at least once a week during the initial monitoring phase. After you move to p=reject, a monthly review is usually enough unless you add new email services. Rapidly growing companies may need more frequent checks.

Can DMARC reports include sensitive information?

Aggregate reports contain metadata like source IPs and volume, not the actual email content. Forensic reports include the original email headers, which may contain some sensitive data but still no body content. Use a secure mailbox and consider third-party tools to parse and anonymize.

What happens if I set p=reject and a legitimate email fails DMARC?

That email will be rejected by receiving servers — it will not be delivered to the recipient. This is why you must ensure all legitimate sources pass DMARC before moving to p=reject. Monitor reports for any unexpected failures after enforcement.