DMARCbis RFC 9989: Does It Change Your Email Setup?

After years of discussion, drafts, and industry feedback, the work on a DMARC revision, DMARCbis. is finally complete. In May 2026, the Internet Engineering Task Force (IETF) published RFC 9989, the new official specification for Domain-based Message Authentication, Reporting, and Conformance (DMARC). Alongside RFC 9990 and RFC 9991, it replaces the original DMARC specification (RFC 7489) that organizations have relied on since 2015.

What is DMARCbis?

Think of DMARCbis as a DMARC1.1, minor improvements and backward compatibility from lessons learned through actual use during the last decade. DMARCbis is an update to the DMARC standard that adds a few tags, deprecates a few tags and splits the DMARC protocol from the reporting requirements to allow for innovation on each without ratification of changes to all.

The actual DMARC protocol portion has changed a bit.

Deprecated Tags

DMARCbis removes a couple of tags that have become unnecessary and reduces the complexity of setting up a new DMARC policy.

  • pct – Allows the sender to allocate a portion of their email to testing a new policy (Quarantine or Reject). This is being replaced by a testing mode. Since it was confusing to adopters and often ignored by inbox providers.
  • rf – Specifies the format of RUF reports. There is only one value currently supported, so it became unnecessary.
  • ri – Corresponds to the aggregate reporting interval. It must be daily (86400 seconds) or longer. Most providers report daily, which is the maximum frequency allowed, so this tag is mostly useless.

New Tags

The system allows for greater simplicity in rolling out new policies and handles a couple of important issues not covered in the original DMARC specification.

  • np – Defines a policy for non-existent subdomains, separating this policy from actual email sending domains. For example, email.example.com might be your primary email domain, while mail.example.com might not exist. Both appear valid, but could open you to risk of being used in fraud and phishing if not locked down by policy.
  • psd – Support Public Suffix Domains and enables DNS-based organizational boundary discovery. It will be used primarily by registry operators and large domain administrators.
  • t – Sets your policy in testing mode. This simplifies staged rollout of new policies while maintaining reporting.

New Policy Handling

Previously, the DMARC standard required that Inbox Providers adhere to the DMARC policy of a standard, quarantining or rejecting email that failed to DMARC compliance tests. In practice, Inbox Providers made their own email acceptance decisions, largely ignoring the DMARC policy or using it only as a trust metric. DMARCbis now formally acknowledges this practice and simplifies the deployment of new policies in a testing mode rather than an odd percentage.

For example, the new policy split will allow setting up a series of subdomain DMARC records with different policies secure to your root domain and person-to-person email (reject policy), handle the complex compliance issues of mailing lists and forwarding systems (quarantine) on a subdomain and building trust in outbound marketing campaigns (reject) through another subdomain. Other sources like order fulfillment, accounting/billing, etc. may require different policies to maintain trust.

What does your organization need to do?

If you have already adopted DMARC and you’re comfortable with your settings: Do nothing. DMARCbis is fully backwards compatible and simply provides new configuration options.

If you have not adopted DMARC, you need to do so as soon as possible to ensure email deliverability. When you do, consider leveraging the new simpler standard. When rolling out a new DMARC policy, the t (testing) option will simplify the testing and while maintaining reporting.

Did DMARC really need an update?

Over the last decade, DMARC adoption has increased dramatically, offering Inbox Providers a clear method to differentiate senders that take ownership of their email from those that do not or potential spammers. In that time, there has been the opportunity to learn and improve the standard especially since email has evolved from a single sending domain utilizing internal email servers to multiple email sending subdomains and multiple 3rd-party providers while dealing with sending systems that often break DMARC like mailing lists and forwarding.

In addition, moving DMARC from an Informational document to a Proposed Standard also provides some benefits:

  • Clearer requirements
  • Better interoperability
  • More consistent implementations
  • Less ambiguity between mailbox providers

How can MxToolbox help?

Regardless of where you are on the journey to adopt DMARC, you will need a tool to interpret the DMARC reports and help with your email delivery. MxToolbox Delivery Center is fully compatible with the latest DMARC standards. Whether you use the initial DMARC standard or the new DMARCbis tags, MxToolbox has you covered. If you would like to adopt DMARC with a trusted partner, MxToolbox offers a Managed Services approach that handles all your email delivery issues. Our experience team can get your email delivery on the right path and allow you to focus on your business.

