DMARC Setup Service

DMARC is the layer that turns SPF and DKIM from suggestions into enforcement — and the one most likely to break your own email if you rush it. The record itself is almost trivial: two required tags in a DNS entry. The real work is everything around it: getting alignment right, discovering every service that sends as your domain, reading the reports, and walking the policy up to full enforcement without rejecting a single piece of your legitimate mail. This page explains what DMARC actually does, why it fails when SPF and DKIM pass, and how a setup gets to p=reject the safe way.

What is DMARC, and what does it actually do?

DMARC — Domain-based Message Authentication, Reporting and Conformance — is a DNS record published at _dmarc.yourdomain.com that sits on top of SPF and DKIM and adds two things they lack on their own. The first is a policy: an instruction to receiving servers about what to do with mail that claims to be from your domain but fails authentication — nothing, quarantine, or reject. The second is reporting: a feedback stream telling you who is sending mail as your domain and whether it is passing. SPF says which servers may send for you; DKIM signs your messages; DMARC ties both to the domain your recipients actually see and tells the world how to treat impostors. Without it, a phisher can pass SPF using their own domain while spoofing yours in the From field, and you would never know.

It is worth being precise about one thing: a DMARC policy is a request, not a command. Receivers decide how to act on it, and some apply their own judgement regardless — Microsoft’s filtering, for instance, may treat failing inbound mail as suspicious even absent a strict policy. But the major providers honour DMARC, and at enforcement it is the single most effective control against domain spoofing.

The scale of adoption shows both how mandatory DMARC has become and how many organisations stop short of the protection. Among the largest companies, the vast majority now publish a DMARC record, but only around six in ten have reached p=reject; drop to mid-sized firms and reject adoption falls into the teens, and globally fewer than half of domains have a valid DMARC record at all. The pattern is consistent: publishing DMARC is now common, but actually getting to enforcement — the only stage that stops spoofing — is where most stall, usually because the rollout work feels risky without a clear process. That gap between “we have DMARC” and “we are protected” is precisely the work a setup service exists to close.

Why does DMARC fail when SPF and DKIM pass?

This is the most misunderstood concept in email authentication, and it trips up nearly every first setup. DMARC does not simply ask whether SPF or DKIM passed — it asks whether the domain they authenticated aligns with the domain in your visible From address. A message passes DMARC if at least one of SPF or DKIM both passes and aligns; it fails only when neither aligns. So you can have a 100% SPF pass rate and green DKIM across the board, and still watch your aggregate report show a 40% DMARC failure rate, because the authenticated domain is not your From domain. The classic case: a marketing platform sends your campaign, signs it with DKIM using its domain, and passes DKIM — but because that signing domain does not match your From address, it does not align, and DMARC fails. Authentication and alignment are not the same thing, and DMARC is entirely about the second. Fixing alignment, sender by sender, is the substance of a real DMARC setup.

The DMARC record, tag by tag

A DMARC record is a set of tags, and only two are mandatory — the rest have defaults. Understanding them is the difference between a record that is technically valid and one that is actually doing its job.

Two tags deserve emphasis. The rua tag, which directs the aggregate reports to you, is technically optional but practically mandatory — without it you publish a policy with zero visibility, which is flying blind. And the forensic reporting tags, fo and ruf, are widely documented but effectively obsolete, because the major providers stopped sending failure reports; the aggregate reports are where all the real value lives, so we do not waste effort chasing forensic data that will not arrive.

Relaxed or strict alignment?

DMARC offers two alignment modes, set by the adkim and aspf tags, and the choice is simpler than it is often made to sound: use relaxed unless you have a specific reason not to. Relaxed alignment, the default, lets a subdomain of your organizational domain satisfy the check — so mail.example.com aligns with example.com — which means it tolerates third-party senders and multiple mail streams without breaking. Strict alignment demands an exact domain match and is only appropriate when you control every sending system end to end. The trap is strict SPF: some widely used sending platforms rely on delegated subdomains for bounce handling and cannot support strict SPF alignment at all, so forcing it simply breaks legitimate mail. The architecture that works for nearly everyone is relaxed alignment combined with subdomain segmentation — each third-party sender placed on its own subdomain, with DKIM alignment prioritised over SPF because DKIM survives forwarding where SPF does not.

The three policy levels

DMARC has three policy levels, and they form a deliberate progression rather than a menu to pick from. A policy of p=none takes no action on failing mail — it only monitors, which makes it safe to publish but useless as a permanent state. p=quarantine tells receivers to send failing mail to spam. p=reject tells them to refuse it outright, and it is the destination: the only level at which your domain genuinely cannot be spoofed. The mailbox providers require at least p=none for bulk senders, but that minimum is not protection — as one common phrasing puts it, p=none is not a policy so much as a confession that the work has not been done yet. Leaving a domain at p=none indefinitely while calling it “DMARC compliance” provides reporting and nothing else; the security only arrives at enforcement.

Why not jump straight to p=reject?

Because you will block your own mail. The instinct, once the security value is clear, is to publish p=reject immediately and be done — and teams that do this routinely find their marketing emails, transactional receipts and calendar invites suddenly rejected, because the services sending them were never aligned. Most organisations send through more tools than anyone remembers: a CRM, an invoicing platform, a help desk, a scheduling app, each potentially failing alignment. Set reject before they are fixed and every one of them is refused. The safe path is the opposite of dramatic: publish p=none with reporting, spend two to four weeks reading the aggregate reports to find every legitimate sender, align each one, and only then move to quarantine and reject — ramping the pct dial from 10 through 25, 50 and 100 if you want extra caution, though some receivers apply the full policy regardless. The rule we follow is to advance only when the reports show roughly 95% or more of legitimate mail aligning consistently, and to watch a full reporting cycle clean at each step before the next.

