Email Deliverability News, October 2026: Sending Limits, Warmup, and EWS

Before a SaaS launch, the marketing team may have approved the audience and copy while leaving three harder questions unanswered: how much the new Microsoft 365 tenant can actually send, whether an agency has manufactured engagement for a sending domain, and whether the CRM still depends on an email interface entering retirement. September 2026 made those dependencies more consequential. Review the sending account, domain practices, and application route before approving a volume increase; an account-wide “delivered” total cannot answer all three questions.

What changed through September 30#

This October 2026 edition covers September developments through September 30, with follow-up status checked on October 1. The changes affect different parts of a B2B SaaS operation: outbound prospecting, customer notifications, shared sending platforms, and Microsoft integrations. Some are September launches; Microsoft’s new-tenant quota changes were announced earlier and scheduled to begin rolling out during September. The distinction matters when deciding whether a team needs an immediate configuration change, a capacity plan, or continued monitoring.

Synthetic warmup now carries a documented listing cost#

Validity’s September 3 announcement introduced Heatwave, a domain blocklist targeting artificial reputation warming. Validity said it had listed more than one million domains exhibiting that behavior at launch. Its signal is available through existing Validity reputation feeds, with partners including Comcast, Proofpoint, Spamhaus, and SURBL described as using or evaluating it. That wording does not establish universal deployment or a new Gmail rule. The decision for a SaaS sales team is narrower: stop treating manufactured engagement as an invisible preparation service.

The vendor chain deserves inspection. Validity says synthetic activity can occur through subcontractors without the brand knowing, and its lookup can surface related domains. Ask the outbound agency which domains and mailboxes it controls, whether it creates automated replies or opens, and which subcontractor runs those exchanges. Gradually increasing legitimate mail to people who expect it is a different practice from arranging fake conversations among controlled accounts. If the agency cannot describe its method, hold the proposed expansion until you can identify what is being sent under your brand.

The late-month follow-up strengthens that call. On September 30, Resend advised senders to avoid warmup services. More consequentially, Validity’s listing policy, checked October 1, says an accurate synthetic-warming observation does not expire simply because the activity stops. An erroneous listing can be reviewed and removed; active-outreach status can change independently. Do not buy a service on the assumption that a later pause will erase its history. Stopping the activity may reduce continuing exposure, but a dispute needs evidence that the original classification or attribution was wrong.

A new Microsoft tenant needs a smaller launch budget#

Microsoft’s TERRL update, announced August 13, scheduled revised quotas to start rolling out September 14. Trial tenants are limited to 500 external recipients per day. New non-trial tenants receive 10% of their standard calculated quota below 31 days of age, 25% at 31–60 days, and the full calculated quota after 60 days. The notice postpones TERRL for GCC, GCCH, DoD, and 21Vianet. A team building a new commercial tenant for a launch should not budget against the mature tenant’s allowance.

For a standard paid tenant with 100 non-trial, non-education email licenses, Microsoft’s example gives a full allowance of 22,059 external recipients. Applying the first-month percentage yields about 2,206. That is a planning calculation, not a guarantee of the tenant’s live threshold. TERRL uses a sliding 24-hour window across the tenant, and repeated sends to the same outside address count repeatedly. A campaign and its follow-ups can therefore consume more allowance than the number of people in the segment suggests.

Before approving a sequence, have the Microsoft 365 administrator read the Tenant Outbound External Recipients Rate report in Exchange admin center. The official guidance identifies the current quota, consumption, and enforcement state there. Compare that allowance with ordinary employee mail and CRM traffic as well as the campaign. Leave capacity for customer conversations; if the planned marketing traffic cannot fit, use an appropriate sending service or reduce the schedule. A calendar-day reset is the wrong assumption for a sliding window, and a rollout start date does not prove the revised calculation is active in every tenant.

EWS access needs an owner as October changes begin#

An application can fail before there is an SMTP message to diagnose. Microsoft’s September 4 EWS notice says updated Exchange Online behavior begins rolling out October 1: keeping EWSEnabled set to True requires an EWSAllowedAppIDs list. Microsoft will preserve an administrator’s list. Where it supplies a list, it uses the previous 60 days of activity, which can miss an infrequent application or retain an unwanted one. The rollout is per tenant, so October 1 is not a universal midnight shutdown.

For a SaaS team, the immediate task is to identify which CRM connectors, customer-mailbox features, or scheduled jobs still call EWS. A quarter-end process can be absent from a 60-day usage window and still matter to revenue operations. Give the messaging administrator the necessary application IDs and their owners, then test the infrequent job as well as the daily one. Where EWS must continue temporarily, Microsoft’s guidance is to configure only the required applications and enable EWS explicitly while planning migration to Microsoft Graph. An allow list buys continuity; it does not complete that migration.

