Tag Archives: DMARC

DMARC Policy Enforcement – the Value

Last week, we discussed three myths that hold businesses back from configuring DMARC for policy enforcement. In this article, we will highlight all the advantages of DMARC policy enforcement and why these greatly offset the risk discussed last week.

Benefit 1 – BIMI

Would your marketing department love to have your logo next to your email campaigns? Of course! BIMI does that for you at many inbox providers worldwide! To adopt BIMI and get your corporate logo next to your email, you first need a strict DMARC policy at 100% quarantine or reject. Learn more about BIMI to understand the additional requirements to adopt BIMI.

Benefit 2 – BEC prevention and cyber-attack insurance

Business Email Compromise (BEC) often occurs through email that appears to come from a trusted internal source. When a business lacks DMARC policy enforcement on inbound and outbound email, BEC fraud becomes simpler for scammers; all they need to do is spoof the existing domain without the need to use a look-alike domain. By adopting a strict DMARC policy for outbound mail and a receiving policy that rejects or quarantines inbound mail failing DMARC, businesses make BEC more difficult. Many cyber insurers now ask about DMARC enforcement during underwriting, and it can affect eligibility and premiums.

Benefit 3 – Reputation Improvements

Inbox Providers like Google, Yahoo and Microsoft leverage proprietary acceptance algorithms based upon sender domain reputation and content reputation as well as meeting certain bulk sender requirements. DMARC policy enforcement is a clear trust statement by a business, that puts your domain ahead of bulk sender requirements.

Benefit 4 – Government Compliance

Government agencies across the world (US, UK, Canada, the Netherlands, Australia and others) require DMARC policy enforcement on their own domains and some require the same of contractors. Since governments and government contractors are major targets for compromise, DMARC policy enforcement helps protect sensitive communication and important governmental data.

Benefit 5 – SOC2, ISO27001 and other standards

Many standards like SOC2, ISO27001 and PCI-DSS require methods to protect and secure sensitive business communications. While not specifically required by SOC2 and ISO27001, DMARC policy enforcement supports and evidences the controls necessary for the standard. PCI-DSS cites DMARC, DKIM and SPF specifically in the guidance to meet the standard. Learn more about PCI-DSS.

How can MxToolbox help?

MxToolbox has over 20 years experience in Email Delivery with Blacklist, DMARC and Inbox Placement solutions designed to improve your email delivery and get your email to the inbox. DMARC policy enforcement is an integral piece of the email delivery puzzle and our tools make it easy to adopt DMARC and migrate to a strict enforced DMARC policy. Learn more about how MxToolbox Delivery Center can help with DMARC policy enforcement.

DMARC Policy Enforcement – the Myth

Policy enforcement can be one of the most valuable aspects of DMARC. Unfortunately, only 80% of businesses are taking advantage of it, primarily due to misunderstandings of the technology that lead to fear. Let’s investigate some of the myths and payoffs to adopting restrictive DMARC policies.

Myth 1 – DMARC Policy enforcement is complicated

Truthfully, it is more complicated that simply adopting DMARC. Many companies simply created a DMARC record to comply with Google and Yahoo bulk sender requirements. However, with DMARC policy enforcement, businesses need to iteratively adopt strict policies, monitor the outcomes and then designate someone to actively monitoring DMARC compliance rates. While this appears more complex, you can easily accomplish this with a service, like MxToolbox Delivery Center, that integrates iterative policy adoption, monitors your SPF, DKIM and DMARC compliance rates and alerts you to possible issues.

Myth 2 – DMARC policy won’t improve my email campaign performance

While a strict DMARC policy does not appear to aid email campaign delivery directly, it actually affects your spam rate. Google, Yahoo and Microsoft have adopted Bulk Sender requirements that mandate a maximum spam rate, the percentage of emails from a domain marked as spam by their users. With an open DMARC policy spammers and fraudsters can send email that appears to come from your domain and is likely to be marked as spam. By adopting a strict DMARC policy, you are filtering out that poor quality email from spammers and fraudsters before it could be marked as spam. By reducing your apparent spam rate, setting up a strict DMARC policy will actually improve your inbox performance.

DMARC enforced email indicates that a business takes ownership of its email delivery.

Myth 3 – A strict DMARC policy might block legitimate email