Top 3 Reasons your email isn’t making the Inbox

Missing the inbox means lower open rates, lower click-through rates and ultimately fewer sales.  While there are many reasons why your emails are missing the inbox, there are three top areas you need to focus on:

  1. Email Configuration
  2. Reputation
  3. List Hygiene

Email Configuration

Email configuration goes beyond setting up an email server and getting your MX records published.  SPF, DKIM and DMARC are now required to make the Inbox at Google, Yahoo and Microsoft email hosting services, representing roughly 90% of world-wide email inboxes.  If you are sending email that fails DMARC compliance checks, you will miss the inbox and your campaigns will suffer.

Run an Email Health Scan at MxToolbox to check your email configuration against best practices.

Reputation

Reputation has evolved: it’s not simply about blacklisting antmore.  Now, you need to be aware of the reputation of your domain and content.  Google, Yahoo! and Microsoft maintain lists of sending email domains marked frequently as spam.  Land on their lists too frequently and your domain can be completely blacklisted from their inboxes.  Inbox Providers also analyzes email contents.  If your email content resembles the contents of emails that have been marked as spam, your email may be dumped to the spam folder.

Use MxToolbox Inbox Placement to see if your email makes the Inbox at Google, Microsoft and Yahoo!, gives you concrete reasons for missing the inbox, including blacklisting, reputation and configuration issues.

Email Hygiene

Keeping up with the quality of your mailing lists is important.  Older email addresses can go cold quickly, using purchased lists is very risky and being marked as spam will affect your inbox delivery rate.  Typically, a decision maker spends between 2 and 5 years in their role, receiving tens of thousands of emails.  If you have any email addresses older than 2-3 years in your lists, these have probably aged out.  In addition, using purchased lists and old email addresses can increase your spam rate as many users simply mark an email as spam if they don’t trust it. A high spam rate at Google, Yahoo! or Microsoft increases the risk that all your email will end up in the spam folder or your domain blocked entirely.

MxToolbox Delivery Center can help you keep tabs on your Google Spam Rate, Inbox Placement, Email Reputation, DMARC Configuration and more…

ARC Being Retired

For years, the email industry has been trying to solve a stubborn problem: What happens to authentication when a legitimate email gets forwarded, modified, or passed through an intermediary?

That question led to the creation of ARC — the Authenticated Received Chain protocol — published as RFC 8617 as an experimental standard. ARC was designed to preserve authentication results as messages moved between systems, helping receivers make better trust decisions even after SPF, DKIM, or DMARC checks were impacted by forwarding or mailing lists.

Now, after years of real-world experience, the industry is reaching a clear conclusion: ARC is not the long-term solution for cross-domain email authentication. The recommendation is that ARC no longer be deployed or relied upon between independent senders and receivers, and that RFC 8617 be officially reclassified as Historic.

So, What Was ARC Trying to Do?

Traditional authentication technologies like SPF, DKIM, and DMARC work well when email travels directly from sender to recipient. But, things get complicated when messages are forwarded, routed through mailing lists, or processed by security gateways that modify content or headers along the way.

ARC attempted to solve this by allowing each third-party system to “vouch” for what it saw when the message passed through, similar to a blockchain. In theory, downstream receivers could look at that chain of custody and make smarter decisions about whether the message should still be trusted.

The goal made sense — preserve trust even when the email path becomes messy.

What Happened In the Real World?

As organizations began deploying ARC, the industry gained valuable operational experience. And while ARC worked in some environments, broader adoption exposed a number of challenges

Different providers interpreted ARC chains differently. Trust relationships between unrelated organizations proved difficult to establish consistently. Validation logic became increasingly complicated. And, perhaps most importantly, ARC never demonstrated enough practical value to become a universally trusted signal across the Internet.

In many cases, it added complexity without delivering the level of reliability the ecosystem needed.

ARC Helped Shape What Comes Next

