RFC 9989 is now the official DMARC standard, replacing RFC 7489 and introducing several changes that organizations will need to account for over time. If you’re looking for a breakdown of the protocol-level updates, EasyDMARC’s Forget DMARC is article covers the technical details. For managed service providers, the bigger challenge is operational. This is not a one-record fix. When you manage dozens or hundreds of client domains, a standards update becomes a portfolio-wide project involving audits, policy reviews, client communication, and ongoing monitoring. The MSPs that approach RFC 9989 systematically can use it as an opportunity to strengthen client security, demonstrate proactive value, and expand recurring services across their portfolio.
Why This Lands Differently When You Manage 50+ Client Domains
For a single organization, an RFC 9989 review may involve updating a handful of records and validating that reporting and enforcement policies still align with current best practices. For an MSP, the scope is entirely different. A standards update has to be evaluated across every managed tenant, each with its own email infrastructure, vendors, reporting setup, and security maturity level.
The challenge is not just identifying which clients need a review. It’s doing so consistently and at scale. Some clients may still have legacy configurations that need attention. Others may have opportunities to strengthen subdomain protection, and many will be at different stages of their DMARC enforcement journey. Without a structured process, it becomes easy for gaps to go unnoticed across a large portfolio.
At the same time, standards changes create a natural opportunity for proactive engagement. Rather than waiting for deliverability issues or security concerns to surface, MSPs can use RFC 9989 as a reason to review client environments, provide recommendations, and demonstrate ongoing stewardship of the services they manage. For many providers, that conversation can also serve as the foundation for a more formalized DMARC management offering.
The Client Portfolio Audit: What to Inventory Across Tenants
Before making any changes, start with a portfolio-wide audit. The goal is not to start with manual domain-by-domain changes, but to identify patterns across tenants and group clients by the actions they need. For a deeper explanation of the RFC 9989 changes themselves, refer to EasyDMARC’s Forget DMARCbis guide. At the audit stage, the focus should be on what needs attention, not on the protocol details.
| Audit Item | What to Check | Priority | Recommended Action |
| pct= cleanup | Tenants still using the pct tag | Medium | Remove pct from DMARC records; deprecated under RFC 9989 |
| Records at p=none | Clients with no enforcement policy | High | Review aggregate report data; begin policy advancement conversation |
| psd= relevance | Clients operating a Public Suffix Domain | Low | No action needed for standard business domains |
pct= cleanup
RFC 9989 removes the pct tag from the DMARC specification, making it an important item to identify across client environments. Any tenant still relying on pct should be flagged for review and record cleanup. As adoption of the updated standard grows, leaving deprecated tags in place can lead to inconsistent behavior across different receivers.
Records stuck at p=none
Clients operating indefinitely at p=none should be treated as a separate priority group. RFC 9989 does not change the fact that monitoring-only policies provide no enforcement. Rather than reviewing these domains one by one, use the audit to surface them as a segment and build a structured policy advancement conversation around them.
psd= relevance
Most MSP clients will never need the psd tag. This setting is intended for operators of actual Public Suffix Domains and is not a routine consideration for standard business domains. During the audit, simply identify whether any client genuinely falls into that category and avoid treating it as a required review item across the broader portfolio.
The Client Conversation
Most clients do not follow DMARC standards updates, nor should they be expected to. The conversation is not about explaining RFC 9989 in technical detail. It’s about demonstrating that you are actively monitoring changes that affect their security posture and taking appropriate action on their behalf. Position the review as a proactive service touchpoint rather than a response to a problem or incident.
| What changed | The DMARC standard has been updated under RFC 9989. |
| What we are doing | Reviewing your email authentication configuration to ensure it aligns with current recommendations. |
| What is being phased out | Some older DMARC tags are deprecated and will be removed from your records. |
| What is being added | New options are available to strengthen protection against mail sent from domains that do not exist. |
| What you need to do | Nothing immediately. We will provide a summary of changes and recommendations once the review is complete. |
A simple client-facing message is often enough: the DMARC standard has been updated, some older DMARC tags are being phased out, new options are available to strengthen subdomain protection, and you are reviewing their environment to ensure everything remains aligned with current best practices. Framed this way, the discussion becomes a trust and retention opportunity. Instead of reacting to an issue after it occurs, you’re showing clients that their email security program is being actively maintained as standards evolve.
Turning the Standard Update into Recurring Revenue
For many MSPs, the RFC 9989 rollout is more than a technical exercise. It’s an opportunity to package email authentication management into a clearly defined service offering. Rather than treating the review as a one-time project, consider formalizing it as a deliverable such as an RFC 9989 Compliance Review, a Subdomain Coverage Assessment, or a DMARC Posture Audit. Giving the work a defined scope makes it easier to communicate value and standardize the process across clients.
The audit itself is only the starting point. Ongoing activities such as monitoring aggregate reports, reviewing np-related traffic, advancing enforcement policies, validating vendor changes, and maintaining visibility across client domains create long-term operational requirements. These are recurring services that require expertise, oversight, and consistent execution as client environments evolve.
EasyDMARC’s MSP Program provides centralized visibility, reporting, and client management capabilities needed to operationalize DMARC services at scale. TouchPoint can support the commercial side by helping MSPs turn email authentication signals into sales-ready opportunities.
Proactive Standards Management as an MSP Differentiator
Most clients will never read an RFC, follow DMARC working group discussions, or track changes to email authentication standards. They rely on their service providers to do that for them. The value of an MSP is not simply responding to problems, but identifying important changes before they become operational or security issues.
RFC 9989 is one of those moments. The MSPs that treat it as a proactive service opportunity can strengthen client trust, improve security outcomes, and create new recurring service conversations long before clients realize a standards update has taken place. Learn how EasyDMARC’s MSP Program and Touchpoint can help you manage and scale that process across your entire client portfolio.
Frequently Asked Questions
Start with clients that have the highest email volume, the most complex sending environments, or records that remain at p=none. These environments typically present the greatest risk and often require the most effort to review. A portfolio-wide audit can help segment clients by priority so you can focus on the domains most likely to benefit from immediate attention.
In most cases, no. RFC 9989 removes the pct tag from the DMARC specification, and receiver support for it has already been inconsistent. Clients should be evaluated individually, but for organizations already operating at their intended enforcement level, removing pct generally does not change the practical outcome of DMARC policy enforcement.
Keep the message simple. The DMARC standard has been updated, and you’re reviewing their email authentication configuration to ensure it aligns with current recommendations. This is not typically an emergency change. It’s a proactive maintenance activity designed to keep their email security posture current and identify any opportunities for improvement.
Probably not. The psd tag is intended for operators of Public Suffix Domains rather than standard organizations managing business domains. Most MSPs will never encounter a client that legitimately requires psd=y. If you believe a client may fall into that category, review the RFC requirements carefully before making any changes.
Not automatically, but it is a good opportunity to revisit the conversation. RFC 9989 does not change the purpose of DMARC enforcement, and domains operating indefinitely at p=none still lack policy-based protection. Use the audit process to identify these clients, review their reporting data, and determine whether they are ready to advance toward stronger enforcement policies.
We’re glad you joined EasyDMARC newsletter! Get ready for valuable email security knowledge every week.
You’re already subscribed to EasyDMARC newsletter. Continue learning more about email security with us
