What SMB1001:2026 Changed for MSP Email Authentication

If you manage email authentication for multiple client domains, you have probably assembled your own workflow from RFCs, vendor docs, and whatever the last outage taught you. That approach works until it does not, and then explaining your decisions to a client becomes its own problem.

SMB1001:2026 is an attempt to give MSPs a shared baseline. Published by M3AAWG, it lays out a structured approach to email authentication for small and medium businesses, with specific attention to what MSPs need when managing auth across a client portfolio. This article explains what the standard covers, what it changed, and what you need to do now that it exists.

What SMB1001:2026 Is

SMB1001:2026 is a best-practice standard from the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG). It targets MSPs and IT practitioners who configure or audit email authentication for SMB clients. The standard is not a mandate, but it is designed to be specific enough that you can implement it without wading through conflicting vendor guidance.

M3AAWG has published several email security documents over the years, but most assume you already have a working knowledge of the underlying protocols. SMB1001:2026 is written differently: it is aimed at a practitioner who needs to know what good looks like and what steps to take next.

What the Standard Changed for MSP Email Authentication

Before SMB1001:2026, MSP email authentication guidance was fragmented. Vendor-specific best practices, partially documented RFC sections, and institutional knowledge held together with assumptions. If you were onboarding a new client, there was no single document you could hand to an engineer and say "do this."

SMB1001:2026 consolidates that guidance into one structured reference. It covers:

- SPF configuration expectations for multi-tenant and multi-client environments - DKIM signing requirements and key rotation practices - DMARC policy selection and aggregate reporting workflows - Reporting obligations and what MSPs should be capturing for client visibility

The practical effect is that MSPs now have a defensible reference point when configuring or auditing a client's email authentication posture. If a client asks why you set p=quarantine instead of p=reject, you can point to a section of SMB1001:2026 rather than a collection of forum posts.

What the Standard Covers

Here is a breakdown of what SMB1001:2026 addresses, based on the standard's documented scope.

SPF

The standard clarifies how SPF should be configured in environments where multiple services send mail on behalf of the same domain. For MSPs this matters because client domains often have third-party SaaS tools, marketing platforms, and internal mail systems all sending via different IPs. Getting the SPF record wrong is one of the most common causes of authentication failures that show up in aggregate reports.

SMB1001:2026 recommends keeping the SPF lookup count within the 10-DNS-lookup limit defined in RFC 7208. It also provides guidance on using include mechanisms vs redirect modifiers to manage complexity as the number of sending sources grows. This is a direct response to a common failure mode: SPF records that grow unchecked until they exceed the lookup limit and silently fail.

DKIM

DKIM configuration gets more specific treatment than many MSP-focused guides give. The standard covers selector management, key rotation intervals, and what alignment mode to use when DKIM is paired with DMARC.

For MSPs, the practical issue is that clients often have multiple third parties adding their own DKIM signatures to outbound mail. Some of those third parties may have poor DKIM implementation, and others may not be aligned with the client's domain at all. The standard gives you a framework for auditing which signatures are present and whether they are correctly aligned with the client's domain.

DMARC

This is where most of the actionable content lives for MSP practitioners. SMB1001:2026 walks through p=none, p=quarantine, and p=reject, and explains the risk profile of each. It also covers the aggregate reporting workflow: what to look for in reports, how to identify authentication failures, and how to escalate findings into client-facing recommendations.

The standard makes a point that practitioners sometimes skip: moving to p=reject should only happen after you have verified that all legitimate mail sources are properly authenticated. Jumping to p=reject before that verification is how you end up with an outage that you then have to explain to a client at 2am.

Aggregate reporting obligations

SMB1001:2026 makes aggregate report consumption a first-class MSP responsibility rather than an afterthought. The standard recommends that MSPs maintain visibility into auth failures within 24 to 48 hours of them occurring, rather than discovering problems during a client complaint.