The September 30 hybrid clarification adds a reason to avoid a blanket removal of EWS permissions. Graph-based hybrid rich coexistence requires Exchange Server Subscription Edition with at least its May 2026 update. On-premises mailboxes with Exchange Online archives still lack full Graph support for that scenario: retain EWS, enable it in the cloud tenant, and allow the dedicated hybrid application for now. Separately, an on-premises organization sharing coexistence information with another Exchange Online organization needs the receiving cloud tenant to keep EWS enabled. Have the messaging administrator classify the deployment before approving a cleanup; a documented dependency warrants a specific exception with an owner.

Brevo’s incident makes sending access part of deliverability#

Brevo’s incident write-up says it detected a SAML SSO flaw on September 10. Access configured for one organization incorrectly extended to other organizations the invited user could reach. Brevo reports 138 affected accounts: six were used for phishing sends and contacts were exported from 43. It closed the entry route and signed out users at 08:30 UTC that day. Brevo also says the malicious messages passed the usual email authentication checks because they came through legitimate infrastructure. An authenticated sending domain therefore cannot answer whether the account operator was authorized.

The customer consequence continued after containment. In its September 17 update, Trezor confirmed that 347,149 marketing contacts had been exported through the API. Trezor had suspended its Brevo account; it said its wallet and product systems were unaffected. For a SaaS growth team, this is a reason to rehearse revocation as part of the sending plan. Identify who can send campaigns, invite users, and export audiences, then verify that the incident owner can disable sending and revoke access promptly. Reducing privileges or removing a dormant integration has an operational cost, but leaving that ownership unknown can expose both the audience and the trusted mail stream.

SES can now show which tenant needs attention#

Amazon SES’s September 17 Virtual Deliverability Manager release adds tenant sends, deliveries, bounces, complaints, opens, and clicks, with breakdowns by mailbox provider, identity, and configuration set. A TENANT_NAME dimension also makes the separation available through BatchGetMetricData. A SaaS platform sending on behalf of many customers can use that view to investigate the customer generating complaints before applying an account-wide restriction. The prerequisite is tenant management with VDM enabled; the announcement does not make every existing SES account a correctly attributed multi-tenant sender.

AWS’s September 28 Mail Manager guide explains the mapping: an SES API send needs TenantName, while SMTP sending can use X-SES-TENANT. Relaying through Mail Manager to a third-party SMTP server does not activate SES tenant attribution. Trace a real application message and check that its tenant identifier reaches the SES send. If the identifier is missing, fix attribution before drawing conclusions from a quiet tenant dashboard.

Keep acceptance and placement separate when reporting the result. The new tenant measures do not establish which folder received an accepted message. Use bounces and complaints to locate a stream that deserves attention, and require separate evidence when the decision depends on inbox placement. The guide’s distinction between Mail Manager logs, SES events, and Lambda logs also matters when a route spans those components: correlate the message through the path instead of interpreting a successful first handoff as completed delivery.

Aggregate reporting offers another view, with draft-stage limits#

The September 8 Aggregate Performance Reporting revision proposes DNS-discovered JSON reports associated with a DKIM signing domain and selector. A receiver can disclose classification, such as inbox or unwanted mail, and positive, neutral, or negative engagement. Those parts are optional, and the generator chooses what to share and how to bucket the values. This is an Internet-Draft, explicitly a work in progress. Publication does not establish a new Gmail requirement or prove that every mailbox provider generates these reports.

The useful SaaS experiment is to ask the sending provider which receivers actually supply feedback and request a sample covering your signing domain. Check the report period, included categories, and aggregation before calculating a placement percentage. If the platform serves multiple customers, find out whether the reports preserve useful separation and avoid putting sensitive customer names into shared segment identifiers. Receiver classification could help explain a high accepted count alongside weak engagement, but an absent category remains unknown. Keep existing provider-specific monitoring until the received reports demonstrate coverage useful enough to support a decision.

Mailgun alerts need a capacity decision behind them#

Mailgun’s September 8 release lets primary account administrators receive usage alerts for subaccounts at default thresholds of 50%, 75%, and 100%; the first two can be edited. Notifications can use email, Slack, or a webhook. The monitored allowances include Messages Sent, Email Previews, Email Validations, and Inbox Placement Tests. Configure the resource that can constrain the campaign rather than assuming every alert concerns sending volume.

A subaccount must already have a usage limit for the alert to trigger. Give an earlier threshold to someone who can compare remaining allowance with the launch forecast and alter capacity or timing. Notification at 100% is not an automatic rescue. The practical difference from Microsoft’s tenant quota is ownership: Mailgun exposes alerts around a configured subaccount limit, while the Microsoft team needs the live service report and tenant-wide demand forecast. Neither consumption measure explains whether recipients wanted the messages, so keep complaint monitoring alongside the capacity review.