ARC succeeded in showing the industry what works, what doesn’t, and where future authentication efforts should focus. One of the most important outcomes of the ARC experiment is that its lessons are already influencing future authentication work, particularly ongoing discussions around “DKIM2,” the proposed evolution of DKIM.

Rather than continuing ARC as a standalone mechanism, the industry is now looking at what can be folded directly into next-generation authentication standards in a cleaner and more interoperable way.

That’s how Internet standards are supposed to work. We experiment. We learn. We improve.

ARC played an important role in that process.

Why Reclassify ARC as “Historic”?

Reclassifying RFC 8617 as Historic helps remove ambiguity about ARC’s status moving forward.

It signals to the industry that ARC should no longer be viewed as a recommended long-term deployment strategy between disparate mail systems. Instead, it becomes part of the historical evolution of email authentication — an important steppingstone that informed future work, even if it didn’t become the final answer.

ARC, Remembered

ARC was created to solve one of the hardest problems in email authentication, and it pushed the conversation forward in meaningful ways. While the protocol itself is being retired, the knowledge gained from deploying and evaluating ARC continues to shape the future of trusted email delivery.

In many ways, ARC did exactly what experimental standards are meant to do: Challenge assumptions, uncover operational realities, and help the industry move toward something better.

If you need help setting up SPF, DKIM, DMARC, or BIMI, try MxToolbox Delivery Center for all of your email delivery needs.

Why monitor DMARC compliance? DKIM Compliance Changes

DKIM is an important part of DMARC compliance and your email delivery reputation. DKIM allows you to cryptographically sign your outbound email, taking ownership of the email you send out: in a sense, binding your email to your reputation. If your DKIM compliance suddenly drops, it could reduce acceptance of your email or move your email from the Inbox to the Junk folder.

The Issues

DKIM is by nature and design a bit finicky. The signature is encrypted using the message itself. Changes to the message after the initial send, either via forwarding or a separate gateway or other alteration of the message breaks the signature. Forwarding is the most common reason for a message to fail DKIM checks. Since forwarding is fairly common, you should expect to always have a less than perfect DKIM pass rate, however, properly configured SPF records should ensure DMARC compliance.

Another potential issue is also a maintenance requirement: rotating keys and/or selectors. It’s a best practice to modify security codes regularly to prevent malicious actors from having access to systems if existing codes get into the wild. When you change them, there is however, the potential to omit a sender or DNS record. In addition, there is potential for slow DNS propagation. This could result in a higher-than-normal DKIM failure rate.

A common issue with 3rd party senders is the use of their own DKIM domain. In this case, the sender does not support using your sending domain and DKIM signatures but only their own. Email from these senders will pass SPF checks if properly included in your SPF record but fail DKIM alignment.

Remedies

To detect and understand these and other potential DKIM issues, you must be monitoring changes to your SPF, DKIM and DMARC compliance rates through DMARC reporting. If you have significant email volume, this is impossible to do without a tool that aggregates your DMARC reports from multiple inbox providers to get a complete picture of your email.

How does MxToolbox Help?

 MxToolbox Delivery Center provides everything you need to manage and maintain DMARC compliance rates to maintain a solid email delivery reputation, including:

  • Setup SPF, DKIM and DMARC for your Domain
  • Carefully migrate to a DMARC Reject policy
  • Setup your BIMI record
  • Verify compatibility of your SVG image
  • Monitor your certificates for expiration
  • Manage the on-going changes to the DMARC, SPF, DKIM and BIMI standards

If this sounds complicated, MxToolbox also offers Managed Services team that can help you setup DMARC, DKIM, SPF, BIMI and get your domain aligned with Google, Yahoo! and Outlook.com bulk sender policies.

Why monitor DMARC compliance? Sudden drops in SPF Compliance

DMARC compliance is a big part of a good email delivery reputation, but simply adopting and configuring DMARC is not the end of the journey, you need to keep monitoring DMARC compliance. There are several reasons to keep a watchful eye on DMARC compliance rates and the underlying SPF and DKIM compliance rates. Let’s take a look at a few recent examples.

The Customer

We recently had a customer with a sudden drop in SPF compliance affecting their email reputation. It could only be detected through regular monitoring of SPF Authentication through aggregated DMARC reports from Inbox Providers. At the same time, there appeared to be an increase in email volume, however, seasonal variations in outbound email volume may make that difficult to track.

