How to Set Up DMARC Properly: A Step-by-Step Guide to Moving from Monitoring to Enforcement

Why DMARC needs a rollout — not a deployment

Most technical controls are binary: either they're in place or they're not. DMARC is different. You can have a DMARC record published and still have zero protection, because the policy level determines what actually happens to mail that fails authentication. A record at p=none instructs receiving mail servers to do nothing — just send reports back. No filtering, no blocking, no quarantine.

The reason DMARC has a p=none stage at all is deliberate: it gives senders a window to understand their own mail streams before applying enforcement. Jump straight to p=reject without that groundwork, and you risk blocking legitimate email — newsletters sent by a marketing platform, transactional email from a billing tool, automated reports from a SaaS service. All of these send on behalf of your domain, and all of them need to pass authentication before you lock the door.

That's the tension at the heart of every DMARC rollout: you need enforcement to stop spoofing, but enforcing before your mail streams are properly aligned breaks legitimate email. The only way through it is to be systematic.

Step 1 — Get SPF and DKIM right first

DMARC works by checking whether an email passes SPF or DKIM — and whether the domain used by those checks aligns with the domain in the From: header. If an email passes SPF but the SPF-authorised domain doesn't match the From: domain, it still fails DMARC. Alignment is the part most people miss.

Before touching DMARC policy, audit the email sources that send on behalf of the domain. That typically includes the primary mail platform (Microsoft 365, Google Workspace), marketing automation tools (Mailchimp, HubSpot, Campaign Monitor), transactional email services (SendGrid, Postmark, Mailgun), and any line-of-business software that sends notifications or invoices with the company domain in the From: field.

This is often where MSPs find the most work. A client who has been using the same email infrastructure for three years has accumulated SPF includes for services they no longer use, missing DKIM selectors for tools they migrated to six months ago, and at least one third-party sender that was never added to the SPF record at all. Getting this tidy is the precondition for DMARC enforcement working correctly.

Step 2 — Publish a p=none record and start reading reports

Once SPF and DKIM are in reasonable shape, publish the DMARC record at p=none with a reporting address configured. A basic starting record looks like this:

The rua tag is the aggregate report address — you'll receive daily XML summaries from every major receiving mail server showing which sources sent mail on behalf of your domain, how many messages passed or failed SPF and DKIM, and what policy was applied. The ruf tag requests forensic (per-message failure) reports, though not all providers send these.

The p=none stage typically runs for two to four weeks at minimum. You're looking for anything sending on behalf of the domain that you haven't accounted for. Aggregate reports will surface sending sources by IP address and mail-from domain — any legitimate source that's failing authentication needs to be corrected before moving forward.

Step 3 — Move to p=quarantine

When your aggregate reports show a consistent pass rate for all known legitimate senders — typically above 95% and ideally 98–99% — you're ready to move from monitoring to quarantine. Update the DMARC record to:

Note the pct=10 tag. This instructs receiving servers to apply the policy to only 10% of failing messages, routing the rest as if the policy were p=none. It's a safety valve — if a legitimate sender is caught by the policy due to a misconfiguration you hadn't spotted, the impact is limited. You'd see it in the reports and correct it before raising the percentage.

Quarantine sends failing messages to the spam or junk folder rather than blocking them outright. This is an important intermediate step: it creates friction for spoofed mail without creating hard delivery failures for legitimate mail that's still being corrected. From the recipient's perspective, spoofed messages stop landing in the inbox. From your perspective, you still have a route to recover if something breaks.

Over the following one to two weeks, watch the aggregate reports. Raise pct incrementally — 25%, 50%, 100% — as confidence builds. Once you're at pct=100 at quarantine with a clean pass rate, the path to rejection is short.

Step 4 — Enforce with p=reject

Rejection is the goal. At p=reject, receiving mail servers discard messages that fail DMARC authentication outright — they never reach the inbox or the spam folder. For anyone attempting to spoof your client's domain, the messages simply disappear. No spoofed invoice lands in a customer's inbox. No phishing email reaches your client's employees from their own domain.

Same incremental approach applies: start at pct=10 and raise it in stages while monitoring the reports. By the time you've reached full quarantine enforcement cleanly, the jump to rejection rarely surfaces new issues — but doing it gradually preserves the ability to catch anything unexpected before it causes a delivery problem.

The ongoing maintenance that most implementations ignore

Reaching p=reject is not the end of the job. DMARC enforcement is a live state, not a permanent achievement. Email infrastructure changes — clients add new SaaS tools, migrate to a different marketing platform, restructure their email routing, or let IT contractors make DNS changes without thinking through the downstream effects. Any of those changes can break alignment silently.

Common maintenance events that can disrupt a working DMARC setup include: adding a new email sending service without updating SPF and DKIM, migrating from one Microsoft 365 tenant to another without reconfiguring DKIM selectors, changing the MX records during a mail migration without preserving SPF includes, and letting a marketing platform's DKIM key expire when the selector DNS record was managed by a previous contractor.

Aggregate reports remain valuable after enforcement — they're the early warning system for drift. A sudden drop in DMARC pass rate, a new sending IP appearing in the reports, or a known source appearing with failed alignment are all signals that something changed and needs attention. Without someone reading those reports, the first sign of a problem is often a client complaint about legitimate email bouncing.

How Albaspot handles this for MSPs at scale

Running through this process for one domain is manageable. Running it for forty clients simultaneously — each with a different email stack, different number of third-party senders, and different timelines — is where manual processes start to break down. Tracking which clients are at p=none, which are at quarantine with pct=50, which are ready to raise the percentage, and which have drifted out of alignment since last week — that's not something a spreadsheet handles well.

Albaspot's DMARC management is designed around exactly this problem. Because DNS management and DMARC monitoring are in the same platform, you're not switching between tools to check a report and then make a DNS change. The full picture for each client — their current policy, their pass rate trend, their identified senders, and any alignment failures from the last reporting period — is available in one place, organised by client.

For an MSP managing thirty clients through a DMARC enforcement programme, the difference between doing this manually and doing it through a platform designed for it is significant. Manually, it means regularly logging into multiple DNS providers, downloading and parsing aggregate report XML files, tracking policy stages in a spreadsheet, and hoping you notice the next time a client's pass rate drops. Through Albaspot, every client's DMARC status is visible across a single dashboard, policy changes apply directly from the same place you're reading the reports, and alerts surface issues before clients notice them.

The enforcement programme that takes months when done manually tends to complete faster when the reports are readable and actionable from day one. MSPs that have already been through DMARC rollouts manually consistently find that the time spent per domain drops substantially once the process is centralised and the reporting is automated.

Subdomains: the part that often gets left behind

One area that's easy to overlook during a DMARC rollout is subdomain policy. By default, a DMARC record on the organisational domain also applies to subdomains — but only if those subdomains don't have their own mail sending configuration. Many domains have subdomains that are used for specific sending purposes: mail.company.com, notifications.company.com, invoices.company.com. Each of these may need its own SPF and DKIM configuration.

There's also the question of parked or inactive subdomains. If a subdomain exists but is not used for email, it's worth adding a restrictive DMARC record directly on that subdomain to prevent it from being used as a spoofing vector while the parent domain is still moving toward enforcement. Something like v=DMARC1; p=reject; on an inactive subdomain is a low-risk, high-value step that's commonly missed.

Related reading

Explore Albaspot features: DMARC & email security, DNS management, monitoring & alerting, domain registration, client portal.