Hosted DMARC

21 June 2026 · 27 min read

What this guide covers

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the record that tells the world's mailboxes what to do with email claiming to be from your domain - and where to send back a report on what they saw. This guide explains every DMARC tag, how alignment works, how DMARC Engine's hosted delegation model keeps your record correct with zero manual DNS edits, and how to move safely from monitoring (p=none) to full enforcement (p=reject).

If you haven't added your domain yet, start at dmarcengine.com/docs/adding-your-first-domain. For the underlying delegation mechanism this guide relies on, see dmarcengine.com/docs/delegating-your-dns. SPF and DKIM are covered in their own guides - hosted-spf and hosted-dkim - and DMARC needs both of those in place to actually pass mail, so read this alongside them rather than in isolation.

Note - DMARC does not replace SPF or DKIM. It sits on top of them and adds two things they lack on their own: an alignment check (does the domain in SPF/DKIM match the domain the recipient actually sees?) and a reporting channel (aggregate and, optionally, forensic reports mailed back to you). You cannot get useful DMARC results without at least one of SPF or DKIM correctly configured and aligned.

---

How DMARC works, in plain terms

Every DMARC-checking mailbox provider (Google, Microsoft, Yahoo and the rest) does the same four things on inbound mail:

1. Look up _dmarc.<your-domain> as a DNS TXT record.
2. Check whether the message passes SPF, and whether the SPF domain aligns with the visible "From" domain.
3. Check whether the message passes DKIM, and whether the DKIM signing domain aligns with the visible "From" domain.
4. If DMARC passes (SPF or DKIM aligned-pass), deliver as normal. If it fails, apply the policy you published (none, quarantine, or reject) - and, if you asked for reports, log the result for later delivery to you.

The "visible From domain" is the one a human reads in their inbox - technically the RFC5322 From: header. This is different from the SMTP envelope sender (RFC5321 MAIL FROM), which is what SPF actually checks. DMARC's alignment check is what ties these two together. If that distinction is new to you, read header-from-vs-envelope-from before continuing - it explains why a domain can pass SPF and still fail DMARC.

Why aggregate reports matter

Because DMARC is opt-in and enforced by the receiver, not the sender, the only way to know whether your legitimate mail streams (helpdesk tool, payroll provider, marketing platform, your own mail server) are all passing is to read the reports receivers send back. That's the whole point of the rua tag, and it's why /analytics exists - nobody reads raw XML by hand.

---

The DMARC record and every tag explained

A DMARC record is a single DNS TXT record published at _dmarc.<domain>. Tags are separated by semicolons, in name=value pairs. Here's a complete example, then a tag-by-tag breakdown:

v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:reports@example.com; ruf=mailto:forensics@example.com; adkim=r; aspf=r; fo=1; ri=86400

Note - Tag order doesn't matter except v, which must be first. Unknown tags are ignored by compliant receivers, not fatal. Duplicate tags, an invalid v, or a syntactically broken record cause the whole record to be treated as absent - which silently drops you back to no DMARC protection at all. Use /lookup any time you want to sanity-check a raw record before or after publishing.

Alignment in practice: r vs s

Relaxed alignment (the default, and what we recommend for almost everyone) matches on the organisational domain. mail.example.com aligns with example.com. Strict alignment (s) requires the exact same domain - mail.example.com would not align with example.com under aspf=s/adkim=s. Strict mode is rarely necessary and breaks legitimate subdomain-based sending setups more often than it stops abuse; leave both at r unless you have a specific reason and have tested it thoroughly first.

Policy tags: p and sp

p is mandatory and governs the domain the record is published on. sp is optional and, when present, governs every subdomain instead. A common pattern for domains that never send mail from subdomains is to set p=reject on the apex and sp=reject explicitly too - belt and braces against someone registering phish.example.com and spoofing it. If you omit sp, subdomains simply inherit whatever p says.

Tip - Even domains that never send email at all should still publish a DMARC record with p=reject (a "parked domain" policy). Otherwise nothing stops an attacker from spoofing From: ceo@yourunusedbrand.com. DMARC Engine's /dmarc builder supports this in one step - add the domain, skip SPF/DKIM setup, and jump straight to enforcement.

