DMARC RFC 9989 Part 3: Prepare for Enforcement

This is the third and final blog in our DMARC RFC 9989 deep dive series. In the first installment, we introduced the changes RFC 9989 brings to DMARC Organizational Domain and policy discovery. In the second, we explored how the new tags can be used to express policy intent more clearly while maintaining compatibility during the transition period as receivers adopt the standard. In this final installment, we outline a measured path to adopting RFC 9989 updates as both a Domain Owner and a DMARC enforcer, helping organizations strengthen protection against domain abuse while preserving legitimate email delivery and visibility into authentication failures. 

Key takeaways 

DMARC is a readiness decision, not just a DNS change. Before moving to ‘p=reject’ you need to know your legitimate senders, have SPF records reflect current authorization, DKIM sign mail wherever possible, and have reporting to quickly show when and why failures occur. 

This matters because RFC 9989 reinforces three practical points: SPF records need ongoing review, domains at ‘p=reject’ should not rely on SPF alone for DMARC pass, and receivers make the final handling decision using DMARC as an important signal alongside other controls. 

Before enforcing, confirm that your legitimate senders are authorized, DKIM-aligned, visible in reporting, and governed by the policy you intend receivers to apply. 

Start with enforcement readiness 

Preparing for DMARC RFC 9989 enforcement starts with knowing your email landscape. Before tightening policy, you need to confirm which systems and third parties send mail for your domains, whether they are authorized in SPF, whether the systems sign with aligned DKIM, and whether failures are visible enough to investigate and fix. 

DMARC RFC 9989 makes this validation more important because the policy or Organizational Domain used by a receiver may differ from what you expect under original DMARC. That can change whether SPF or DKIM aligns, which policy applies to failed mail, and how non-existent subdomains are handled through the ‘np’ tag. It also affects inbound enforcement planning: receivers may adopt RFC 9989 at different times, so teams need monitoring, reporting, and risk-based controls before moving to stricter handling. 

Know every system that sends mail 

Sender inventory is the foundation for DMARC readiness because legitimate traffic should pass DMARC before publishing a ‘p=reject’ policy. 

• Inventory email traffic that uses your domains. This can include traffic from corporate mail platforms, marketing tools, billing systems, HR applications, support platforms, and regional senders. 
• Investigate DMARC failures: 
  • Determine whether the traffic is legitimate. 
  • Review authentication patterns to identify the source of failures. 
  • Remediate legitimate traffic through DNS or email modifications, working with the sending platform where needed, to achieve authentication and alignment for both SPF and DKIM. 
  • Track senders that cannot directly support aligned DKIM. 
• Repeat this process on a regular cadence, as your organization’s email landscape typically evolves over time. 

Align SPF with current authorization needs 

DMARC RFC 9989 guidance reinforces the need to periodically review SPF records, so authorization matches current sending needs. As stated in DMARC RFC 9989 Section 7.1: "Domain Owners should periodically review their SPF records to ensure that the authorization conveyed by the records matches the domain's current needs."  

The goal of an SPF record is to align the content to legitimate traffic without being overly permissive or increasing the risk that malicious actors can send abusive traffic from your domains. Proofpoint Email Fraud Defense’s Hosted SPF helps achieve this outcome by reducing the operational burden of managing complex SPF records manually and by providing insight into IPs that are used. 

Regularly conduct SPF record hygiene: 

• Confirm each include still maps to an approved sending relationship.  
  • Remove vendors that no longer send on behalf of the domain. 
  • Avoid broad authorization that increases spoofing risk. 
• Add IPs for legitimate traffic, if not already included. 
• Use Hosted SPF to simplify maintenance and reduce complexity. 

Close DKIM gaps before reject 

Forwarding, relaying, and infrastructure changes can break SPF even when the original sender was legitimate. DKIM helps ensure this traffic can pass DMARC.  

Guidance in DMARC RFC 9989 Section 8 takes this a step further by strongly recommending DKIM signing, even if SPF passes, for domains at ‘p=reject’: “In order to fully participate in DMARC, Domain Owners:...MUST NOT rely solely on SPF for a DMARC pass if the DMARC policy for the Author Domain is "p=reject".” 

Domain Owners should do the following: 

