„Odesláno“ znamená, že zprávu převzal váš poštovní systém. Neznamená to, že skončila v hlavní složce příjemce. Rozdíl mezi odmítnutím, doručením do spamu a nezájmem adresáta je zásadní: každá situace má jinou příčinu a jiný další krok.
Pokud poštu právě zavádíte, nejdříve nastavte doménu podle našeho úvodního průvodce. Tento článek nabízí diagnostiku pro běžné firemní zprávy, webové notifikace i newslettery. Bez přístupu k hlavičce konkrétní zprávy nelze poctivě označit jediného viníka.
První krok: určete, co se vlastně stalo
| Příznak | Co zjistit | První krok |
|---|---|---|
| Vrácená zpráva s chybou | Kód a text odmítnutí | Řešit uvedenou chybu adresy, limitu či autentizace |
| Zpráva ve spamu | Hlavičky a výsledek SPF/DKIM/DMARC | Ověřit doménu, reputaci a typ obsahu |
| Nedorazila, ale není chyba | Log odeslání a karanténa příjemce | Požádat správce cílové domény o trasování |
| Padá jen pošta z webu | Který server ji skutečně poslal | Opravit SMTP a autentizaci webového systému |
Nejdříve si uložte jednu konkrétní testovací zprávu se všemi hlavičkami a časem odeslání. Hláška „nedochází e-maily“ bez adresy, času a výsledku nedovolí odlišit problém domény od chyby jedné schránky.
Autentizace: prochází zpráva pod správnou doménou?
Kontrolujte SPF, DKIM a DMARC v hlavičce přijaté zprávy. SPF říká, které servery smějí posílat za technickou obálkovou doménu. DKIM ověřuje podpis. DMARC posuzuje vztah k doméně v poli „Od“ a politiku pro neúspěšné zprávy. Nestačí, že záznamy v DNS existují; musí projít zpráva z každého skutečného odesílacího systému. Konkrétní pořadí nastavení a nejčastější chyby uvádíme v článku SPF, DKIM a DMARC pro firemní e-mail.
Google vyžaduje pro běžné odesílatele do osobního Gmailu SPF nebo DKIM, správné dopředné a zpětné DNS odesílající IP a TLS. U velkých hromadných odesílatelů nad 5 000 zpráv denně platí přísnější režim včetně SPF i DKIM a DMARC. Nezaměňujte tyto dva prahy. Dobrý výsledek autentizace ovšem stále nezaručuje umístění v hlavní složce.
Pověst domény, obsah a očekávání adresáta
Filtry zohledňují také stížnosti, kvalitu seznamu kontaktů, frekvenci rozesílky a historii odesílání. Nová doména nemá stejnou historii jako zavedený firemní účet. Skokové rozeslání velkého objemu, nakoupené adresy nebo zasílání lidem, kteří zprávy nečekají, může zhoršit pověst bez ohledu na technicky správné DNS.
- Transakční pošta: faktury, potvrzení objednávek a obnovy hesel posílejte odděleně od marketingových kampaní a ověřte, že jejich šablony odpovídají skutečné události.
- Newsletter: používejte kontakty se správným souhlasem či jiným právním základem, jasného odesílatele a funkční odhlášení; velcí odesílatelé do Gmailu musí plnit i požadavek na snadné odhlášení.
- Přílohy a odkazy: zkontrolujte, zda nevedou na nečekanou doménu, zda dokument není zbytečně objemný a zda text zprávy dává smysl i bez přílohy.
- Odpovědi: používejte aktivní adresu, na kterou může člověk reagovat; ignorované nebo neplatné schránky důvěru snižují.
Proč se liší pošta od člověka a z WordPressu
Osobní schránka může odesílat přes server e-mailového poskytovatele, zatímco kontaktní formulář běží na webhostingu a používá jiný server. Pokud formulář nastaví viditelnou adresu zákazníka jako „Od“, může tím předstírat odesílání z cizí domény. Vhodnější bývá odesílat z vlastní autentizované domény a adresu zákazníka uvést jako „Odpovědět komu“. Přesné nastavení závisí na pluginu a poštovní službě.
Po změně hostingu či e-mailu přetestujte všechny formuláře, fakturační pluginy a zprávy systému. Návod na bezpečný přechod popisuje migrace firemního e-mailu. Právě zapomenutý automatický odesílatel bývá důvodem, proč běžná pošta funguje a systémové zprávy padají do spamu.
Praktická diagnostika za 20 minut
- Pošlete jedinečnou testovací zprávu z běžné schránky a stejnou cestou, která selhává, například z formuláře.
- Uložte čas, adresu odesílatele a příjemce, případnou chybovou zprávu a úplné hlavičky přijatého e-mailu.
- Porovnejte SPF/DKIM/DMARC, odesílající IP a doménu „Od“ u obou zpráv.
- Zkontrolujte, zda se problém objevuje u všech příjemců, nebo pouze u jedné firmy či služby.
- Opravte konkrétní zdroj a test zopakujte. U odmítnutí cílovým serverem předejte podpoře jeho chybový kód.
Nevyvozujte příčinu jen ze slov „spam“. Pokud autentizace prochází a potíže má jediný příjemce, může rozhodovat jeho lokální filtr. Pokud selhává většina cílů, zkoumejte vlastní nastavení a pověst. Násilné přesouvání zpráv z jedné testovací schránky do inboxu není náhrada za opravu příčiny.
Čtyři situace, které vyžadují odlišnou opravu
1. Přišla chybová zpráva o nedoručení
Otevřete celý text vrácené zprávy. Obsahuje adresu příjemce, čas, server a stavový kód. Trvalé chyby často začínají číslicí 5, dočasné číslicí 4, ale přesnou příčinu určuje až celý kód a text. Neřešte automaticky SPF, pokud hlášení říká, že schránka příjemce neexistuje. U dočasné chyby sledujte, zda poštovní server doručení zkouší znovu; u trvalé chyby opravte adresu či příčinu uvedenou protistranou.
2. Zpráva dorazila, ale leží ve spamu
Požádejte příjemce o původní zprávu nebo aspoň úplné hlavičky. Zkontrolujte autentizaci, doménu ve viditelném „Od“, obsah a konkrétní cílovou službu. Jeden spamový filtr může rozhodnout jinak než druhý. Proto udělejte test na několika různých doménách a oddělte problém celé domény od pravidla jediného příjemce.
3. Zpráva byla přijata poštovním systémem, ale uživatel ji nevidí
Hledejte karanténu, pravidla schránky, přesměrování a skupinovou adresu. V Microsoft 365 lze použít správní sledování zpráv: stav „Delivered“ může znamenat i zařazení do nevyžádané pošty nebo karantény podle konkrétního filtru, takže je nutné přečíst detaily události. Samotný zelený stav doručení ještě nedokazuje, že zpráva leží v hlavní složce.
4. Selhává pouze faktura nebo webový formulář
Odešlete dvě testovací zprávy na stejnou vnější adresu: jednu ze schránky pracovníka, druhou z aplikace. Porovnejte jejich hlavičky a odesílací server. Často se ukáže, že aplikace používá výchozí poštu webhostingu nebo nesprávně nastavuje adresu zákazníka jako odesílatele. Oprava patří do nastavení aplikace a její autentizace, ne nutně do běžné schránky zaměstnance.
Praktický test WordPress formuláře
U modelového webu firma.cz vyplní zákazník formulář adresou zakaznik@jina-domena.cz. Pokud plugin odešle zprávu s hlavičkou From: zakaznik@jina-domena.cz přímo z vašeho serveru, vystupuje jako cizí doména, kterou neovládáte. Bezpečnější výchozí konfigurace bývá From: formular@firma.cz přes autorizovanou poštovní službu a zákaznická adresa v Reply-To:. Pak odpověď v klientu směřuje zákazníkovi, ale technický odesílatel patří vaší doméně.
Tento příklad neupravujte mechanicky bez kontroly pluginu. Změňte nastavení v testu, odešlete formulář a sledujte, co dorazí a co se objeví v hlavičkách. Důležité je také, aby systém správně hlásil chybu odeslání; samotná zelená hláška na webu není důkazem doručení e-mailu.
Co hledat v hlavičce a provozním logu
| Údaj | Kde jej hledat | Co napoví |
|---|---|---|
| Message-ID a čas | Hlavička nebo log odeslání | Umožní dohledat jednu konkrétní zprávu |
| From a Return-Path | Úplná hlavička | Ukáže viditelnou a technickou doménu |
| Authentication-Results | Hlavička u příjemce | SPF, DKIM a DMARC výsledek skutečné zprávy |
| Stav a chyba | Nedoručenka či správní trasování | Odmítnutí, odklad, karanténa nebo doručení |
Ne každý příjemce zpřístupní všechny údaje. Pokud máte administraci Microsoft 365, použijte message trace; u jiné služby požádejte podporu o odpovídající log. Při předání případu uveďte přesný čas s časovým pásmem, odesílatele, příjemce, Message-ID a chybový text. Neposílejte podporám hesla ani celé citlivé faktury, pokud k diagnostice stačí technické údaje.
Jak oddělit reputaci od technické chyby
Pokud testy ukazují úspěšné SPF/DKIM/DMARC a přesto většina marketingových zpráv končí ve spamu, prozkoumejte kvalitu seznamu adres, stížnosti, odhlášení a frekvenci kampaní. Google pro hromadné odesílatele sleduje míru nahlášení spamu a uvádí hranici 0,3 %; jako provozní cíl je rozumné držet ji výrazně níže. Nákup databáze kontaktů či prudké rozeslání z nové domény mohou reputaci poškodit i při dokonalých DNS záznamech.
Pokud selhává jen jedna firma jako příjemce, její správce může mít vlastní pravidlo či blokaci. Zeptejte se na konkrétní odmítnutí a nevyžadujte obecné „přidejte nás do bezpečných odesílatelů“ jako první krok. To může překrýt chybu u vás a problém se objeví u dalších adresátů.
Kdy problém předat poskytovateli
- Máte opakované odmítnutí se stejným kódem a vlastní základní kontrola DNS nevysvětluje příčinu.
- Odesílací služba hlásí úspěch, ale cílový server zprávu nedostal nebo ji odložil.
- Chybí nebo se mění DKIM podpis u zpráv, které mají jít přes stejnou službu.
- Po migraci se rozcházejí odesílací servery podle uživatele či aplikace.
Dobře popsaný jediný případ s hlavičkami a časem bývá užitečnější než deset obecných stížností. Po opravě zopakujte původní test stejnou cestou a zkontrolujte výsledek u více příjemců.
Jak poznat, že náprava vydržela
Nezastavujte kontrolu u jedné úspěšné zprávy. V následujících dnech sledujte běžnou poštu, systémové notifikace i případné kampaně zvlášť. Zaznamenejte nové odmítnuté zprávy, stížnosti a dotazy zákazníků na chybějící fakturu. Pokud se potíž vrací jen v určitou hodinu nebo při vyšším objemu, prověřte odchozí limit a provozní log poskytovatele. Tak odlišíte opravený DNS záznam od problému, který souvisí s kapacitou nebo s jinou aplikací.
Časté otázky
Zaručí SPF, DKIM a DMARC doručení do hlavní schránky?
Ne. Pomáhají ověřit oprávněného odesílatele, ale příjemce hodnotí také reputaci, obsah, chování adresátů a vlastní pravidla. Úspěšná autentizace je nutný technický podklad, nikoli slib umístění v inboxu.
Jaký je rozdíl mezi odmítnutím zprávy a doručením do spamu?
Odmítnutí obvykle vrací odesílateli chybovou zprávu s důvodem. Zpráva ve spamu byla přijata, ale příjemcův systém ji vyhodnotil jako podezřelou. Obě situace vyžadují jinou diagnostiku.
Proč selhávají jen e-maily z webového formuláře?
Formulář může odesílat přes jiný server než běžná firemní schránka. Ověřte adresu odesílatele, způsob odeslání a zda je tato služba zahrnuta v autentizaci domény. Testujte na několika cizích schránkách.
Pomůže změnit jen předmět nebo text zprávy?
Někdy obsah přispívá k filtrování, ale bez kontroly hlavičky a provozních logů je to hádání. Nejdřív určete, zda zpráva odešla, byla přijata, odmítnuta nebo přesunuta do spamu.
Kdy oslovit poskytovatele pošty?
Když máte konkrétní čas, odesílatele, příjemce, chybový kód nebo hlavičku testovací zprávy a vlastní kontroly nevysvětlily výsledek. Neposílejte podpoře obsah citlivých zpráv, pokud není k diagnostice nezbytný.
Zdroje
- Google: Email sender guidelines, autentizace, požadavky na hromadné odesílatele a spam rate ověřeny 21. 10. 2026.
- Microsoft Learn: Message trace FAQ, význam stavů doručení a diagnostika ověřeny 21. 10. 2026.




