Skilj standarddomänen från sändningsvägen
En onmicrosoft.com -adress kan tjäna flera roller i en Microsoft 365 -miljö. Det kan vara en standardhyresgästadress, en postlådeadress, en routingidentitet eller en applikationsavsändare. Att hitta strängen var som helst i ett meddelande eller konto avgör inte i sig vilken utgående begränsning som gäller. Börja med den faktiska meddelandevägen och avsändarens identitet och jämför dem sedan med Microsofts dokumenterade omfattning.
Den här artikeln granskar vägledning från första part den 8 november 2026. Den inspekterar inte en hyresgäst, tar inte bort en initial domän, ändrar adresser eller skickar testmeddelanden. En anpassad domän är en möjlig designkomponent som stöds, inte ett löfte om att ändra ett visningsfält kommer att lösa ett kvotproblem eller befria organisationen från andra sändningskontroller.
Läs den dokumenterade begränsningen i mottagarenheter
De Exchange Online gränser sida, uppdaterad 19 oktober 2026, anger att utgående e-post från organisationens standard onmicrosoft.com -domäner är begränsad till 100 externa mottagare per organisation i ett rullande 24-timmarsfönster. Den säger att inkommande meddelanden är opåverkade och identifierar 550 5.7.236 diagnostiken när begränsningen nås. Detta är en publicerad begränsning på organisationsnivå, inte 100 meddelanden för varje brevlåda eller en midnattsåterställningsrätt.
De Exchange Team meddelande, daterad 20 augusti 2025, beskriver standard MOERA-domänens testroll och uppmuntrar anpassad domänanvändning för regelbunden sändning. Den framgångsrikt hämtade texten ger det sammanhanget; senare försök att inspektera ytterligare passager tog timeout. Inget slutdatum för lanseringen eller oobserverad hyresgästtillstånd kan härledas från den ofullständiga läsningen.
Håll denna begränsning åtskild från brevlådans mottagarfrekvens, meddelandeinlämningshastighet, anti-missbrukskontroller och Hyresgästens externa mottagarfrekvensgräns. En organisation kan stöta på en annan begränsning efter att ha korrigerat en källa till strypning. Numerisk likhet mellan två kvoter är inte bevis för att de delar samma räkneregel eller tillämpningsområde.
Lageridentiteter utan att gissa räknefältet
För varje påverkad applikation, registrera den konfigurerade avsändaren, SMTP MAIL FRÅN identitet, synlig från adress, autentiserat konto, inlämnande slutpunkt, anslutare och faktiska mottagardomäner. Behåll fullständiga rubriker och spåra bevis endast under lämpliga åtkomstkontroller. Skilj information som tillhandahålls av ansökan från information som skrivits om eller lagts till av en mellanhand.
De hämtade leverantörspassagena beskriver e-post som skickas från onmicrosoft-domäner, men fastställer inte varje kantfall som involverar divergerande kuvert-, rubrik- och routingidentiteter. Om ett meddelande visar en anpassad synlig Från-adress och en onmicrosoft-identitet någon annanstans, förklara det inte undantaget eller påverkat enbart från det fragmentet. Be den ansvariga administratören att korrelera den faktiska diagnostiken och spåra med den tillämpliga leverantörens tolkning. Det okända hör hemma i bedömningen, inte i en gissningsregel.
DMARC uppriktning är en separat protokollfråga. A DKIM undertecknare, SPF identitet och synlig Från-domän kan skilja sig, och kvotklassificeringen fastställs inte av en DMARC passera. Omvänt kräver antagande av en anpassad avsändardomän lämplig autentisering och auktorisering; ett varumärkesbyte kan inte ersätta dessa kontroller.
Klassificera rutten innan du föreslår en åtgärd
Microsofts enhets- och applikationsvägledning, uppdaterad 16 september 2026, skiljer postlådeinlämning, anslutningsrelä och direktsändning. En skanner som använder Direct Send kan inte använda den sökvägen för externa mottagare bara genom att ändra avsändaradressen. En ansökan om postlådeinlämning behöver fortfarande rätt autentisering och sändningsbehörigheter som stöds. En anslutningsväg har sina egna behörighets- och förtroendekrav.
En fiktiv inventering kan innehålla en testbrevlåda med tenant-example.onmicrosoft.com , ett kvittoprogram konfigurerat med en verifierad anpassad domän och en intern skanner. Bedömningen skulle granska var och en för sig. Den skulle inte anta att kvittoapplikationen är säker bara för att dess gränssnitt visar en anpassad adress, eller ta bort skannerns routingidentitet eftersom den liknar standardhyresgästdomänen. Ingen sådan hyresgäst eller trafik inspekterades här.
Förbered en förändringsplan först efter att ha bekräftat den relevanta begränsningen. Inkludera beroenden av kontoinloggningsnamn, alias, programkonfiguration, anslutaridentitet och administrativ policy. Dessa kan kräva olika ägare och godkännandevägar. Undvik ett urskillningslöst byte av namn eller radering av onmicrosoft-adresser, vilket kan tjäna orelaterade operativa syften.
Använd diagnostiken för att separera begränsningar
En dokumenterad 550 5.7.236 pekar på onmicrosofts externa mottagare-begränsning, medan 5.7.233 är associerad med TERRL. Bevara leverantörens fullständiga ordalydelse och sammanhang snarare än att behandla någondera koden som ett generiskt autentiseringsfel. RFC 5321 klassificerar ett 5xx-svar som permanent för det SMTP försöket. Applikationen behöver ett medvetet återställningsbeslut, inte en oändlig omedelbar återförsöksslinga.
De aktuell TERRL-uppdatering särskiljer också molnmiljöer, hyresgästpopulationer och undantag. Dessa detaljer definierar inte automatiskt onmicrosoft-begränsningens omfattning. Om en kvot faller inom ett rullande fönster, bestäm när faktisk tidigare trafik åldras istället för att lova en återställning vid en fast klocktid.
Verifiera resultatet på ett kontrollerat prov
Efter en separat godkänd rättelse, använd ett litet representativt test som täcker den avsedda avsändar- och mottagarklassen. Behåll inlämningsresultatet, spårningen, bevis på mottagarsidan och relevant kvotobservation. Bekräfta att köad e-post inte har duplicerats och att programmets verkliga affärsflöde förblir funktionellt. Framgångsrik transport lovar inte placering i inkorgen, och ett enda framgångsrikt meddelande skapar inte hållbar kapacitet.
Dokumentera vem som äger framtida granskning när applikationen, domänkonfigurationen eller Microsofts vägledning ändras. Det exakta driftsättningskravet är fortfarande öppet: Använd aktuell Microsoft-dokumentation och kontrollerade ruttspecifika leveransbevis. Aktuella dokumentära källor och en föreslagen ruttkarta ingår, men inga originalbevis för kontrollerad leverans finns. Teknisk tolkning av identitetskantfall, hyresgästtillämplighet, driftacceptans och ägarens publiceringsgodkännande kvarstår.