pct: the ramping lever

pct tells receivers what fraction of otherwise-failing mail should actually get the stricter treatment; the remainder is treated as if the next weaker policy applied. For example, p=reject; pct=50 means roughly half of DMARC-failing mail is rejected and the other half is treated as quarantine. This is the mechanism the safe rollout in this guide relies on - see Rolling out enforcement safely below.

Warning - pct only ever throttles the failure path. It has no effect on mail that already passes DMARC. Setting pct=10 does not mean "only enforce on 10% of my domain's mail" - it means "of the mail that fails, only enforce on roughly 10% of it." Don't use pct as a substitute for actually fixing failing senders first.

---

The hosted approach: delegate with a CNAME, we manage the record

DMARC Engine's core model is delegation, not copy-paste. Instead of you maintaining a DMARC TXT record by hand forever, you publish one CNAME pointing at us, and we serve and continuously manage the actual record content - including rotating pct during a guided rollout, keeping the rua address correct, and never letting the record go stale or drift out of sync with what you configured in the app.

How it works

Your domain has a hosting slug - a short identifier shown in the app for that specific domain - and a rua token, a unique string that routes incoming aggregate reports back to your organisation. Together they let one shared hostname (dmarcengine.com) safely serve records for thousands of different customer domains without collisions.

_dmarc.example.com.    CNAME   acme7f2.dmarc.dmarcengine.com.

Behind that CNAME, we serve a TXT record equivalent to:

v=DMARC1; p=quarantine; pct=100; rua=mailto:r-8f4a1c2e@reports.dmarcengine.com

The r-<token>@reports.dmarcengine.com address is where every receiver in the world sends your daily aggregate reports. We receive them, parse the XML, and surface the results on /analytics and /reports - no mailbox to monitor, no XML to unzip.

Setting up hosted DMARC - step by step

1. Sign in to app.dmarcengine.com/domains and add your domain if it isn't listed yet (see adding-your-first-domain for that flow).
2. Open the domain and go to its DMARC page at /dmarc.
3. Choose your starting policy. For a brand-new setup, always start at p=none (monitoring only - see Rolling out enforcement safely).
4. The app shows you the exact CNAME to publish, using your domain's hosting slug, in the form:

   Host:  _dmarc.example.com
   Type:  CNAME
   Value: <slug>._dmarc.dmarcengine.com
   

1. Log in to your DNS provider (registrar or DNS host - Cloudflare, GoDaddy, Route 53, etc.) and add that exact CNAME record. Do not add a TXT record alongside it; the CNAME is the whole point - one place to manage the value going forward.
2. Save the DNS change and return to the app.
3. Click Verify on the DMARC page, or run a check via /lookup. Propagation is usually minutes, but can take up to 24-48 hours depending on your DNS provider and any cached TTLs - see how-long-dns-changes if it's taking a while.
4. Once verified, the app shows the record as Live and starts routing aggregate reports through to your dashboard as receivers send them (expect the first reports within 24-48 hours of going live, since most providers send once daily).

Note - A CNAME can only exist at a DNS name that has no other records. That's fine at _dmarc.example.com - nothing else legitimately lives there - but it's worth knowing if your DNS provider throws a "conflicting record" error: it almost always means a leftover TXT record at the same host from a previous DMARC setup that needs deleting first.

Why hosted beats manual for most teams

• No drift. A pasted TXT record is a snapshot; the moment you need to bump pct during a rollout, rotate a reporting address, or add a second rua recipient, someone has to remember to go and edit DNS again. With the CNAME, changing the policy in the app changes what's served immediately - the DNS record itself never needs to be touched again.
• Correct syntax, always. Hand-typed DMARC records are a common source of silent failures (missing semicolons, a stray space after mailto:, a typo in v=DMARC1). We generate the record, so it's always syntactically valid.
• Ramping is one click. Moving from p=none to p=quarantine; pct=25 and later to p=reject; pct=100 is a policy change in the app, not a DNS edit-and-wait cycle each time.
• Report delivery is guaranteed to route. The rua mailbox is ours and built to parse the reports receivers send - you're not relying on a shared team inbox someone might disable or a mail rule someone might delete.

