SMTP AUTH 2026: změny pro tiskárny a aplikace

Tiskárna posílá skeny e-mailem, účetní aplikace faktury a web provozní oznámení. Vše funguje, dokud se nezmění autentizace nebo síť. Správce pak zjistí, že tři systémy používají různé cesty odesílání, přestože je firma všechny označuje jako SMTP.

Odlište SMTP protokol od Basic Authentication. Změna podpory heslového přihlášení neznamená plošný konec SMTP ani stejný dopad na všechny konektory a zařízení.

Aktuální termíny se liší od starších článků

Microsoft v aktualizovaném oznámení Exchange týmu uvádí beze změny chování SMTP AUTH Basic Authentication do prosince 2026. Na konci prosince má být u existujících tenantů vypnutá ve výchozím stavu s možností opětovného zapnutí. U nových tenantů po prosinci má být výchozí podporovanou cestou OAuth. Konečné datum odstranění má Microsoft oznámit ve druhé polovině 2027.

Proto nepoužívejte starší březnový nebo dubnový termín 2026 jako aktuální definitivní datum. Před ostrou změnou zkontrolujte i oznámení pro vlastní tenant.

Odklad nic nemění na potřebě inventury. Je to prostor na podporované řešení a jeho test, nikoli důvod dál rozšiřovat závislost na heslech.

Čtyři odlišné cesty odesílání

Microsoft porovnává podporované scénáře v návodu pro multifunkční zařízení a aplikace. Metodu vybírejte podle skutečného umístění aplikace a příjemců.

Proveďte inventuru podle odesílatele

U každého systému zaznamenejte vlastníka, SMTP endpoint nebo API, port, autentizaci, odesílací adresu a příjemce. Přidejte umístění zařízení, podporu výrobce a přístup k logům.

Zvlášť se ptejte, zda systém posílá pouze uvnitř organizace, nebo i zákazníkům. Test skenu na vlastní adresu neprokazuje funkční externí doručování faktur.

Také rozlišujte zařízení v kanceláři a aplikaci hostovanou u třetí strany. Stejná konfigurace connectoru nemusí být podporovaným řešením pro obě umístění.

Co požadovat od dodavatele tiskárny

Ptejte se na konkrétní model, firmware a podporovaný způsob OAuth. Obecné potvrzení „umíme Microsoft 365“ nestačí. Potřebujete postup registrace, obnovování přístupu a chování při chybě.

Vyžádejte si zkušební scénář se skutečným tenantem a podporovaný způsob správy. Zjistěte, zda po změně hesla, výměně správce nebo restartu zařízení odesílání pokračuje.

Pokud zařízení moderní autentizaci neumí, vyberte odpovídající podporovanou alternativu. Nenavrhovali bychom vypnutí ochrany celého tenantu jako běžný způsob zprovoznění jednoho skeneru.

Connector má vlastní síťové předpoklady

SMTP relay přes connector není obecný veřejný SMTP server pro každou aplikaci. Ověřte identifikaci odesílatele, veřejnou IP nebo certifikát a dostupnost požadovaného portu.

Zvlášť zkontrolujte pobočky a změny internetového připojení. Pokud řešení závisí na veřejné adrese, přechod na jiného poskytovatele může odesílání přerušit, aniž by se změnila tiskárna.

Zápis do firewallu nebo DNS má mít vlastníka a dokumentovaný důvod. Nespoléhejte na historickou konfiguraci, kterou nikdo neumí vysvětlit.

Direct Send a externí adresát

Direct Send není náhradou pro libovolné odesílání zákazníkům. Jestliže účetní systém potřebuje posílat do jiných domén, ověřte metodu odpovídající tomuto požadavku.

Na fórech bývají zaměněné pojmy „direct send“ a „SMTP relay“. Diagnostikujte podle endpointu, connectoru a skutečné autentizace, nikoli názvu v e-mailu od předchozího dodavatele.

Pro jednoduchou tiskárnu má být zvolená cesta dlouhodobě spravovatelná. Řešení vyžadující složitou infrastrukturu kvůli několika skenům týdně může být provozně nevhodné, i když je technicky možné.

Modelový příklad: tiskárna, ERP a web

Hypotetická firma má tiskárnu v kanceláři, ERP na firemním serveru a web u externího poskytovatele. Všechna tři zařízení mají odlišné podmínky a mohou potřebovat odlišnou cestu.

Tiskárna posílá jen zaměstnancům. ERP doručuje faktury i zákazníkům a potřebuje logy i opakování. Web odesílá potvrzení z hostovaného prostředí. Výběr jednoho SMTP hesla pro všechny systémy přehlíží jejich rozdíly.

Správce připraví samostatný test a vlastníka pro každou cestu. Finance potvrzují doručení faktury, provozní tým sken a správce webu doručení formulářového potvrzení. Úspěch jedné metody se nepřenáší automaticky na ostatní.

Testujte i nedoručení

Před nasazením odešlete zprávu interně i externě, ověřte reprezentativní přílohu a zkontrolujte výsledek v logu. Potom vyzkoušejte chybu: nedostupnou síť nebo neplatného příjemce v bezpečném testu.

Zjistěte, zda aplikace požadavek opakuje a zda nehrozí duplikace. U faktur je důležitá kontrola obchodního výsledku, ne pouze záznam „SMTP accepted“.

Do předání zahrňte, kde se hledá odmítnutá zpráva a kdo reaguje. Bez tohoto kroku můžete modernizovat autentizaci a ponechat stejný problém s neviditelnými chybami.

Plán migrace

1. Zmapujte všechny odesílající systémy.
2. Určete dnešní metodu a závislosti.
3. Ověřte podporované alternativy u dodavatelů.
4. Vyberte řešení pro každé umístění a typ provozu.
5. Otestujte doručení a chování při chybě.
6. Změnu nasaďte po jednotlivých systémech.
7. Odstraňte nepotřebné staré přístupy a aktualizujte evidenci.

Pro návrat připravte konkrétní schválený postup. Obnovení starého mechanismu není dlouhodobý výsledek migrace a nemá se provádět bez vědomí odpovědného správce.

Výsledek dobře provedené změny

Firma ví, odkud posílá poštu, jak se systémy ověřují a kdo řeší chyby. Nová autentizace tak přinese i lepší provozní přehled, který pomůže při příští změně zařízení nebo dodavatele.