Troubleshooting

There could be several reasons for a change in SPF compliance: an alteration to the SPF record or one of its underlying included SPF records from 3rd party providers, a phishing attempt using the customer’s domain or a new email source. To troubleshoot an issue like this, you need to know who the actual Sender is.

DMARC reports contain details of sending IP addresses, but not the company name. MxToolbox Delivery Center aggregates DMARC reports from the Inbox Providers and then correlates IP addresses in these reports with our databases of known 3rd party senders to determine if they are risky or legitimate. If legitimate, then the sender could be missing from the SPF record or there could be an updated range of IP addresses the customer or 3rd party sender failed to include in the SPF record.

In this case, MxToolbox determined that the sender was MailChimp, a legitimate provider of marketing email. An internal investigation by our client found that a department had started using MailChimp without informing IT. Without MailChimp’s sending IP addresses in the SPF record, much of that email had been rejected. The other department had been puzzled by low campaign open rates, but, had not realized that it was due to the sender being absent from the SPF record. Continued SPF Authentication issues could escalate the reputation issue potentially causing blacklisting of those IPs or wholesale rejection of email from that sender.

Other Issues

Another reason SPF compliance could suddenly drop is phishing attempts using your domain. A bad actor can use your domain for phishing attempts, suddenly increasing the volume of email appearing to come from your domain. Phishing is a huge security threat for both your domain and your internal staff. Again, investigations require aggregated DMARC reports to understand and uncover the issue. The only way to prevent phishing is to adopt DMARC reject policies.

How does MxToolbox Help?

 MxToolbox Delivery Center provides everything you need to manage and maintain DMARC compliance rates, including:

  • Setup SPF, DKIM and DMARC for your Domain
  • Carefully migrate to a DMARC Reject policy
  • Setup your BIMI record to get your logo in the Inbox
  • Verify compatibility of your SVG image
  • Monitor your certificates for expiration
  • Manage the on-going changes to the DMARC, SPF, DKIM and BIMI standards

If this sounds complicated, MxToolbox also offers Managed Services team that can help you setup DMARC, DKIM, SPF, BIMI and get your domain aligned with Google, Yahoo! and Outlook.com bulk sender policies.

The SPF Struggle is real – What happened at reddit?

We’ve talked about SPF Limits and SPF Flattening in the past. There is simply too much demand to get into the SPF record. Whether it’s adding a new sender or an existing sender updating and include, senders sometimes necessarily and sometimes lazily add too many lookups into your SPF record. In fact, one well-known CRM goes so far as to write dynamic macros in their SPF record to avoid hitting the 10 include limit.

What is the issue?

Currently, reddit has published an SPF record with too many includes, meaning that during email delivery, the last includes to be checked are dropped. This could leave one or more of reddit’s legitimate senders appearing to be spam or phishing because email from these senders will fail SPF Authentication.

In addition, reddit is running a DMARC policy of “reject”. While it is up to the individual Inbox Provider, a DMARC reject policy instructs the recipient systems to reject email that is not DMARC compliant, which means trashing any email that fails SPF Authentication. Essentially, there is an unknown amount of email from reddit that cannot be delivered, potentially affecting accounts, customers, purchases, etc.

What can they do?

There are several ways to get your SPF record below the 10 lookup threshold:

  • Manual or Automatic SPF Flattening as discussed in our blog.
  • Reducing the number of senders.
  • Splitting email sending across multiple domains or subdomains with separate SPF records.

All of these options have pros and cons. Many senders do not want to lose the cache of their primary domain, some cannot consolidate vendors to reduce SPF complexity, and some SPF records cannot be easily manually flattened. Even if you get below the threshold today, vendors may add new includes to their SPF records tomorrow pushing you over the threshold again.

What’s going to happen?

With a proper DMARC reporting and management system, like MxToolbox Delivery Center, they should already be seeing SPF failures and working to fix their SPF record. In the short-term, reddit will see some of their email bounce, in the long-term, this could cause their domain to have serious reputation issues.

How can MxToolbox help?

