What Happens After p=reject?

If you’re reading this and have made it to a p=reject DMARC policy, congratulations! You’ve gained the knowledge and awareness of how to protect your internet domains. Now that you’ve cataloged your domains, listed each of the vendors sending email on your behalf, identified who owns these services, reached DMARC compliance, and have a better understanding of your email footprint, you may be asking: What is next?

No matter where you are in your DMARC deployment project, it’s useful to know that reaching a policy of p=reject initiates the stage of DMARC maintenance and management. DMARC is not a set-it-and-forget-it project—monitoring your DMARC reports is vital in securing your email programs and staying ahead of cybercriminals.

Without a way to clearly and continually track the variation in how emails are sent on behalf of your organization, an untracked change could lead to delivery errors when at p=reject. dmarcian’s DMARC Management Platform ensures the lights are always turned on and that you have sufficient alerts and visibility at your fingertips.

Apart from email sending patterns, the health of your SPF, DKIM and DMARC records must also be monitored as any changes or errors can lead to diminished inbox placement or outright bouncing of email while at a policy of p=reject.

Our DMARC Management Platform allows you to be alerted when such issues are discovered, with the goal of minimizing the impact of your email programs and ensuring best practices have been applied and maintained to each of the email sources that send on your behalf. If you haven’t already configured alerts in Alert Central, we encourage you to do so now. All of our subscription plans support unlimited alerts.

Why Visibility Matters

If you’ve reached a DMARC compliance policy, here are several reasons to continue using our DMARC Management Platform:

  • Periodic checks of SPF records – Use the SPF Surveyor to ensure your SPF records are up-to-date by checking to see if any IPs or netblocks authorized to send email on behalf of the organization are in use or not. It’s always a good practice to review the contents of your record for vendors you no longer use or were added in error previously. This is referred to as over-authentication and is generally frowned upon by receivers.
  • Process of approving SPF changes – Make sure no SPF changes are made without the approval of the DMARC project owner at your organization. Enable the dmarcian platform to notify you via alerts when any unexpected changes have taken place.
  • Monitoring of periodic DKIM key rotation – For optimal security, DKIM keys should be rotated on a regular basis. Depending on the importance of the source of email, this could be every few months or yearly. Here’s a piece on that.
  • Periodic check of DMARC data – As your business grows, be sure to check for new sources of legitimate email. This same dataset can be used to launch other investigations such as tracking vendor consolidation opportunities, email volume changes, compliance regressions at a particular vendor, and unexpected delivery patterns.
  • Reporting – Configure dmarcian to send reports about the use and abuse of your domains.
  • Internal incident management – If there are email deliverability issues that are suspected to be DMARC-related, check for problems and solutions. Often, support organizations get limited or incomplete error tracing. You can get a much fuller picture by filtering DMARC data to understand the reach of the issue.

DMARC Maintenance

An organization’s DMARC maintenance issues often occur whenever vendors are onboarded or offboarded or if a change in a vendor relationship alters a vendor’s email sending behavior.

Without a way to clearly track who sends emails on behalf of your organization, these changes could easily be missed and have a serious impact on your email deliverability if already at a p=reject. Our DMARC Management Platform ensures the lights are always turned on.

While there are certain technical aspects to getting DMARC in place, such as making the necessary changes in DNS, much of the work involves communication and creating strong business processes that will remain in place after getting domains to p=reject.

To wrap it up here, once you have achieved a policy enforcement of quarantine or reject, there must be an ongoing effort to maintain DMARC compliance and minimize potential issues related to your DMARC policy enforcement. This phase of the DMARC project is focused on preparing the organization for unexpected problems as well as planned changes. Additionally, business processes should be in place now for onboarding new vendors in a way that bakes in DMARC from the beginning.

If you need assistance with DMARC deployment, monitoring or maintenance, register for a free trial with us, and we’ll assist you along the way.

Want to continue the conversation? Head over to the dmarcian Forum