It helps to see the phases concretely. The first two weeks are pure monitoring at p=none: the record is live, reports are arriving, and nothing about delivery has changed — this stage cannot hurt you, which is why there is never a reason to delay starting it. The next stretch, typically weeks three and four, is the real labour: configuring proper authentication for every legitimate sender the reports surfaced, so each aligns to your domain. Only once that alignment is consistent does the policy move to quarantine, where failing mail goes to spam rather than being rejected, giving a safety margin to catch anything missed. The final move to reject is the shortest if the earlier work was done well, often a one-to-two-week ramp. The whole sequence is bounded and predictable, and the discipline is simply refusing to skip a stage because enforcement feels urgent — the urgency is exactly what causes the self-inflicted outages.

Reading the aggregate reports

The aggregate reports are where DMARC stops being a DNS record and becomes operational intelligence. Receivers send them daily as XML files to your rua address, summarising every source that sent mail claiming to be your domain, with the IP, the volume, and whether each passed SPF, DKIM and alignment. The detail that matters most is the gap between authentication and alignment: a source can show SPF “pass” while the evaluated alignment shows “fail,” which means the sender is authorised but not configured for DMARC — exactly the misconfiguration that breaks legitimate mail at enforcement.

# mcsnet · dmarc aggregate report · example.com · 1 day
source            spf    dkim   dmarc   volume
your mta           align  align  PASS    18,420
marketing platform pass   align  PASS    9,310
crm (forgotten)    pass   none   FAIL    2,140
invoicing tool     none   pass   PASS    870
unknown / spoof    fail   fail   FAIL    4,605
action            align crm before p=reject; spoof confirms why

Reading that report tells you precisely what to do: align the CRM before tightening, and note that the spoofing source is itself the argument for reaching reject. The reports turn “is DMARC safe to enforce yet?” into a question with a clear, evidence-based answer.

The reports also have a security dimension that outlasts the rollout. Once you are at enforcement, the aggregate stream becomes an early-warning system: a new source appearing in the reports is either a tool someone added without telling you — which needs aligning — or someone attempting to spoof your domain, which you now know about and can act on. Many organisations discover the scale of impersonation attempts against their brand only after turning on DMARC reporting, because before it there was simply no visibility. Reading the reports is therefore not a one-time rollout chore but an ongoing practice, and the raw XML is dense enough that most teams need either a parsing tool or someone whose job is to read them — which is part of what an ongoing service provides rather than leaving a daily pile of XML in an inbox nobody opens.

Subdomain strategy: sp and segmentation

Subdomains are where DMARC setups quietly go wrong, and the sp tag is part of why. If you do not set sp, your subdomains inherit the parent domain’s policy — fine for uniform enforcement, but a problem when a subdomain sends with a different authentication setup and gets caught by a policy meant for the root. The sp tag lets you set a different policy for subdomains centrally, which is useful, but it is not a substitute for managing subdomains properly: any subdomain doing real sending — marketing, transactional, support — usually deserves its own explicit DMARC record. The architecture we favour puts each distinct mail stream on its own subdomain, each with appropriate authentication and policy, so a problem on the marketing subdomain cannot threaten the transactional one, and enforcement can be tightened per stream as each becomes ready. It is more deliberate than a single top-level record, and it is what keeps a complex sending environment from forcing an all-or-nothing choice.

How we set up and run DMARC

Our process is the staged one, run end to end. We publish the initial record at p=none with reporting, then collect and read the aggregate reports to build a complete inventory of every source sending as your domain — including the ones you have forgotten. We align each legitimate sender, fixing DKIM signing domains and return paths so they match your From address, and we shut down or escalate the illegitimate ones the reports reveal. Then we tighten the policy in stages, watching the reports at each step, until you are at p=reject with your legitimate mail flowing cleanly and your domain genuinely protected from spoofing. Because we also host your sending infrastructure and configure SPF and DKIM, we fix alignment at the source rather than filing tickets with vendors and hoping — which is the difference between a DMARC rollout that stalls at p=none and one that reaches enforcement. After that, we keep watching the reports, because new senders and new spoofing attempts both show up there, and a DMARC setup is only as good as its ongoing maintenance.

Why work with us?

Two reasons. First, data and consent: we run DMARC with your reporting and infrastructure hosted in Toronto under PIPEDA, and our CASL-aware approach treats authentication as part of legitimate, consent-based sending rather than a checkbox. Second, operator depth: DMARC enforcement is exactly the kind of work that goes wrong when rushed or handed to someone who has not done it, and you get operators who have taken many domains to p=reject safely and know how to read a report and when to advance. The providers themselves advise that teams without DMARC expertise use a service rather than set quarantine and reject blind — and that is precisely the gap we fill, with the added advantage of controlling the infrastructure the alignment depends on.

Who this is for, and who it is not

It is for any domain that needs DMARC at enforcement done safely — bulk senders meeting the mandatory requirements, brands that want spoofing genuinely stopped rather than merely monitored, and teams stuck at p=none who do not know how to advance without breaking mail. It is especially for complex environments with many vendors and subdomains, where the alignment work and the report-reading are real jobs rather than a five-minute task. It is not strictly necessary for a tiny single-platform sender whose provider already publishes and manages DMARC correctly — though even then, confirming you are actually at enforcement rather than parked at p=none is worth doing. DMARC is the keystone of authentication: it depends on SPF and DKIM underneath, sits inside the broader authentication setup, and pairs with feedback-loop setup for the complaint side. Get it to p=reject, in the right order, and your domain stops being a tool anyone can forge.