You first need to know if you have a problem before solving it.  MxToolbox offers a Free SPF Lookup Tool where you can check your real-time SPF configuration for errors, including the risk of “Too Many Includes”.  We also have a suite of Email Delivery tools to help you manage DMARC, SPF and DKIM and get your email to the Inbox.

DMARC Compliant but still going to Spam?

Many emailers consider DMARC compliance to be an end goal. This is only partially true. Adopting DMARC and sending DMARC compliant email is an important part of maintaining good email delivery, but DMARC is not the end of that journey. Let’s examine a few other things you need to be doing.

Adopting DMARC “Reject” policies

DMARC works best when your DMARC policy is 100% Reject for emails that are not DMARC compliant. 100% DMARC Reject indicates to Inbox Providers that you are confident that legitimate email from your domain is DMARC compliant and anything that is not compliant is spam, phishing or otherwise risky. 100% Reject policies are required to adopt BIMI and maintain compliance with Google, Yahoo! and Outlook.com bulk email sender policies.

Monitoring DMARC compliance

Your email configuration is not “set and forget”. Every time you change a technology provider, you will need to update your SPF record to send email from that system: CRMs, order management systems, Support, Marketing Automation, etc. all require an entry in your SPF records. Even if you do not change systems every few years, these companies will change their sending IP addresses or undergo mergers, forcing changes on you. You need to monitor your DMARC compliance or you may miss when email is rejected.

Adopting BIMI

BIMI can get your brand directly in front of your customers and prospects, within the Inbox. But, to adopt BIMI, you must be at 100% DMARC Reject policy. A Reject Policy requires monitoring of your DMARC compliance to prevent loss of legitimate email through misconfiguration.

Monitoring Inbox Placement

Even with 100% DMARC compliant email, you could be rejected from the Inbox. Inbox Providers maintain the equivalent of internal blocklists using customer sentiment and algorithms that judge similarity to spam to place email in Spam, Junk or Quarantine folders. If you are not monitoring your email for this, you will only find out after important email is turfed to the Junk folder.

Managing Email Senders

Your 3rd party email senders are an important part of your email delivery hygiene. A sender that mixes your email in with other clients’ email may cause issues due to the poor reputation of these other senders. If a shared IP address is blacklisted, your email may be blocked simply because some of it came from that server. Purchasing a dedicated sending IP space may reduce the risk, but it is always prudent to monitor your 3rd party senders for compliance and blocklist issues. If frequent blacklisting occurs, it might be time to look at new senders.

How can MxToolbox Help?

MxToolbox has been building email delivery management and monitoring tools for over 20 years. Our Experts know that email delivery is not static but an ever-changing arms race between spammers and Inbox Providers. Our MxToolbox Delivery Center tools are constantly updated to provide you with the latest in Email Delivery technologies:

  • Setup, Maintain and Monitor DMARC compliance
  • Adopt DMARC reject policies with confidence
  • Get your logo in the Inbox with our BIMI tools
  • Regularly test your Inbox Placement to quickly detect internal blocklisting
  • Get insight into your senders’ reputations with Adaptive Blacklist Monitoring

If this sounds complicated, MxToolbox also offers Managed Services team that can help you setup DMARC, DKIM, SPF, BIMI and get your domain aligned with Google, Yahoo! and Outlook.com bulk sender policies.

It’s Time for BIMI

For the last few years, we’ve been on the fence about when it would be time to implement BIMI. Often, it seemed like the ability to adopt BIMI would only be there for large companies with substantial email marketing budgets. However, support for both Common Mark Certificates as well as Verified Mark Certificates makes BIMI much more accessible for small and medium businesses. We now think BIMI is ready for everyone!

What is BIMI?

BIMI is a DNS technology that allows you to define a logo to appear next to your email subject lines or next to your messages in major Inbox Providers’ web-based, computer and mobile clients. Essentially, your mail will be branded with your logo giving you more exposure and potentially creating an edge over your competitors.

An example of the MxToolbox Logo displayed next to our email in Google’s web client.

Note: BIMI is different from simply being a GSuite-using company in that your BIMI logo will appear at Yahoo!, Le Post and many other web-based, computer and mobile email clients, not just the Google Inbox.*

