# How can you simplify the journey to DMARC enforcement? > How can you simplify the journey to DMARC enforcement? Inventory senders, verify alignment, test real mail, then change policy with evidence. Simplify the journey to DMARC enforcement by treating it as an evidence and ownership process, not a DNS switch. Publish a monitoring record, use aggregate reports to identify every observed sender, confirm which senders are legitimate, repair SPF or DKIM alignment, test real production mail, and only then request a stronger DMARC policy. The operator still approves sender status and changes the externally hosted DNS record. ## Quick takeaways - DMARC passes when SPF or DKIM passes with an identifier aligned to the visible From domain. - A `p=none` record requests reporting without asking receivers for quarantine or rejection. - Aggregate reports identify observed sources and authentication outcomes, but they do not prove that a source is business-authorized. - RFC 9989 makes the former `pct` tag historic and defines `t=y` for policy test mode. - A receiver can apply local policy beyond the domain owner's DMARC request. - A green DNS result or vendor status does not prove that the production application is signing and sending as intended. ## How the path to enforcement works [DMARC, defined in RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), lets a domain owner publish a DNS TXT policy for messages that use the domain in the visible From field. A message can pass DMARC when either SPF or DKIM passes and the authenticated identifier aligns with that visible From domain. The receiver evaluates that result before considering the published DMARC policy. The main policy values have distinct jobs: - `p=none` asks for no specific handling of DMARC failures. It is commonly used while the domain owner gathers aggregate-report evidence. - `p=quarantine` asks receivers to treat failures as suspicious. - `p=reject` asks receivers not to accept messages that fail DMARC. These are requests, not guarantees. [RFC 9989's receiver requirements](https://www.rfc-editor.org/rfc/rfc9989.html#section-5.4) allow a receiver to consider other local signals and policy. The work becomes manageable when ownership follows the evidence. The messaging or security team reviews observed sources, application owners confirm legitimate services, and DNS owners approve the policy record. That avoids a common mistake: treating every source in a report as approved mail. For protocol context and related terminology, see the [Palisade DMARC learning hub](/learning/dmarc). ## When the answer changes The route needs extra care when mail changes identity in transit. [RFC 9989's interoperability guidance](https://www.rfc-editor.org/rfc/rfc9989.html#section-7.4) says general-purpose domains whose users send mail through Internet mailing lists should not publish `p=reject` without addressing the resulting interoperability risk. Forwarding and mailing-list flows can alter SPF and DKIM results, so validate those paths with delivered-message headers and report data before increasing policy. Use this decision rule: - If a source is recognized and has an aligned SPF or DKIM pass, keep monitoring its real production path. - If a source is recognized but fails alignment, repair the vendor configuration or sending-domain setup before enforcement. - If a source is unfamiliar, ask the relevant business owner to classify it. Do not authorize it from an IP address alone. - If a low-frequency sender has not appeared in recent reports, test it deliberately before moving policy. - If an indirect flow such as a mailing list matters to your domain, validate that flow separately and retain a rollback plan. > Do not publish two DMARC TXT records at the same `_dmarc` hostname. RFC 9989 treats multiple records at the same policy-domain name as a DMARC processing error, which can leave receivers without a usable policy. ## A worked monitoring-to-enforcement record A DMARC policy record is a TXT record at `_dmarc.` and begins with `v=DMARC1`, as specified in [RFC 9989's record format](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.8). ```text Illustrative only. Do not publish this reporting address. Type: TXT Name: _dmarc.yourdomain.com Content: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com TTL: Auto ``` `example.com` is a reserved example domain. Use a reporting address that your organization controls and that is authorized to receive the reports. A `rua` address gives the record a plausible shape but does not create monitoring. In Cloudflare, [create a DNS record from DNS Records, Add record, then choose the record type and complete the fields](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/). Enter `TXT` as the type, `_dmarc` as the name for the zone's root domain, the complete DMARC value as content, and the TTL approved by your DNS change process. Confirm there is no existing DMARC TXT record first, then save only through the approved change path. After reports accumulate, use the reported source, aligned domain, authentication outcome, and message volume to create a sender inventory. Follow each source through four checks: - Query authoritative DNS and at least one public resolver to confirm the intended record is published. - Check the sending vendor's current authentication status. - Send a real message through the exact production application and inspect its `Authentication-Results` header. [RFC 8601 defines this header field](https://www.rfc-editor.org/rfc/rfc8601.html). - Review DMARC aggregate reports after enough data accumulates to cover the sending pattern. ![Decision flow for moving a domain from DMARC monitoring to quarantine or reject based on sender ownership, alignment, real-message testing, and aggregate-report evidence](/images/editorial/how-can-you-simplify-the-journey-to-dmarc-enforcement/how-can-you-simplify-the-journey-to-dmarc-enforcement-enforcement-decision-flow.webp "1200x829") *Source: Palisade.* When you are ready to test a stronger policy, use RFC 9989's current semantics. The [`pct` tag](/learning/glossary/dmarc-pct) is historic because intermediate percentages were implemented inconsistently. With `t=y`, `p=quarantine` requests an applied policy of `none`, while `p=reject` requests an applied policy of `quarantine`. [RFC 9989's testing tag definition](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7) describes that one-level reduction. ```text Illustrative only. v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@yourdomain.com ``` Keep the previous record, the approved next record, a rollback trigger, and an owner for unresolved senders. After each change, repeat the DNS, vendor, message, and aggregate-report checks. A published record alone cannot show that every business-critical application is aligned. ## The practical next step Start with the evidence you have: - If you only have a domain name, [check the published DMARC record](/tools/dmarc) and compare it with your approved DNS change record. - If you have aggregate reports, turn them into a sender list, then assign each unfamiliar source to a business owner for classification. - If you have a known sender failure, inspect a delivered message from that production path before editing SPF, DKIM, or DMARC. - If the wider problem is organizational ownership and stalled approvals, read [why corporations struggle with DMARC enforcement](/learning/why-do-corporations-struggle-to-move-from-dmarc-awareness-to-enforcement). Palisade is agent-first DMARC software that analyzes DMARC aggregate-report data, identifies observed sending sources and authentication or alignment issues, creates prioritized remediation tickets, and proposes a next policy milestone when the evidence appears ready. The human team reviews unfamiliar senders, remediation evidence, policy timing, and the DNS change. ## Continue the enforcement work with report evidence A DMARC record lookup can confirm what DNS publishes today, but it cannot inventory every production sender that later fails alignment or monitor new sending paths. Palisade organizes aggregate-report evidence and remediation work so the team can review a proposed move toward enforcement with the relevant sender context. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_enforcement&utm_content=how-can-you-simplify-the-journey-to-dmarc-enforcement) Palisade does not autonomously change an externally hosted DMARC record, guarantee delivery or inbox placement, or replace business-owner approval for unfamiliar senders. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Cloudflare: Create DNS records](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/) - [Palisade domain overview documentation](https://docs.palisade.email/page-breakdowns/domain-overview) - [Palisade guide to fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues) ## Frequently asked questions ### Can I move directly from `p=none` to `p=reject`? Only if the domain owner has already inventoried legitimate senders, validated aligned authentication on their real production paths, and addressed relevant indirect-mail flows. A change to `p=reject` can affect legitimate mail that still fails DMARC. ### Does `p=none` stop spoofing? No. `p=none` asks for no specific receiver handling of DMARC failures. It can request aggregate reports through `rua`, which provides evidence for sender inventory and remediation. ### Does a DMARC aggregate report prove that a sender is legitimate? No. An aggregate report shows observed traffic and authentication results. Business owners still need to confirm whether an unfamiliar service is authorized to send using the domain. ### Should I use `pct` to stage DMARC enforcement? No. RFC 9989 marks `pct` historic. Use current policy testing semantics with `t=y` where appropriate, and validate how important receiving environments handle the policy. ### Does `p=reject` guarantee that spoofed mail never reaches recipients? No. `p=reject` is a strong request to receiving systems after DMARC failure. Receivers make their own final decisions, and DMARC does not guarantee delivery, inbox placement, or a uniform outcome at every receiver.