Check the relay’s support status before changing the campaign#

Microsoft’s September 2 notice scheduled a higher Exchange 2016/2019 version floor from the second week of September. It applies to servers submitting to Exchange Online through an inbound connector of type OnPremises, with the October 2025 public update as the announced minimum. The notice does not give an exact worldwide activation timestamp. Ask for the submitting server’s build, connector type, and mail-flow evidence before diagnosing a decline on that path as a campaign problem.

The same notice says the next increase, estimated in several months, will exceed publicly available Exchange 2016/2019 updates; affected organizations will need Extended Security Updates or Exchange Server Subscription Edition. Assign a migration owner now if a CRM or internal application still uses that relay. Rewriting its messages cannot repair an unsupported transport route. Keep this server-version enforcement distinct from TERRL’s outbound-recipient budget and EWS’s application-access controls: fixing one leaves the other two dependencies to be checked.

Self-hosted sending software adds a different maintenance boundary. GreenArrow’s September 9 release discontinued Debian 11 support, following the operating system’s August 31 end of life; Debian 12 remains supported. A SaaS notification stream using GreenArrow needs its host’s operating system recorded alongside the MTA version. Have the operator plan and test that transition before adopting a new release on an unsupported host. The September 22 release also describes remote-limiter scheduling improvements. Review compatibility and measure throughput under your workload before changing the campaign forecast; the changelog does not establish improved inbox placement.

September incidents belong in the campaign postmortem#

Policy changes were not the only reason Microsoft-bound mail needed investigation. On September 1, Microsoft reported that mail flow was working as expected and queues were draining, while search restoration continued under EX1464935 and MO1465074. On September 4, it acknowledged separate delays sending to and receiving from external domains under EX1467029. Voyado’s September 7 update marked its related incident resolved and explained that affected Engage messages could remain “Unknown” until Microsoft processed the queue. These updates justify checking the incident window; they do not establish a permanent deterioration in a sender’s reputation.

An application outage creates another place to investigate. Salesforce’s September 16 incident record describes severe delays, intermittent errors, and access problems in affected Hyperforce environments, including reports of scheduled jobs not running. It records service recovery at 15:26 UTC; a September 17 correction says sandboxes were not affected. For an email workflow initiated by an affected application, check that the job ran and submitted a message before diagnosing the receiving mailbox. The record does not establish that every Marketing Cloud product or every email send failed.

Preserve attempt times, destination domains, response codes, and the platform’s eventual message outcome when reviewing a September campaign. Match the service incident before interpreting a temporary backlog as evidence that the list or domain needs replacement. Recovery at the provider does not reconcile your campaign automatically: account for delayed notifications, check whether retries produced duplicates, and confirm the final queue state. If the anomaly continues outside the documented window, reopen the route and reputation investigation with that later evidence rather than assuming the earlier incident explains everything.

Gmail’s carryover topics need narrower decisions#

The prior issue’s political-sender watch item now has a confirmed start: Campaign Verify says its program began September 8. Google’s eligibility policy, checked October 1, limits participation to eligible U.S. political committees and retains sender requirements and recipient controls. An ordinary SaaS business should not treat that program as an available verification shortcut or an exemption from filtering. A platform serving eligible campaigns can assign enrollment to that customer; the rest of its commercial traffic still needs its own sending discipline.

The Postmaster Tools transition also needs an updated status. Google’s current help page, checked October 1, says the legacy web-interface retirement is postponed, with timing to follow. It separately says API v2 is available and requires a distinct client data schema; Domain and IP Reputation are excluded from v2. Keep a migration owner and identify any reporting dependency on those fields. Build replacement reporting around the fields actually available, and keep the retirement date open until Google confirms one.

For third-party Gmail “Send as”, the October 1 check still shows removal starting January 2027 for non-Google identities; Gmail and Workspace aliases are unaffected. New configurations may be restricted during the transition. Audit a salesperson’s or support operator’s actual external-account setup and test the replacement before January. A Google-hosted company alias does not require the same migration, and the change says nothing about whether a separately sent SaaS campaign reaches Gmail recipients.

Approve October volume only after tracing the route#

The first review should connect each business stream to its domain, account or tenant, submitting application, and next relay. For outbound sales, resolve synthetic-warmup exposure. For a new Microsoft tenant, reserve room inside its live external-recipient allowance. For an EWS integration, test the authorized application and its migration path. For customer mail on SES or Mailgun, establish attribution and capacity ownership before interpreting the account total.

Choose the intervention at the point that failed. A tenant quota calls for a send-budget decision; a missing application authorization calls for the integration owner; a vulnerable relay calls for the messaging administrator. An unexplained complaint increase calls for examining the affected sender stream and audience. That ordering protects ordinary customer conversations from broad changes made before the team knows which dependency is responsible.

Frequently asked questions#