How do you adopt BIMI?

To be BIMI compatible, you need to have your email configuration setup properly. Inbox Providers need a level of trust before they will include your logo as it appears to be an endorsement of sorts for your brand.

  • You must adopt DMARC, DKIM and SPF
  • Your email must be DMARC compliant
  • Your DMARC policy must be at 100% Reject
  • Your BIMI record must be setup correctly with a properly formatted SVG file
  • You must have a Common Mark Certificate or Verified Mark Certificate for your logo

How does MxToolbox help?

MxToolbox recently released a comprehensive answer to the issues of BIMI setup, management and maintenance. MxToolbox Delivery Center provides everything you need to:

  • Setup SPF, DKIM and DMARC for your Domain
  • Carefully migrate to a DMARC Reject policy
  • Setup your BIMI record
  • Verify compatibility of your SVG image
  • Monitor your certificates for expiration
  • Manage the on-going changes to the BIMI standard

Learn more on our BIMI feature page.

*A previous version of this blog included Microsoft Outlook.com. At this time, Outlook.com does not support BIMI.

The Double-Edge Sword of Generative AI and Email

For most people doing creative marketing work, Generative AI can be a huge asset. You can write white papers, create tag lines for ads, and develop new email campaigns quickly and easily. But, there are downsides to all of this productivity…

Losing your voice

Your voice, your brand, your identity. Losing this is easy if you are not careful how you deploy generative AI. Generative AI has its own voice, so you need to apply your brand to it before deploying the content it generates. Make sure it uses your verbiage, your terms and reflects your brand. If you don’t, you risk blurring into the background noise from all the other brands deploying generative AI in their campaigns. While Google, Yahoo! and Outlook.com have not disclosed policies or filters looking for generative AI, they are at the forefront of the technology, so you can be sure they are!

Going All -In

It may seem like a good idea to ramp up your outreach programs, especially email, now that you have a virtually unlimited source of content. Unfortunately, that can make your email delivery worse. Higher volumes of email can trigger greater scrutiny at Inbox Providers like Google, Yahoo! and Outlook.com, which could make it more difficult to make the Inbox. Further, you could induce email fatigue in your recipients. Fatigued users are:

  • Less likely to open your emails
  • More likely to mark them as Spam
  • More likely to Unsubscribe

Rather than increasing the quantity of your interactions, you should be looking to increase the quality: Better content yields better results.

Generative AI Phishing

If you can use Generative AI to create content for your legitimate business, rest assured that spammers, scammers and fraudsters are already fully embracing the ability to generate huge quantities of malicious content. This means that it is even more important to educate your teams about phishing scams and improve your email security.

In addition, it is now more important to protect your brand from being used in phishing attacks by adopting a DMARC Reject policy. Adopting DMARC and setting your DMARC policy to Reject will tell Inbox Providers to trash any email that appears to come from your domain that is not DMARC compliant. This makes it harder for phishing scammers to send email that appears to come from your domain. DMARC reject policies also enable you to adopt BIMI, which will get your brand logo into the Inbox alongside your email.

How MxToolbox Helps

MxToolbox is the expert in email delivery and email technologies. Our suite of email tools, Delivery Center, provides you with everything you need to:

  • Adopt DMARC
  • Get DMARC to a Reject policy
  • Adopt BIMI
  • Measure Inbox Placement
  • Manage the on-going maintenance of adopting new email technologies
  • Notify you of issues while they’re occurring to enable quick resolution and damage control

If this sounds complicated, MxToolbox also offers Managed Services team that can help you setup DMARC, DKIM, SPF, BIMI and get your domain aligned with Google, Yahoo! and Outlook.com bulk sender policies.

Getting DMARC to Reject

More and more, major Inbox Providers like Google, Yahoo! and Outlook.com are demanding DMARC compliance before allowing email into the Inbox. However, to get the best inbox placement and enable new innovations like BIMI, the policy in your DMARC record must be set to 100% reject.

What is a DMARC policy?

The DMARC policy is a setting in your DMARC record that specifies how a recipient should treat email from your domain that fails DMARC and what percentage of your email should be subjected to that treatment. DMARC policies can take on one of three options:

  • None – Do nothing if the email fails DMARC.
  • Quarantine – Move the email to quarantine for further processing.
  • Reject – Reject the email entirely if it fails DMARC.