The manual alternative

If you'd rather manage the record yourself - perhaps your DNS is locked down by a separate infrastructure team, or you have compliance reasons to keep everything first-party - you can always publish the record directly instead of the CNAME. The app's /dmarc page has a "Publish manually" toggle that shows the literal TXT value to copy:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:reports@example.com"

With this approach, you're responsible for keeping the record's pct and p values current as you progress through a rollout, and reports go wherever rua points - your own mailbox or parsing pipeline, not ours (which means our /analytics dashboard won't have anything to show unless you also add a rua recipient pointing at your hosted address alongside your own). We generate the exact syntax either way; the CNAME is simply less to maintain over the record's lifetime.

Tip - You can run both: some teams keep their own rua mailbox as a backup or for a separate compliance archive, and add ours as a second address in the same tag: rua=mailto:reports@example.com,mailto:r-8f4a1c2e@reports.dmarcengine.com. Multiple mailto: URIs, comma-separated, is standard DMARC syntax and every major receiver supports it - but this only applies if you're publishing the record manually, since the hosted CNAME already routes reports for you.

---

Rolling out enforcement safely: p=none → quarantine → reject

Jumping straight to p=reject on a domain you haven't monitored first is the single most common way DMARC breaks legitimate mail - invoices stop arriving, marketing sends bounce, a forgotten SaaS tool that sends on your behalf goes silent. The safe path is always: monitor, fix, then enforce gradually.

1. Start at p=none. This asks receivers to do nothing differently - mail is delivered exactly as it would be without DMARC - but they still send you reports on what passed and what didn't. This is pure visibility with zero delivery risk. Set this on /dmarc as your very first step.
2. Wait and read. Give it at least 1-2 weeks so you see a representative sample of your sending sources - including anything that only sends monthly (payroll, annual reports, etc.). Review results on /analytics, which groups results by sending source so you can see at a glance which services are passing and which aren't.
3. Fix every legitimate source that's failing. For each sending platform not yet aligned, either add it to your SPF include chain (see hosted-spf) or set it up with its own DKIM selector (see hosted-dkim). Re-check /analytics after each fix until you see consistent aligned-passes from every source you recognise.
4. Move to p=quarantine; pct=25. This is the first real enforcement step, but throttled: roughly a quarter of failing mail gets sent to spam/junk instead of the inbox, and only mail that's already failing is affected. Set this via /dmarc - the builder handles the pct maths for you.
5. Increase gradually: pct=50, then pct=100. Leave each step running for several days to a week, watching /analytics for any new failure pattern each time. Slow is safe; there's no reward for rushing.
6. Move to p=reject; pct=25 once p=quarantine; pct=100 has run clean for a while with no unexpected failures.
7. Ramp pct to 100 on p=reject. At this point failing mail is rejected outright by receivers rather than delivered to spam - this is full DMARC enforcement.
8. Set sp to match p (usually the same value) once you're confident, so subdomains are covered by the same enforcement level.

Warning - Don't skip the quarantine stage entirely and jump from none straight to reject, even at pct=1. Quarantine gives you a recoverable failure mode (a user can still find the message in spam and rescue it); reject does not - the sending server gets a bounce and the recipient never sees the message at all. Always prove the setup clean at quarantine first.

For the fuller decision-making version of this rollout - including how long each stage typically takes and how to know you're ready to move on - see p-none-to-p-reject, how-long-to-reach-p-reject, and is-it-safe-to-move-to-p-reject. If you're worried about the risk of enforcement altogether, p-none-false-security explains why staying at p=none indefinitely isn't actually a safe long-term resting state - it gives visibility but zero protection against spoofing.

---

Reading aggregate reports on /analytics

Aggregate (RUA) reports are XML documents receivers send roughly once a day, summarising every message they saw claiming to be from your domain over that period: source IP, volume, and whether SPF/DKIM passed and aligned. DMARC Engine parses every report it receives and renders it as readable trends and tables on /analytics, so you never need to open raw XML.

What to look for

1. Open /analytics and select the domain.
2. Check overall pass rate first. A healthy, fully-aligned domain should trend toward ~100% aligned-pass over time. A sudden drop is worth investigating immediately - it can mean a sending platform changed its outbound IPs or a DKIM key rotated without the DNS side following.
3. Look at results grouped by source/IP. Each distinct sending source (your mail server, your CRM, your helpdesk, a marketing platform) shows up separately. This is how you catch a legitimate but unauthenticated sender - the volume from that source will show consistently as SPF-fail/DKIM-fail even though the mail is genuine.
4. Distinguish SPF-only pass from DKIM-only pass from both. Ordinarily either one aligning is enough for DMARC to pass overall, but if you only have one of the two set up, losing that single mechanism (a broken SPF include, a rotated DKIM key) drops the whole source to fail with no fallback. Diversify where you can.
5. Watch for unexpected geographies or volumes. A burst of failing mail from an IP range or country you don't send from is a signal someone is actively spoofing your domain - useful independent confirmation on top of whatever your threat feed already tells you.
6. Cross-reference with /threats, which flags known-bad senders and abuse patterns detected across your reports automatically.
7. Export or drill into raw data on /reports if you need the underlying report list - for example to hand to a security team investigating a specific incident.

For a slower walkthrough of what a single report actually contains and how to interpret it field by field, see reading-a-dmarc-aggregate-report and aggregate-report-analysis. If your reports look empty or thin, dmarc-reports-are-empty covers the common causes.

Note - Not every mailbox provider sends aggregate reports, and the ones that do vary in frequency and completeness. Gmail and Microsoft are consistent and prompt; smaller providers may send weekly, partial, or not at all. Don't panic if coverage looks patchy in the first few days - it builds up over the first one to two reporting cycles.

---

Forensic (RUF) reports

ruf requests forensic reports - near-real-time notifications sent for individual failing messages, potentially including full or partial message content, rather than the daily aggregated summary rua provides.

1. Add a ruf recipient the same way as rua, either via the record the app manages for you or manually if self-hosting the TXT record:

   ruf=mailto:forensics@example.com
   

1. Set fo to control which failures trigger a report. fo=1 (fail if either SPF or DKIM fails) is the most diagnostically useful setting for most teams; fo=0 (the default) only reports when both fail, which is much quieter but also less informative while you're actively debugging a specific source.
2. Understand the trade-off before enabling this broadly.

Warning - Forensic reports can include the full original message, headers and sometimes body, which means genuine personal data flowing to wherever ruf points. Support for RUF is also far less consistent among receivers than RUA - many large providers (Gmail included) don't send forensic reports at all for privacy reasons, so don't rely on ruf as your primary diagnostic tool. Treat aggregate reports on /analytics as the day-to-day source of truth, and reserve ruf for narrow, temporary debugging of a specific sending source where you've already got consent/compliance sign-off to receive raw mail content. See data-retention-and-privacy for how we handle anything routed through our own reporting addresses.

---

Common pitfalls

These are the mistakes that show up most often in support tickets, roughly in order of how often we see them.

1. Publishing both a TXT and a CNAME at _dmarc.<domain>. DNS doesn't allow other records to coexist at a hostname that also has a CNAME. If a stale TXT record from a previous provider or an earlier manual attempt is still there, the CNAME either fails to save or silently loses to whichever record your DNS provider prioritises. Always delete the old TXT record first.
2. Jumping straight from p=none to p=reject. Covered in detail above, but worth repeating: this is the single most common cause of "DMARC broke our email" incidents. There is no shortcut that skips reading /analytics first.
3. Forgetting that DMARC only inspects the visible From: header. Teams sometimes "fix" an SPF failure by adjusting the envelope sender and then can't understand why DMARC still fails - because the visible From domain, not the envelope domain, is what alignment checks against. Revisit header-from-vs-envelope-from if this trips you up.
4. Treating pct as a traffic percentage rather than a failure percentage. As covered above, pct=10 doesn't mean "enforce on 10% of mail" - it means "enforce on roughly 10% of the mail that's already failing." Passing mail is unaffected regardless of pct.
5. Only setting up one of SPF or DKIM, then being surprised when a single change breaks everything. If DKIM is your only aligned mechanism and a key rotates without the corresponding DNS update, every message drops to DMARC-fail the moment that happens, with no SPF fallback to catch it. Set up both where you reasonably can.
6. Not updating rua/ruf after a mailbox migration. If your rua address was a personal mailbox and that person leaves, reports silently stop being read (though, notably, this is one thing the hosted CNAME entirely sidesteps, since reports route to us rather than a person's inbox).
7. Forgetting subdomains exist. A domain locked down at p=reject with no sp set, and a forgotten dev.example.com or mail.example.com subdomain sending unauthenticated mail, can still be freely spoofed if that subdomain isn't covered. Set sp explicitly rather than relying on inheritance you haven't checked.
8. Assuming every mailbox provider sends aggregate reports at the same frequency or completeness. Coverage varies. Draw conclusions from a representative window (one to two weeks), not a single day's reports.
9. Ignoring DNS TTL when troubleshooting. A cached negative lookup or an old TTL value can make a correctly-published record appear "not found" for longer than expected. Check the TTL on the previous record before assuming the new one is broken; see how-long-dns-changes.
10. Managing DMARC for many client domains without a consistent process. If you're an agency or MSP handling DMARC for multiple clients, ad hoc manual record edits across dozens of domains are exactly the workflow the hosted CNAME model was built to remove - see multiple-domains and the MSP page for how to manage a portfolio of domains from one account.

Tip - If you only take one thing from this section: never change p without having looked at /analytics first, and never skip the quarantine stage of the rollout.

---

Working with a DMARC-hosting change across your organisation

If you manage DMARC on behalf of a wider organisation - IT, a security team, or a marketing team that owns its own sending domain - a few extra practices are worth putting in place beyond the individual record:

1. Assign an owner for rua monitoring, even though the hosted CNAME means reports route to us automatically - someone still needs to be the person who logs into /analytics periodically and acts on what it shows, rather than assuming the dashboard fixes itself.
2. Turn on alerts at /alerts so a sudden authentication failure spike or an unexpected new sending source surfaces proactively instead of only being caught on a manual dashboard check. See setting-up-alerts for the available alert types and thresholds.
3. Document every legitimate sending source in one place - your own mail server, marketing platform, helpdesk, payroll provider, anything that sends From: your domain - so that when a new one appears in /analytics you can quickly tell "known and needs onboarding" from "unrecognised and needs investigating."
4. Review /audit periodically for a change history across your DMARC, SPF, DKIM, MTA-STS and BIMI records, particularly useful if more than one person on your team has access to make changes.
5. Keep an eye on drift. Because the record is hosted, drift caused by a manual DNS edit going stale isn't a risk the way it is with a self-managed TXT record - but it's still worth confirming annually (or whenever you change DNS providers) that the CNAME itself is still correctly pointed, since registrar migrations occasionally drop custom records that don't look obviously important to whoever is doing the migration.

---

Verify it worked

1. Confirm the CNAME resolves. Run /lookup against _dmarc.<your-domain> and confirm it shows your hosted DMARC value being served through the CNAME, or use a terminal:

   dig TXT _dmarc.example.com +short
   

You should see the full v=DMARC1; ... string resolved through the CNAME chain.
2. Check the domain's DMARC status is "Live" on /dmarc in the app - this reflects our own verification, run independently of your local DNS cache.
3. Send yourself a real test email from the domain and check the authentication results header at the receiving end (most webmail clients expose "Show original" or similar) - look for dmarc=pass.
4. Wait for the first aggregate report to land, typically within 24-48 hours, and confirm it appears on /analytics. An empty dashboard after 48 hours with a confirmed-live record is the main sign something's misrouted - see the troubleshooting section below.
5. Use the free public checker at dmarcengine.com/tools/dmarc-checker for a quick outside-in view that doesn't require being logged in, handy for sharing a link with a colleague or client.

For general post-setup end-to-end confirmation across DMARC, SPF and DKIM together, see check-dmarc-is-working.

---

Common problems and fixes

---

FAQ

Do I need SPF and DKIM before I set up DMARC?
You don't strictly need both before publishing a DMARC record at p=none - monitoring works regardless, and in fact seeing the gaps is exactly how you find out what needs fixing. But you do need at least one of them correctly configured and aligned before moving past p=none, otherwise all your own legitimate mail will start failing enforcement. Set up hosted-spf and hosted-dkim in parallel with this guide.

What's the difference between the hosted CNAME and just publishing the TXT record myself?
Functionally, receivers see the same content either way - a CNAME resolves through to a TXT value, and DNS resolvers treat that as equivalent to a TXT record living directly at that name. The difference is entirely about who maintains the value over time. With the CNAME, changing your policy in the app changes what's served immediately, with no DNS edit required. With a manually-published TXT record, you own updating it every time you change p or pct.

Can I use a different rua mailbox instead of DMARC Engine's?
Yes, if you're publishing the record manually rather than via the hosted CNAME. Point rua at any mailbox you control, including your own alongside ours as a second comma-separated address. If you use the hosted CNAME, reports route to our address automatically and surface on /analytics - you don't need a separate mailbox at all.

Why does my record show p=none still working, if p=none means "do nothing"?
p=none doesn't disable checking - receivers still evaluate SPF/DKIM alignment and still send you reports. It only means they don't change delivery based on the result. It's the correct, deliberate first stage of any rollout, not a broken or incomplete state.

How long should I stay at each pct step?
There's no universal number, but several days to a week per step is typical, long enough to see a representative slice of your regular sending volume (including anything that only sends weekly). Don't rush based on the calendar - rush based on /analytics showing clean, consistent aligned-passes.

What happens to subdomains I haven't set up DMARC for individually?
They inherit sp if you've set it, or otherwise p, from the organisational domain's record - DMARC doesn't require every subdomain to publish its own record. See five-records-that-protect-email for how the different record types work together across a domain and its subdomains.

Is DMARC enough on its own to stop phishing of my domain?
It's the single most effective control against exact-domain spoofing once you reach p=reject, but it can't stop lookalike domains (examp1e.com) or compromised legitimate accounts. Pair it with the free lookalike-domain-checker and general vigilance for those threats.

What if I'm migrating from another DMARC provider?
Update the CNAME target to point at your DMARC Engine hosting slug instead of the old provider's, and remove any TXT record left over from the previous setup at the same host. See migrating-from-another-dmarc-provider for the full checklist, including how to avoid a reporting gap during the switch.

Does moving to p=reject affect mail I send to mailing lists?
It can - some mailing list software rewrites the From: header or forwards without re-signing DKIM, which breaks alignment regardless of your DMARC policy. This is a known, common edge case; see mailing-lists-dmarc-and-arc for how ARC helps and what to expect.

Can I set different policies for different subdomains, not just one sp for all of them?
The base DMARC spec only gives you one sp for all subdomains collectively (plus per-subdomain records if you explicitly publish one at that exact subdomain, which then takes precedence over the parent's sp). If you need genuinely different enforcement per subdomain, publish a distinct _dmarc.<subdomain> record for each one that needs to differ - the app supports this per domain entry on /domains.

Will changing ri actually make receivers report more often?
In practice, no, not reliably. ri is a request, not an obligation, and the large majority of receivers - including Gmail and Microsoft - send once every 24 hours regardless of what you set it to. It's safe to leave at the default or omit entirely; don't rely on shortening it to get faster feedback during a rollout. Watching /analytics over a slightly longer window achieves the same result without depending on receiver cooperation.

What happens if I remove the DMARC record entirely?
Your domain reverts to no DMARC protection at all - receivers stop applying any policy and stop sending reports, and anyone can spoof From: your domain with no consequence at the receiving end (SPF and DKIM might still independently pass or fail, but nothing ties that result to what the recipient actually sees). There's essentially never a good reason to remove the record outright rather than dialling it back to p=none if you need to pause enforcement.

Do I need to renew or rotate anything on the DMARC record itself, the way I would with a DKIM key?
No - unlike DKIM, a DMARC record has no cryptographic material to rotate. Once the CNAME is published, it stays valid indefinitely; the only reason to touch it again is a deliberate policy change (moving through the rollout stages, adding a report recipient if self-hosting, or updating sp).