• Identify high-volume or business-critical sources where DKIM does not sign and align. 
• Work with senders to remediate emails so that they are properly DKIM-signed.  
• Use an application sending platform like Proofpoint Secure Email Relay (SER), or a related sending system, to DKIM sign outbound traffic where application signing isn’t natively supported. 

Validate policy discovery and aggregate report destinations 

Before moving from monitoring to quarantine or reject, compare RFC 7489-era assumptions with DMARC RFC 9989 discovery. This is especially important in delegated or nested domain structures. 

Question	Why it matters
What is the Organizational Domain under RFC 9989?	Alignment depends on the selected boundary. Traffic that once aligned may fail if the boundary differs.
Which DMARC record is resolved under RFC 9989?	The applied policy may come from a different DNS location than expected.
Are the destinations of RUA and RUF reports as expected under RFC 9989?	If the applied record comes from a different location, visibility into aggregate reporting could cease if the destinations are different than expected.
Does the result differ from RFC 7489-era expectations?	A mismatch can change policy handling or alignment results.
Does SPF or DKIM align to the selected Organizational Domain?	Legitimate mail may need remediation before enforcement.
Does ‘p’, ‘sp’, or ‘np’ apply?	Existing and non-existent subdomains may have different handling.

 

The implication is that enforcement risk is not limited to the ‘p’ value. Risk also comes from incorrect assumptions about which record applies and whether identifiers align under the selected boundary. 

Enforce inbound policy with context 

Some teams worry that ‘p=reject’ means inbound mail must always be rejected solely because the domain owner published that policy. That is not the right operational model. DMARC RFC 9989 Section 5.4 provides guidance for mail receivers: “The final handling of any message is always a matter of local policy and is left to the discretion of the Mail Receiver… Mail Receivers MAY choose to reject or quarantine a message even if it passes the DMARC validation check. Mail Receivers are encouraged to maintain anti-abuse technologies to combat the possibility of DMARC-enabled abuse… Mail Receivers MAY choose to accept email that fails the DMARC validation check even if the published Domain Owner Assessment Policy is "reject"… Mail Receivers SHOULD NOT reject messages solely because of a published policy of "reject" but that they apply other knowledge and analysis to avoid situations such as rejection of legitimate messages…” 

Plainly put, receivers should combine DMARC results with broader security context, local policy, user risk, sender reputation, and business impact when handling a message. When deciding how to handle DMARC enforcement of one’s own domains on inbound mail, organizations can use Proofpoint to apply DMARC signals as part of guided inbound enforcement rather than treating the published policy as the only decision point. 

Investigate failures with enough detail to act 

Once policy tightens, the useful question is not simply whether a message failed. The useful question is why it failed and how to fix it. DMARC RFC 9989 makes failure investigation more precise, but it also adds questions teams need to answer. 

• Was the message evaluated using RFC 7489-era behavior or DMARC RFC 9989 behavior? 
• Did the resolved Organizational Domain differ from expected behavior? 
• Which authentication passed or failed? What remediation steps are required to resolve the issue? 
• Was the domain real or non-existent? 
• Which DMARC policy tag drove the requested handling? 
• Is this a legitimate source, a configuration issue, or abuse? 

How Proofpoint can help 

Proofpoint Email Fraud Defense helps by: 

• Identifying active senders and surfacing authentication gaps across your email ecosystem, including third parties. Email Fraud Defense helps you determine who your legitimate senders are and when they fail authentication.  
  • Providing clear remediation instructions for legitimate traffic to help resolve authentication issues faster so your good traffic gets delivered. 
• Surfacing DMARC RFC 9989 policy resolution details. 
• Supporting DNS changes through hosted services for simplified remediation of authentication issues and protection against spoofing. 
• Supporting DMARC enforcement for traffic that cannot DKIM-sign directly through Proofpoint Secure Email Relay.  
• Guiding inbound enforcement decisions with support from Proofpoint Professional Services consultants so DMARC signals can be applied in a risk-aware way.  

The result is a more controlled path to enforcement: known senders, stronger authentication, clearer failure investigation, and fewer surprises where unexpected DMARC policy is applied. 

 

Learn more 

Visit Proofpoint Email Fraud Defense to learn how Proofpoint can help you simplify DMARC deployment, improve email authentication, and accelerate your journey to enforcement. 

To learn how Proofpoint helps organizations defend against AI-scaled threats and advanced impersonation attacks across email and digital communications, visit Proofpoint Collaboration Security or contact your Proofpoint representative today.