Unfortunately, this is the most pervasive belief in the industry. While there is some truth to this belief, when properly configured and monitored, there is minimal risk of losing legitimate email to strict DMARC policy enforcement. Using a DMARC management, reporting and monitoring tool like MxToolbox’s Delivery Center, businesses will have all the tools necessary to set a strict DMARC policy, monitor senders for DMARC compliance and alert when a sender is non-compliant. With proper setup, the only email you might lose to strict DMARC enforcement:

  • New senders not authorized in the SPF record lacking correct DKIM setup. Monitoring tools will quickly alert to missing senders like this.
  • Forwarded or mailing list emails that improperly modify the header and break the DKIM signature. While ARC was intended to address this issue, most forwarders now respect the DKIM signature, so this problem is vanishing.
  • DKIM Key rotation errors. This issue should be quickly discovered and short lived.

How can MxToolbox help?

MxToolbox has over 20 years experience in Email Delivery with Blacklist, DMARC and Inbox Placement solutions designed to improve your email delivery and get your email to the inbox. DMARC policy enforcement is an integral piece of the email delivery puzzle and our tools make it easy to adopt DMARC and migrate to a strict enforced DMARC policy. Learn more about MxToolbox Delivery Center.

Why Email Deliverability Tools Fail Businesses

Email deliverability is a broad category of tools designed to help your organization get your email messages to your intended recipients. Subcategories of tools include:

  • TLS Reporting
  • MTA-STS Reporting
  • Blacklist monitoring
  • DMARC Compliance Management and Reporting
  • Inbox Placement Analysis
  • Email Warming
  • Google Postmaster and other Feedback Loops

Clearly, there is a lot to unpack here, and that’s the start of why many tools fail their business customers: too much complexity.

Complexity

The landscape of email deliverability solutions is very complex. Most vendors focus on a narrow area of email delivery. Take a few different examples:

  • DMARC Management and Reporting is a maturing specialty market with a large number of providers often offering only DMARC and nothing more.
  • Blacklist solutions market has been around almost 20 years with only a few specialty tools with blacklisting becoming less of a hindrance due to the use of mass cloud-based emailers.
  • Email Warming is a highly niche market with few entrants as cloud-based email solutions reduce the need for much of it.

This level of complexity can mean a business either needs to adopt multiple solutions or miss out on some of the functionality they need to manage email deliverability. A full email deliverability suite will allow management and reporting of the most important layers of email deliverability:

  • Blacklist Monitoring and Management
  • DMARC Compliance Management and Reporting
  • Inbox Placement Analysis
  • Google Postmaster and other Feedback Loops

Organizational Ownership

There are a few major business cases driving adoption of email deliverability technologies:

  • Protecting the brand from being used in fraud and phishing, usually driven by IT Security
  • Improving email delivery rates to increase downstream email metrics including sales.
  • Meeting Google, Yahoo and Microsoft bulk sender requirements to keep access to their inboxes.

Typically, Marketing drives the last two use cases. While IT and Marketing both have reasons to improve email deliverability, coordination is required for both of them to achieve value. Marketing owns the sales outcomes and will drive much of the adoption of email deliverability tools, but IT will end up implementing many of the underlying technologies, including SPF, DKIM and DMARC DNS entries. Lacking tools for both Marketing and IT to achieve their goals is another way email deliverability tools fail businesses.

What “delivery” actually means

Unfortunately, there are multiple very specific definitions around email delivery, and they differ from the popular idea of what it means for an email to be delivered.

  • Delivery – Technically, an email is considered delivered when the receiving server accepts the email from the sending server. This means a complete SMTP negotiation of the email payload via accepted TLS encryption. Most email is rejected at the server if not properly encrypted.
  • Quarantine Delivery – Many systems will accept an email, run email filtering algorithms and place the email in a quarantine box that only IT email administrators can access.
  • Spam/Junk Folder Delivery – Specialized algorithms at inbox providers like Google, Yahoo and Microsoft sift through incoming email for compliance with content and reputation rules, including algorithms that compare content to known spam content.
  • Inbox Delivery – This is the holy grail for email delivery and what most people assume “delivery” means. In fact, Inbox Delivery only occurs if the email passes many tests.

Since final inbox delivery is not guaranteed, email deliverability tools need to measure Inbox Placement in addition other email delivery metrics.

Email Deliverability is a Moving Target