This is the part of the standard that most directly affects tooling decisions. MSPs who adopt SMB1001:2026 need a way to aggregate, parse, and act on DMARC aggregate reports across their entire client portfolio. Receiving and reviewing XML reports manually does not scale, and forwarding reports to clients in raw form does not give them the actionability they need.

DMARCFlow is designed for exactly this workflow: it consolidates aggregate reports across multiple client domains and surfaces which domains have authentication failures, misconfigured records, or unexpected senders. For an MSP working toward SMB1001:2026 compliance, that portfolio-level visibility is a prerequisite, not a nice-to-have.

First Steps for Adopting SMB1001:2026

If you want to bring your MSP practice in line with SMB1001:2026, here is a practical starting sequence:

1. Audit current SPF, DKIM, and DMARC records for each client domain

Before changing anything, document what exists. Many SMB domains have accumulated SPF records over years of adding SaaS tools without ever pruning them. The resulting record may already be close to or over the 10-lookup limit, which means SPF is silently failing for some senders.

2. Verify SPF and DKIM alignment for all legitimate sending sources

Identify every service that sends mail on behalf of the client domain and confirm that each one either passes SPF alignment, DKIM alignment, or both. Any service that does not align is a risk when you move to a stricter DMARC policy. Aggregate reports are the only reliable way to find senders you do not know about.

3. Establish a DMARC aggregate reporting workflow

If you are not already receiving and reviewing aggregate reports for every client domain, SMB1001:2026 effectively requires that you start. The standard expects MSPs to maintain visibility into auth failures across their portfolio, not just when a client reports a problem. This is the part of the workflow where tooling matters most, because doing it manually across 20 client domains means you will not do it consistently.

4. Move DMARC policy from p=none to p=quarantine for domains that pass initial audit

p=none has near-zero protective value: it tells the world what your policy is but does nothing when someone spoof your domain. SMB1001:2026 acknowledges this directly. Once you have confirmed that your legitimate sending sources all pass authentication, moving to p=quarantine gives you real protection without the risk of p=reject causing an outage from a missed sender.

5. Plan p=reject as the target state

p=reject is the only DMARC policy that fully prevents domain spoofing. SMB1001:2026 treats it as the destination, not the starting point. Getting there requires a deliberate migration path with verification at each stage. Aggregate reports should be checked before and after each policy step to catch any senders that were missed in the audit.

FAQ

Does SMB1001:2026 require specific software or tooling?

No. The standard describes outcomes and practices, not specific products. How you achieve those outcomes is up to you. For aggregate report analysis, you can use open-source tools, commercial platforms, or manual XML parsing if you prefer. The standard's requirement is visibility, not a specific tool.

Is SMB1001:2026 compliance mandatory?

No. It is a best-practice document, not a regulation or certification requirement. But if you are an MSP and a client asks what framework you use for email authentication, pointing to SMB1001:2026 is a more credible answer than "we have a checklist we put together."

How does SMB1001:2026 relate to other email standards?

It builds on the existing email authentication RFCs: RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for DMARC. SMB1001:2026 does not replace those documents but adds operational context for how MSPs should apply them in multi-client environments.

Does the standard cover BIMI?

BIMI is mentioned in the context of brand indicators for email, but SMB1001:2026 does not make BIMI adoption a requirement. It is covered as an optional enhancement for domains that have already achieved strong baseline authentication.

What if a client refuses to move beyond p=none?

SMB1001:2026 acknowledges this as a common MSP challenge. The standard recommends documenting the client decision and maintaining aggregate reporting visibility so you can demonstrate what would change if they allowed stricter policy. The reporting workflow remains valuable even at p=none because it surfaces unknown senders and auth failures that p=none itself cannot block.

---

SMB1001:2026 will not solve email authentication for MSPs by itself. But it gives the industry a reference point that did not exist before, and for the first time, MSPs have a document they can point to when explaining to a client why authentication setup costs what it costs. The standard is a starting point, not a destination.