# How to Publish DMARC Record: A 2026 Guide Published: August 1, 2026 Learn to publish DMARC record in DNS, from TXT syntax to enforcement, to boost email deliverability in 2026. If your domain is getting spoofed, the fix usually isn't another blocklist ticket or a longer spam complaint thread. It's a **published DMARC record** that receivers can find, read, and enforce. In practice, that means treating DMARC as a staged rollout, not a one-time DNS change, because the record becomes both a policy signal and a reporting system the moment it lands in DNS. ![An infographic showing the risks of skipping DMARC email security, highlighting phishing, credential breaches, and targeted attacks.](https://cdnimg.co/9a227681-63f7-452a-a677-fb77b6767eba/c303403b-687c-42ba-a633-c3be6d5c419b/publish-dmarc-record-dmarc-risks.jpg) A lot of teams first run into DMARC after a phishing wave starts using their exact brand. At that point, publishing a record is less about compliance theater and more about giving receivers a clear instruction set for failing mail. The core policy choices are straightforward, **monitor**, **quarantine**, and **reject**, but the operational consequences are not. A record with `p=none` tells receivers to observe and report, while stronger policies begin to shape delivery behavior once you trust your authentication setup. The protocol's own design explains why this matters. DMARC's standard record format includes policy and reporting tags such as `p=` and `rua=` and is published as a DNS **TXT** record at `_dmarc` so receivers know how to handle failures and where to send aggregate statistics. That reporting loop is what makes DMARC useful before enforcement, because the record is also a measurement system. For a plain-English companion on rollout hygiene, [email security tips for Canadian businesses](https://www.aits.ca/tag/email-security-best-practices/) is a useful reference alongside the technical work. ## Why Publishing a DMARC Record Matters A DMARC record matters because it gives you control over how other mail systems treat messages that claim to be from your domain. Without it, receivers can still make their own decisions, but you don't get a consistent policy or a reliable reporting stream. With it, you define the action for mail that fails alignment and you get a daily view of who's sending on your behalf, which is exactly why the record is worth publishing before you ever turn on hard enforcement. That visibility is the part many teams miss. In one large global measurement, active DMARC records grew to **31.15 million by December 2025**, up from **2.22 million in June 2020**, a more than **14-fold increase** over roughly five and a half years, but the same dataset showed that only **13.8%** of active records used `p=reject` while **65.7%** still used `p=none` ([DMARC.org draft](https://dmarc.org/draft-dmarc-base-00-01.html)). The pattern is clear, publication is widespread, enforcement is still catching up. > **Practical rule:** publish first, enforce later. If you skip the reporting phase, you'll eventually block something legitimate and won't know why. ### What DMARC actually controls DMARC sits on top of SPF and DKIM. It doesn't replace them, it decides what happens when authentication fails or doesn't align with the visible From domain. That's why DMARC is best thought of as both a policy layer and a feedback loop. If you're building or operating infrastructure for AI agents, automated notifications, or product mail, that feedback loop matters even more. One misconfigured sender can hide inside a dozen healthy ones, and a published DMARC record is often the only way to see the whole picture before tightening policy. ## DMARC Record Syntax and Where to Publish It Publish the record as a **TXT** record, not an MX, A, or CNAME record. The hostname should be **`_dmarc`**, with the leading underscore intact, and the record belongs at **`_dmarc.yourdomain.com`** rather than the bare apex domain. That placement is canonical across guidance from Microsoft 365, dmarcian, and other implementation docs, and it's the easiest way to keep receivers from missing the policy entirely ([Microsoft 365 guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure), [dmarcian publishing guide](https://dmarcian.com/how-to-publish-a-dmarc-record/), [Fortra publishing docs](https://hstechdocs.helpsystems.com/manuals/agari/agari_DMARC_protection/current/Content/Topics/BP/Implementing_DMARC/Publish_the_DMARC_Record_in_DNS.html)). The value itself is a semicolon-separated string of tags. The core tags you'll edit are **`v`**, **`p`**, **`rua`**, **`ruf`**, **`sp`**, **`adkim`**, **`aspf`**, and **`fo`**. Some implementation guidance also includes `pct`, but operationally I'd treat staged rollout through monitoring and policy changes as the safer path because DMARC is only enforced when the record is syntactically valid, in the correct DNS node, and aligned to the right destination. ### Read the tags like a policy map - **`v=DMARC1`** means the receiver is looking at a DMARC policy record. - **`p=`** sets the action for the organizational domain, usually `none`, `quarantine`, or `reject`. - **`rua=`** points aggregate reports to a mailbox or reporting service. - **`ruf=`** is for failure reports, though many receivers limit or don't send them. - **`sp=`** sets subdomain policy when you want something different from the parent. - **`adkim=`** controls DKIM alignment mode. - **`aspf=`** controls SPF alignment mode. - **`fo=`** defines failure reporting behavior. The main publishing mistake I see is not the syntax itself, it's the assumption that one record handles every domain shape. It doesn't. If you run multiple brands, subdomains, or third-party sending systems, the policy architecture matters as much as the text string. > **Operational note:** only one DMARC record should exist per domain. Duplicate TXT records at `_dmarc` create unpredictable validation behavior and make troubleshooting miserable. ## A Safe Rollout From Monitoring to Enforcement Start with the least risky record you can live with. A baseline DMARC value like **`v=DMARC1; p=none; rua=mailto:...`** gives you visibility without telling receivers to block anything, which is the right first move when you're still learning which systems send mail for the domain. During rollout, a short TTL such as **3600 seconds** is sensible because it lets DNS updates propagate faster while you're iterating. ![A diagram illustrating the four-step DMARC rollout process from monitoring to full rejection enforcement.](https://cdnimg.co/9a227681-63f7-452a-a677-fb77b6767eba/cb7acee9-5c1e-4de1-8554-4f528008912c/publish-dmarc-record-dmarc-process.jpg) The cleanest sequence is simple. Publish `p=none`, verify it, watch reports long enough to see every legitimate sender, then move to `p=quarantine` before you decide whether `p=reject` is safe. Multiple implementation guides recommend this ramp because pushing straight to rejection is how teams end up blocking internal systems, marketing tools, or forwarded mail that never got aligned correctly ([Red Sift implementation guide](https://redsift.com/guides/dmarc-implementation-guide), [NCSC none-policy guidance](https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing/implement-a-dmarc-policy-of-none)). The 2025 measurement picture also explains why caution still matters. One large global scan found only **18.2%** of 10 million domains had a valid DMARC record in Q2 2025, while **81.6%** had none at all; within the adopted group, just **7.6%** of all domains enforced with `p=quarantine` or `p=reject` ([global Q2 2025 scan](https://itnerd.blog/2025/08/29/the-state-of-email-trust-global-dmarc-adoption-trends-in-q2-2025/)). That's the gap you're trying to close without taking mail down. ## Handling Subdomains and Multiple Sending Systems The place where most DMARC rollouts get sloppy is the domain tree. Teams publish a record at the root, assume everything underneath inherits cleanly, and then discover that marketing, product, and support send through different systems with different alignment behavior. The result is usually a policy that looks tidy on paper and breaks mail in production. ### Decide whether subdomains inherit or override DMARC supports a parent policy with optional subdomain control through **`sp`**, and that's the first decision to make when you have more than one sender. Use one organizational record when the same policy fits the whole domain family. Publish a separate **`_dmarc`** record on a subdomain when that subdomain has a distinct sending identity or needs tighter handling than the parent, which is often the right choice for dedicated marketing or transactional domains. Forwarded mail and delegated senders complicate things. Microsoft's guidance notes that alignment failures are common when messages originate from different domains or pass through forwarding paths, and this is exactly why a one-size-fits-all policy can backfire. If a sender platform rewrites enough of the message path, the parent policy might be technically correct and operationally wrong. ### Authorize reporting destinations the right way Aggregate reporting also gets tripped up by destination authorization. If your `rua` address points to a different domain, the receiving domain needs to authorize the sender through a `_report._dmarc` TXT confirmation, or the reports may never arrive. That failure mode is easy to miss because the record is published, the policy is live, and the reporting mailbox stays quiet. I've also seen teams overuse the parent record when a subdomain should carry its own policy. That choice matters when a custom domain powers multiple sending systems, because DMARC is really about aligning the visible From domain with the actual authentication path. If you don't map that architecture first, you end up debugging symptoms instead of policy. ## Verifying Your Record Before You Tighten Policy Publishing a record and assuming it's working is a good way to burn time later. The fastest verification path is to confirm the TXT value at the live DNS node, check syntax with an external validator, and then inspect a test message's authentication results to see what receivers returned. Use a DNS lookup against **`_dmarc.yourdomain.com`** and confirm the TXT string matches what you meant to publish. A second pass with a DMARC checker helps catch malformed tag values and missing separators before you trust the record. Then send a message from the domain and inspect the **Authentication-Results** header, because that's where you learn whether the receiver saw a pass or fail and why. A few gotchas show up repeatedly: - **DNS caching:** a panel can show the change before global resolvers have picked it up. - **TTL mismatches:** the zone may still cache an older value longer than you expect. - **Trailing punctuation or typos:** one stray character can make a valid-looking record fail parsing. - **Wrong host name:** publishing at the root domain instead of `_dmarc` leaves receivers with nothing to query. Use those checks before you shift policy, not after. A live record that hasn't been verified is just an assumption in DNS clothing. ## Turning Reports Into Action Instead of Inbox Noise The bottleneck after you publish DMARC usually isn't DNS. It's whether someone reads the reports, understands them, and uses them to make policy decisions. Aggregate reports at **`rua`** are the main feedback stream, while **`ruf`** is for failure-level detail, but many organizations never get useful value from either because the reporting destination wasn't authorized or nobody built a review habit around the incoming XML. That's why I treat reporting as an operational process, not a checkbox. If your aggregate mailbox is quiet, first confirm the destination is valid and authorized. If it's noisy, the next question is whether the failures come from a known sender, a forwarding path, or a misaligned third-party system. The difference matters because monitoring-only records protect nothing until someone acts on the data. A weekly review cadence is usually enough to start. I look for three things only, whether the sender is known, whether failures cluster around one system, and whether a new source appeared without notice. If you want a practical parsing workflow, the walkthrough in [how to read DMARC reports](https://robotomail.com/blog/how-to-read-dmarc-reports) is the right companion piece. > **Practical rule:** if you can't explain the failed sources in your aggregate reports, you're not ready to raise enforcement. ## Troubleshooting the Most Common DMARC Publishing Errors The recurring failures are boring, which is why they keep costing teams mail. The good news is that most of them have a narrow symptom, a predictable cause, and a one-line fix. ### Duplicate records or the wrong host If receivers behave inconsistently or a checker shows an invalid policy, look for more than one TXT record at `_dmarc`. DuoCircle's Office 365 guidance is blunt about this, there should be **only one _dmarc record in the DNS zone** ([DuoCircle guidance](https://www.duocircle.com/resources/dkim-office-365/)). The fix is to delete duplicates and keep one canonical record per domain. If nothing resolves at all, the host is often wrong. A common typo is leaving off the leading underscore or publishing at the bare domain. The fix is to publish at the dedicated `_dmarc` node, not the apex. ### Syntax mistakes and report destination problems A malformed record usually comes from a broken tag pair, missing semicolon, or a typo in `v=` or `p=`. The fastest correction is to simplify the string until only the required tags remain, then add optional tags back one at a time. If the `rua` mailbox never receives anything, check whether the receiving domain has authorized the sender through `_report._dmarc`. ### Alignment failures that look like policy failures Sometimes DMARC is fine and your sender path isn't. If SPF and DKIM alignment both fail, legitimate mail will fail DMARC even when the record itself is valid, which is especially common in forwarded flows and mixed sending ecosystems. Microsoft's guidance is clear on that alignment dependency, and the fix is to repair the sender configuration rather than weaken the policy. For a broader triage flow, the note in [DMARC record not found](https://robotomail.com/blog/dmarc-record-not-found) is worth keeping handy. It's the kind of problem that looks mysterious in a dashboard and turns out to be a single DNS mistake. ![A checklist illustrating common DMARC record publishing errors to avoid when setting up DNS records.](https://cdnimg.co/9a227681-63f7-452a-a677-fb77b6767eba/566cc99a-50fa-4bfd-9663-3d4e72cc90d4/publish-dmarc-record-dmarc-checklist.jpg) The rollout checklist I use is short. Publish the TXT record at `_dmarc`, verify propagation, watch the reports, tighten policy in stages, and revisit subdomain architecture whenever a new sender gets added. That sequence keeps you from breaking mail with a premature reject policy and gives you time to fix SPF and DKIM where they matter. Robotomail supports custom domains with auto-configured **DKIM, SPF, and DMARC**, which makes it useful when automated mailboxes need to send and receive without hand-building every authentication step. If you're wiring DMARC into an agent workflow or a product stack, visit [Robotomail](https://robotomail.com) and compare how its mailbox and custom-domain flow fits your rollout plan.