A DMARC “reject” policy at 100% shows that you are confident in your email configuration and trust that anything appears to be sent from your domain that fails DMARC is likely junk, spam or phishing. You have done the work, so Google, Yahoo! and Outlook.com are more likely to trust you.

Lower trust levels and lower percentages are available for testing purposes, allowing you to gently move your email to stricter settings without impacting your existing email delivery. Most Inbox Providers will treat as suspect all email from domains with a non-reject DMARC policy and use their own internal processes to filter inbox delivery.

How to Get to “Reject”

Getting to a “reject” DMARC policy at 100% is a fairly straight-forward process of iteration.

  1. Gather a list of all your sending systems and ensure that they are in your SPF records.
  2. Setup DKIM and DKIM records for all your sending systems.
  3. Configure your DMARC record to send DMARC reports to a processing tool like MxToolbox Delivery Center.
  4. Review your DMARC reports for missing senders that fail DMARC (go back to step 1 until you uncover all of your legitimate senders).
  5. Modify your DMARC record to a 10% reject policy.
  6. Review your DMARC reports, Delivery Rates, and Open Rates for issues and analyze for a week or a major newsletter cycle.
  7. When satisfied that email delivery is acceptable, return to the DMARC record, changing your policy to 25%, 50% and, eventually 100% while continuing to review as in step 6.
  8. Maintain your review of your DMARC delivery statistics to ensure new senders aren’t accidentally installed and changes at existing senders are incorporated into your SPF and DKIM records.

Iterate through this process as necessary. While Quarantine is available as a policy, MxToolbox Experts have found that it is preferable to skip using Quarantine. Most major Inbox Providers treat non-compliant email from a domain with a DMARC policy of None or Quarantine the same. Stepping through Quarantine will simply delay getting to your goal.

How does MxToolbox Help?

MxToolbox Delivery Center provides everything you need to manage your DMARC, SPF and DKIM setup, move to a DMARC reject policy and manage the on-going maintenance and analysis of DMARC reports.

Manage SPF Setup

Every system that sends email on behalf of your domain must be in your SPF record for the email to be SPF compliant. Unfortunately, many providers get lazy with how they define the entries they want included in your SPF records, often proscribing large ranges or including macros. Sometimes, multiple systems will include the same ranges (GSuite systems being the most duplicated).

MxToolbox helps you manage this by giving you a list of all your Verified Sources, the ability to instantly manage your SPF record, detect overlapping includes in your SPF record and, even upgrade to SPF Flattening should your record have too many includes.

Hosting Your SPF with MxToolbox

Hosting your SPF record with MxToolbox through our SPF Hosting Integration, will enable you to modify your record and add new senders to your SPF record without having to log in to your DNS host.  Additionally, our system will help you avoid configuration errors and make suggestions as to what senders to include in your SPF record without having to leave your MxToolbox account.

With an MxToolbox hosted SPF record, your business can:

  • View your entire SPF setup on one screen
  • Manage your record through Verified Sources
  • Make changes to ensure your SPF record is correct and valid
  • Manage vendors and update providers
  • Enable automated options that automatically keep your record up to date

More MxToolbox SPF Management

MxToolbox Delivery Center Plus also offers SPF Flattening, which rewrites your SPF record. If you have more than 10 lookups included in your SPF record, the later lookups will not be executed, leaving some of your legitimate email senders to bounce. SPF Flattening helps “iron out” any SPF record issues and instantly creates a new, properly configured record to increase your email delivery rates.

Manage DMARC Setup

Similarly to SPF management, MxToolbox Delivery Center can host your DMARC records, allowing you to quickly and easily manage your DMARC records through the iterative process of implementing a 100% Reject policy.

  • View and Inspect your existing DMARC record for configuration issues
  • Manage changes on-the-fly to your DMARC record
  • Quickly modify your DMARC policy
  • Easily adjust the percentage of email subject to the DMARC policy

With MxToolbox Delivery Center Products, the iterative process of getting to 100% Reject is simple and easy!