Unauthenticated sending domains: the October 2026 numbers

The October refresh gives us a current reading on unauthenticated sending domains, but the supplied aggregate does not include the earlier result. We cannot say whether the problem grew or shrank. What we can say: in the US B2B SaaS 5-50 population, N = 1128, 13.3% (n=150) were classified as active unprotected sending domains.

That matters because a familiar sender address carries authority. A client may recognize the address on an invoice, document request or account notice and assume the message came from the business. Email authentication helps receiving systems evaluate that claim. Gaps leave those systems with less protection against someone impersonating your domain.

What the October result measures

The aggregate was generated on 2026-10-22 from the October 2026 monthly refresh of the same population. Its email.active_unprotected category identifies domains observed sending real mail without SPF alignment or an enforced DMARC policy. This is a configuration finding, not a count of attacks, fraudulent messages or affected customers.

Our methodology is passive, public-data-only and k-anonymised. The sample is the US B2B SaaS 5-50 population, N = 1128. Findings are presented only in aggregate, with no company named. Public HTTP and DNS observations do not prove abuse, reveal every legitimate sending service or establish what happens inside a business.

The population also limits the conclusion. These findings describe the measured SaaS sample. They do not establish the prevalence of the same issue among law firms, medical practices, manufacturers or other established businesses. The practical configuration questions, however, apply wherever clients rely on email bearing a business domain.

A recognizable From address is not authentication

The visible From address is the identity a recipient usually sees. SPF checks whether the sending infrastructure is authorized for the domain used in its check. For SPF to contribute to a DMARC pass, that authenticated domain must align with the visible From domain.

DKIM provides another route. A message passes DMARC when it has an aligned SPF pass or an aligned DKIM pass. Both are not required. Missing SPF alignment therefore does not, by itself, establish that legitimate messages fail DMARC or that every message using the domain is unauthenticated.

DMARC also lets the domain owner publish a policy for messages that fail its checks. A policy of p=none requests no DMARC-based enforcement. Quarantine and reject express the domain owner's requested treatment of failing messages; receiving systems apply their own handling rules.

That distinction prevents an exaggerated conclusion. An unprotected domain does not guarantee that an impersonated message will arrive, avoid a warning or reach an inbox. Receivers may block it under other policies. The finding is that the domain owner has left an authentication or enforcement gap, not that delivery is assured.

How this could affect a client relationship

Consider a hypothetical business that emails clients about invoices. An impersonator constructs a message displaying its familiar From address and asks a client to replace payment details. The attempt does not necessarily require access to the business's mailbox.

A properly configured authentication policy gives the recipient's mail system a stronger basis for handling that message. It cannot make every payment request trustworthy. Staff still need an independent way to confirm changed banking instructions, using contact details already on file.

What to actually do about it

• Identify legitimate senders. Include ordinary mailboxes and services that send invoices, support replies, campaigns or application notices. Ask whoever manages each service how it authenticates mail using your domain.
• Check alignment. Confirm that legitimate messages pass DMARC through aligned SPF or aligned DKIM. A service saying that SPF or DKIM is enabled does not establish alignment with your visible From address.
• Configure reporting deliberately. DMARC reports require a configured reporting destination. Publishing p=none alone does not request reports. Assign someone to review the available evidence and investigate unfamiliar senders.
• Review enforcement after validating senders. Resolve legitimate authentication failures before changing policy. Quarantine or reject should follow a considered review of sending services and alignment, with monitoring for disrupted legitimate mail.

The free public checker offers a starting point for reviewing visible configuration. The separate External Security Posture Assessment provides a broader passive, external-only review. Neither public DNS records nor a checker result replaces validation of your legitimate mail.

Start with the service that sends your most sensitive client messages. Confirm which domain it authenticates, whether that identity aligns with the From address, and who owns fixing any gap.