Transakční zprávy WordPressu posílejte přes důvěryhodného poskytovatele, používejte adresu z vlastní ověřené domény a nastavte SPF, DKIM a DMARC podle jeho pokynů. Logujte technický identifikátor a stav bez citlivého těla zprávy, monitorujte odmítnutí a pravidelně testujte formuláře i reset hesla.
E-mail z WordPressu může být aplikací odeslán, a přesto se nedostat do doručené pošty. Mezi formulářem a příjemcem stojí kód, fronta, poskytovatel, DNS autentizace, reputace domény a spamový filtr. Funkce, která vrátí úspěch, obvykle potvrzuje pouze předání další vrstvě. Bez logů tým neví, zda zpráva nevznikla, byla odmítnuta, nebo doručena do spamu.
Spolehlivé řešení využívá transakčního poskytovatele přes autentizované SMTP nebo API, správné DNS záznamy domény a oddělení systémových zpráv od marketingových kampaní. Formulář navíc potřebuje potvrzení na obrazovce a bezpečný záznam požadavku, aby se při výpadku e-mailu poptávka neztratila. Tento návod ukazuje celý tok bez slibu stoprocentního doručení.
Zmapujte všechny typy odesílaných zpráv
Vypište kontaktní formuláře, objednávky, reset hesla, registrace, administrační upozornění a vlastní automatizace. U každé zprávy určete spouštěč, příjemce, adresu odesílatele, adresu pro odpověď, kritičnost a vlastníka šablony. Test pouze kontaktního formuláře nepokrývá e-mail z WooCommerce nebo bezpečnostního pluginu, který používá jinou cestu.
Rozlište transakční zprávy vyvolané akcí člověka od marketingu a newsletterů. Hromadnou kampaň neposílejte přes běžný webový proces, protože zatíží server a může poškodit reputaci důležitých systémových zpráv. Kritická zpráva má mít i jiný signál nebo záznam, aby provoz nezávisel výhradně na jedné schránce.
Nastavte důvěryhodného odesílatele
Adresa From má používat doménu, kterou organizace vlastní a poskytovatel ověřil. Nevkládejte e-mail návštěvníka jako odesílatele; po validaci patří do Reply-To. Jinak zpráva předstírá cizí doménu a může selhat autentizace. Zobrazované jméno ať jasně identifikuje web nebo proces a zůstane konzistentní.
SPF povoluje zdroje odesílání, DKIM podepisuje zprávu a DMARC určuje politiku i reportování shody. Záznamy nastavujte přesně podle aktivních poskytovatelů a nevytvářejte více SPF záznamů pro jednu doménu. Při změně služby ponechte přechod jen po nezbytnou dobu. Stav DNS ověřte nezávislým testem a reporty směřujte vlastníkovi.
- From na ověřené vlastní doméně
- Návštěvník pouze v Reply-To
- SPF pro všechny platné odesílatele
- Podpis DKIM a monitorovaná politika DMARC
Vyberte SMTP nebo API a chraňte klíče
SMTP je široce podporované a jednoduché, API může nabídnout podrobnější události, šablony a kontrolu. Rozhoduje dokumentace, region, limity, webhooky, podpora a kompatibilita pluginu. Používejte šifrované spojení a samostatné produkční přihlašovací údaje s minimálním rozsahem. Heslo nevkládejte do veřejného repozitáře ani na screenshot pro podporu.
Testovací a produkční prostředí mají odlišné klíče a příjemce. Staging nesmí zákazníkům posílat skutečné resety hesla nebo objednávky; použijte zachytávací schránku nebo povolený seznam. Při rotaci připravte překryv a poté starý klíč odeberte. Přístup k nastavení omezte na správce, nikoli na běžného redaktora.
Diagnostikujte podle vrstvy a identifikátoru
Nejprve ověřte, zda WordPress zprávu vytvořil a předal transportu. Poté v portálu poskytovatele vyhledejte ID, stav přijetí, doručení, dočasného odložení, odmítnutí nebo bounce. Zkontrolujte adresu, čas, DNS a odpověď cílového serveru. Test do jedné vlastní schránky neprokazuje chování u všech příjemců.
Aplikační log uchová typ zprávy, čas, bezpečný identifikátor příjemce a výsledek, nikoli celé tělo s osobními údaji nebo resetovacím tokenem. Při dočasné chybě může fronta pokus opakovat, při trvalé chybě potřebuje vlastník upozornění. Neposílejte opakovaně stejný potvrzovací e-mail bez ochrany před duplicitou.
- Vznik zprávy v aplikaci
- ID u poskytovatele
- Stav a odpověď cílového serveru
- Bezpečný log bez citlivého obsahu
Testujte formulář jako celý obchodní proces
Po odeslání formulář uloží poptávku nebo ji předá do CRM, zobrazí potvrzení a odešle zprávu. Pokud e-mail selže, návštěvník nemá přijít o vyplněné údaje bez náhradního procesu. Otestujte validaci, ochranu proti spamu, přílohy, Reply-To, více jazyků a mobil. Citlivé údaje uchovávejte pouze podle schváleného účelu a přístupu.
Pravidelný syntetický test může ověřit doručení kontrolní zprávy a upozornit na změnu. Samostatně sledujte bounce rate a blokování domény podle možností poskytovatele. Po aktualizaci formuláře, SMTP pluginu nebo DNS zopakujte reset hesla, poptávku a objednávkový e-mail. Runbook má obsahovat náhradní kontakt a způsob dohledání konkrétní zprávy.
Časté dotazy
Proč WordPress hlásí odeslání, ale e-mail nepřišel?
Úspěch může znamenat pouze předání lokálnímu transportu. Poskytovatel mohl zprávu odložit, odmítnout nebo doručit do spamu. Zkontrolujte aplikační log, ID u poskytovatele, DNS autentizaci a odpověď cílového serveru.
Může být adresa návštěvníka v poli From?
Neměla by. Web nevlastní cizí doménu a zpráva může neprojít kontrolou SPF nebo DMARC. Použijte ověřenou adresu vlastní domény ve From a validovanou adresu návštěvníka v Reply-To.
Stačí nainstalovat SMTP plugin?
Ne. Je třeba nakonfigurovat poskytovatele, bezpečné klíče, SPF, DKIM a DMARC, správné adresy, logy a testy všech typů zpráv. Plugin je transportní vrstva, ne kompletní politika doručování.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