Email is an ever-changing landscape attempting to balance accepting important correspondence while blocking unwanted or harmful email. Since the first days of email, spam has been a threat to inboxes. Back then, spammers setup their own email servers and broadcast from static IP addresses giving rise to IP-based blacklists. Then, specific domains were known to send spam, so domain-based blacklists were created. Now, spammers can setup and teardown email servers programmatically making spoofing easy while avoiding blacklists. DMARC forces those spammers to step through a few additional compliance hoops and ensures that they can’t use imitate legitimate domains. Now we have proprietary content algorithms for inbox placement. In the future, there will be additional AI-driven acceptance criteria to combat AI-based spam, spoofing and other malicious email. The arms-race is constantly evolving so email deliverability tools must as well. Businesses lose out if they are not subscribing to email deliverability tools that are also constantly evolving.

How MxToolbox Helps

MxToolbox has over 20 years of experience in Email Deliverability technologies. Starting from basic DNS lookups to help IT admins setup email servers, we have constantly improved our free tools and paid email delivery solutions to meet the constant changes in the market. At MxToolbox.com, you can get free TLS Report, MTA-STS, SPF, DKIM, DMARC and Blacklist lookups.

Our paid suite, MxToolbox Delivery Center provides everything you need to manage your email delivery through its constantly changing requirements. We provide:

  • Adaptive Blacklist Monitoring
  • DMARC Reporting and Management
  • Inbox Placement Analysis
  • Feedback Loop integration including major vendors and Google Postmaster reporting.

In addition, we have a team of experts that can provide a Managed Services approach to email delivery. We can take over or simply assist you with improve your email deliverability, managing your adoption of DMARC and other email deliverabilty issues.

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.

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.

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.

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.

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!

Apple to Support BIMI in Native Mail Applications

Apple Mail recently announced BIMI adoption within its email applications in iOS 16 and MacOS Ventura. In September. Apple will become the most recent email client to support BIMI.

Why adopt BIMI?

BIMI gives email recipients more confidence in messages they receive and helps them avoid fraudulent emails by forcing senders to utilize new technologies to make email more secure.

BIMI gives marketers and businesses enhanced branding opportunities by attaching the company’s logo to verified messages in the inbox as a reward for adopting DMARC email security technologies. Your customers will trust your correspondence more and your brand will be enhanced.

What is BIMI?

BIMI, or Brand Indicators for Message Identification, is a DNS-based email technology that allows a company to specify a logo for inbox providers to display in an email client. Email providers, such as Gmail, Yahoo Mail, and now Apple Mail, can show this logo to their users in the subject line of certified messages from the sending company. If you receive a legitimate email from Yahoo!, for example, this logo will appear:

How do I get BIMI?

BIMI requires DMARC. Before you can get your logo displayed in Apple Mail’s inbox, you need to get your email fully DMARC compliant, then apply strict DMARC policies. Becoming DMARC compliant is a process, but it is very beneficial and strongly recommended. You need to know who is sending email on your behalf, ensure they are properly configured with both SPF and DKIM, and regularly monitor DMARC delivery reports to understand DMARC compliance.

Once your verified email sources are fully DMARC compliant, you can start enforcing stricter “Quarantine” or “Reject” policies with your DMARC configuration. Inbox Providers like Yahoo!, Google and now Apple Mail will only attach a BIMI logo to your email if the email is DMARC compliant and you have a “100% Reject policy”.

Need Help with BIMI and DMARC?

Checkout your BIMI configuration

Our free BIMI Lookup tool searches for a BIMI record for any submitted domain name. If a record is found, it is shown in detail after a series of diagnostic checks are performed against the record. For example, below are the results for chase.com.

Get DMARC Compatible!

To maintain the highest levels of email deliverability using DMARC, businesses like yours need a proven Email Delivery management system, such as MxToolbox Delivery Center. Our Delivery Center provides valuable insight into your email delivery status and the continual maintenance necessary to sustain peak performance, including:

  • Manage SPF, DKIM, DMARC, and BIMI to improve compliance and reduce the threat of fraudsters and phishing campaigns using your domain.
  • Review daily volume and SPF, DKIM, and DMARC compliance rates to ensure the best email deliverability.
  • Implement Feedback Loops (FBLs) to gain unique data on how your recipients view your emails and when they mark them as spam.
  • Gradually move your DMARC policy to “Reject” to enable better inbox placement opportunities and reduce the risk of phishing and fraud using your domain.
  • Manage the ongoing requirements of maintaining optimal levels of email deliverability and security.

Want more assistance? MxToolbox has a Managed Services offering to get you DMARC compliant and maintain the highest levels of email delivery.

Google’s Recent SMTP Relay Exploit and DMARC Policies

