LINK-V
LINK-V · Článek

E-mail z aplikací a zařízení Microsoft 365: co prověřit před změnou v prosinci 2026

October 18, 2026

Zjistěte, které aplikace a zařízení používají SMTP AUTH se základním ověřováním v Exchange Online, porovnejte podporované způsoby odesílání a ověřte firemní zprávy před změnou výchozího nastavení v prosinci 2026.


E-mail z aplikací a zařízení Microsoft 365: co prověřit před změnou v prosinci 2026

Než schválíte změny skeneru, fakturačního systému nebo aplikace pro tvorbu reportů, zjistěte, zda odesílá zprávy přes Exchange Online pomocí SMTP AUTH se základním ověřováním. Právě této konkrétní závislosti se týká prosincová změna Microsoftu v roce 2026. Samotné používání Microsoft 365 neříká, jak jednotlivé aplikace zprávy odesílají.

V praxi je potřeba určit dotčené odesílatele, potvrdit podporovaný způsob dalšího odesílání a před změnou živé konfigurace ověřit reprezentativní firemní zprávu. Vlastník systému nebo rozpočtu tak získá podklady pro rozhodnutí, které práce jsou nutné.

Co se změní na konci prosince

Podle aktualizovaného harmonogramu SMTP AUTH zůstane chování do prosince 2026 beze změny. Na konci prosince se SMTP AUTH se základním ověřováním ve stávajících tenantech ve výchozím nastavení vypne. Správci ho budou moci podle potřeby znovu zapnout. Tato změna výchozího nastavení je oddělená od konečného odebrání.

U nových tenantů vytvořených po prosinci 2026 bude tato metoda ve výchozím nastavení nedostupná a podporovanou metodou ověřování bude OAuth. Microsoft oznámí datum konečného odebrání ve druhé polovině roku 2027. Jde o období, kdy bude oznámeno datum, nikoli o datum samotného odebrání.

Tento harmonogram se týká základního ověřování SMTP AUTH v Exchange Online. Neznamená, že končí SMTP nebo že každá schránka a zařízení Microsoft 365 mají stejnou závislost. Upravený harmonogram dává čas na přípravu; stále je ale potřeba posoudit konkrétní změnu konfigurace.

Začněte u firemní zprávy

U každé důležité zprávy požádejte dodavatele nebo správce o potvrzení skutečné cesty odesílání. Fakturační aplikace může zprávu předávat přímo do Exchange Online, využívat místní relay server nebo odesílat přes službu svého dodavatele. Jde o hypotetické příklady a každý vyžaduje jiné podklady. Samotná adresa Microsoft 365 v poli odesílatele odpověď nepotvrdí.

Veďte stručný přehled s těmito údaji:

  • Firemní zpráva: co se odesílá, kdy je to potřeba a na jaké příloze či obsahu záleží.
  • Odesílatel a cesta: aplikace nebo zařízení, skutečná odesílací služba a metoda ověřování.
  • Příjemci: lidé uvnitř organizace, externí příjemci nebo obojí.
  • Vlastník systému: osoba odpovědná za odesílatele a vztah s jeho dodavatelem.
  • Možnost pokračování: podporovaný způsob odesílání a nevyřešené otázky kompatibility či konfigurace.
  • Odpovědná osoba za ověření: kdo potvrdí, že požadovaná zpráva dorazila příjemci.

Neznámé údaje zaznamenejte a určete, kdo je vyřeší. Tím odlišíte potvrzenou závislost na základním ověřování od odesílatele, který vyžaduje samostatné šetření. Dodavatel navíc dostane konkrétní otázku, na kterou má odpovědět před nákupem nebo změnou konfigurace.

Zvolte způsob podle příjemců a hostingu

Odesílání klientem přes OAuth je jednou z možných cest. Dokumentace Microsoftu k OAuth pro SMTP popisuje podporu ověřování včetně registrace aplikace a tokenů. Konkrétní aplikace nebo zařízení musí požadovanou podporu implementovat a konfigurace tenantu musí její použití umožňovat. Obecné tvrzení, že produkt „podporuje SMTP“, kompatibilitu nepotvrzuje. Ověřte ji u dodavatele pro přesný model nebo verzi softwaru.

Pokyny Microsoftu pro odesílání z aplikací a zařízení rozlišují cesty podle okruhu příjemců a provozních požadavků. Odesílání klientem a relay přes způsobilý konektor mohou doručovat interním i externím příjemcům. High Volume Email a Direct Send jsou v tomto přehledu určeny pouze pro interní poštu. Kvůli omezení příjemců se nehodí pro faktury nebo upomínky zákazníkům mimo organizaci.

Relay přes konektor má vlastní podmínky způsobilosti. Vyžaduje příchozí konektor, ověření certifikátem nebo vhodnou statickou veřejnou IP adresou a dostupný port 25. Microsoft tuto cestu vylučuje pro relay přes služby třetích stran hostované například v Azure. Před zvažováním relay přes konektor je proto u cloudové aplikace potřeba prověřit její hosting.

Direct Send s sebou také nese odpovědnost za správu e-mailového serveru. Jiná odesílací služba, včetně alternativy Azure Communication Services popsané Microsoftem pro interní i externí poštu, vyžaduje vlastní posouzení kompatibility a provozu. Které možnosti stojí za prověření, určuje seznam příjemců, prostředí hostingu a dostupná podpora. O výměně hardwaru rozhodujte až po prověření podporovaných možností.

Před změnou v ostrém provozu ověřte doručení

Domluvte se, kdo změnu provede, kdo ověří obchodní výsledek a kdo bude následně řešit případné problémy. Použijte reprezentativní zprávu se správnou identitou odesílatele, obsahem a přílohou. Sledujte ji od odeslání až po doručení zamýšlenému příjemci, včetně externího příjemce, pokud to firemní proces vyžaduje.

Úspěšné ověření potvrzuje pouze jednu část tohoto procesu. Potvrzení podpory od dodavatele a úspěšný test připojení správcem je stále třeba doplnit ověřením doručení příjemci. Změnu v ostrém provozu naplánujte, jakmile budou jasné závislost, kompatibilní způsob odesílání i odpovědnosti za ověření.

Potřebujete-li pomoci posoudit požadavky na odesílání z aplikace nebo zařízení, můžeme probrat rozsah v rámci naší služby e-mailové infrastruktury.

LINK-V LINK-V