In April, Google began to see an uptick in spoofing attacks that utilized their SMTP Relay system and compromised Google accounts. They have closed the loophole by May, however, at least 30,000 malicious emails were detected in a two-week period. While this is an extremely small chunk of Google’s email traffic, similar exploits can affect other outbound email providers, requiring patches and constant vigilance.

What is the SMTP Relay exploit?

Google has a great reputation as an outbound sender so email coming from their servers is generally accepted. Google allows their customers to leverage that reputation to send bulk or large quantities of email through the SMTP Relay connection. Before the fix, this enabled any Google customer to send email that looked like another Google customer by simply putting their domain in the “From:” field. For example, SmallCompany.com gets hacked by a scammer and begins to send email that looks like GreatBrand.com, a well respected company also hosted at Google.

  • Blacklists – Google rotates sending IP addresses to minimize the affects of blacklists so a blacklist will not generally catch this issue.
  • SPF Authentication – Both SmallCompany.com and GreatBrand.com have Google’s servers in the SPF record, so it passes Authentication. This might be enough to make the inbox.
  • SPF Alignment – The “From:” address says GreatBrand.com. The <ReturnPath> is SmallCompany.com so it fails SPF Alignment.

So, unless the recipients servers are configured to check SPF Alignment, the Spoofing email may make the inbox. Any brand could then be compromised by a hack to another company in the same outbound email provider.

How do you protect your brand from spoofing?

First, you might think to bring all email in-house. This just compounds your risk. Google and other outbound email providers have more security experts and experience than even most large companies can ever hope to bring to bear. A small or medium business should leverage that experience to protect their brand and get their emails delivered.

Second, adopt DMARC and SPF, and DKIM. A properly configured SPF, DKIM and DMARC setup will help prevent spoofing of your brand and give you insight into potential spoofing issues.

Finally, adopt DMARC “Reject” policies. A DMARC “Reject” policy instructs recipient providers to highly scrutinize in-bound email and reject anything that fails SPF Alignment or Authentication. A “reject” policy would immediately fail email that arrived using the recent SMTP Relay exploit.

Why are few companies adopting “Reject” Policies?

If “reject” policies are great, why aren’t companies adopting them immediately? Unfortunately, there is a lot of fear and misunderstanding about “reject” policies. Our Experts receive push-back every day from our clients. Let’s look at a few examples:

“My legitimate email might be rejected”

While it is possible for legitimate email to be rejected, it is far more likely to be accepted if you have a “reject” policy in place. Inbox providers are looking for relevant content from senders with good reputations. By telling setting up DMARC with a “reject” policy you are telling them that you value your reputation. In addition, the “reject” policy is telling them to throw out emails that might harm your reputation.

“I won’t know if a legitimate source comes online”

Maintaining good email delivery means ensuring that all your legitimate email sources are managed actively. Each source should be included in your SPF record to ensure SPF Authentication. While it is possible for a department to bring in a new 3rd party email source without telling you, these vendors will have detailed information about proper SPF configuration as part of their on-boarding process. If it still slips by, then is it really valid email? Could that rogue department be hurting your brand? Regardless, a comprehensive DMARC reporting tool, like MxToolbox Delivery Center, will alert you that a potential Verified Email Source is missing.

“I won’t know if a phishing attack occurs”

The beauty of DMARC is that by publishing a DMARC record with RUA and RUF tags, you are asking for information about the compliance of emails that come “from” your domain. Inbox providers will tell you through an XML email report. Regular reviews of these reports will give you insight into legitimate sources that fail as well as emerging email threats from phishing attacks using your brand. While you can manually parse these XML files, most companies rely on a reporting tool, like MxToolbox Delivery Center, to process and distill these files into actionable insights.

“It seems complicated…”

While it can take some time to verify your outbound email sources, ensure that SPF and DKIM configurations are correct and monitor DMARC reports to ensure that everything is properly tuned, moving to a “reject” policy is not very complicated. MxToolbox Delivery Center uses our experience with DMARC to make recommendations on when to move to a “quarantine” or “reject” policy and how much of your mail to send under that policy.

If you still find it complicated, you can leverage our Expert Managed Services to help you with your configuration.

What do MxToolbox Experts recommend?

Our team of Experts is always evaluating the newest email technologies – DMARC “reject” policies are a necessity to help improve your brand reputation by stopping phishing attacks using your brand. If more brands adopted DMARC “reject” policies, phishing attacks would be greatly reduced. It’s time for all companies to be DMARC compliant – Get Started Today!