Časté dotazy

echo.email analyzuje jeden e-mail na adresu a vysvětlí výsledek. Odpovědi níže popisují, jak služba funguje a co znamená každá kontrola v reportu.

Jak echo.email funguje?

Úvodní stránka vytvoří novou adresu ze tří slov, například power.file.tube@echo.email. Zpráva poslaná na tuto adresu dorazí na poštovní server echo.email, který zaznamená komunikaci SMTP a předá zprávu k analýze. Za několik sekund stránka zobrazí report o ověření, obsahu, dodržení pravidel a doručení. Nic nemusíte instalovat a žádné účty neexistují.

Jak dlouho je adresa platná?

Adresa je aktivní, dokud je stránka otevřená. Stránka komunikuje se serverem každé dvě sekundy, a pokud ji obnovíte do 10 minut, zůstane vám ve stejné kartě stejná adresa. Když je stránka zavřená déle než 10 minut, poštovní server odmítá nové zprávy pro tuto adresu s trvalou chybou.

Počítá se jen první zpráva, která dorazí. Další zprávy na stejnou adresu server odmítne, takže každý report odpovídá právě jednomu e-mailu. Zprávy větší než 10 MB server odmítne už během komunikace SMTP.

Jak dlouho se reporty uchovávají?

Každý report, uložená zpráva i data stažených obrázků se automaticky mažou 24 hodin po doručení zprávy. Během těchto 24 hodin funguje odkaz na report pro každého, kdo ho má. Potom odkaz přestane fungovat. Jedinou výjimkou je ukázkový report, protože vznikl z testovací zprávy odeslané právě pro tento účel.

Co se děje s obsahem zprávy?

echo.email ukládá celou zprávu, tedy hlavičky, tělo a přílohy, spolu s daty o relaci SMTP, jako je IP adresa odesílatele, název HELO a verze TLS. Data zůstávají v EU a poštovní server běží ve Falkensteinu v Německu. Každý, kdo má odkaz na report, vidí celou zprávu, proto je nejlepší testovat s obsahem, který můžete sdílet. Newslettery často obsahují sledovací odkazy a odkaz na odhlášení vázaný na jednoho příjemce. Když pošlete kopii na testovací seznam, zůstanou tyto odkazy soukromé.

Dvě adresy vedou přímo k provozovateli služby: contact@echo.email pro dotazy a hlášení zneužití a privacy@echo.email pro žádosti týkající se dat. Všechny podrobnosti najdete v zásadách ochrany soukromí.

Co testuje kontrola SPF?

SPF uvádí servery, které smějí posílat poštu s doménou v return path. echo.email vezme doménu odesílatele obálky (adresu MAIL FROM, které se také říká return path) a vyhodnotí záznam SPF této domény pro IP adresu serveru, který zprávu doručuje. Za dobrý výsledek se považuje jen pass. Při výsledku softfail, neutral nebo none nemá příjemce pro odesílatele žádný doklad SPF.

Název HELO se nekontroluje, stejně jako to dělají velcí poskytovatelé e-mailu při hodnocení SPF hromadné pošty. Report ukazuje každý záznam a každý mechanismus na cestě, takže je vidět, jak vzniká konečný výsledek.

Proč záleží na počtu dotazů DNS?

Vyhodnocení SPF smí provést nejvýše 10 dotazů DNS. Do tohoto limitu se počítají mechanismy include, a, mx, ptr, exists a redirect, včetně těch ve vnořených include. Překročení limitu změní výsledek na trvalou chybu a příjemci se ke zprávě chovají, jako by neměla žádné platné SPF. Prázdné dotazy, tedy dotazy, které nevrátí žádný záznam, mají vlastní limit dva. Obvyklou příčinou jsou dlouhé řetězce include od třetích stran a problém vyřeší kratší seznam služeb.

Co prokazuje DKIM?

DKIM přidává do hlaviček zprávy kryptografický podpis. Podepisující doména zveřejňuje veřejný klíč v DNS pod selektorem. echo.email klíč načte a ověří podpis podle hlaviček a těla tak, jak dorazily. Výsledek pass znamená, že podepsané části dorazily beze změny a že za ně podepisující doména ručí.

Report ukazuje podepisující doménu (d=), selektor (s=), podepsané hlavičky (h=) a typ a velikost klíče. Limit délky těla (l=) report označí, protože umožňuje po podpisu přidat obsah.

Co je DMARC?

DMARC propojuje SPF a DKIM s doménou viditelné adresy From. Doména From zveřejňuje na _dmarc.<domain> politiku, která příjemcům říká, jak naložit s poštou, která neprojde ověřením: none, quarantine nebo reject. Zpráva projde DMARC, když SPF nebo DKIM projde pro doménu zarovnanou s doménou From.

DMARC samo žádné ověření nepřidává. Jeho přínos je v požadavku na zarovnání a v souhrnných reportech (rua=), které příjemci posílají vlastníkovi domény.

Co znamená zarovnání?

Zarovnání (alignment) porovnává ověřenou doménu s doménou From. Volné zarovnání vyžaduje stejnou organizační doménu, takže mail.example.com je zarovnaná s example.com. Přísné zarovnání vyžaduje přesně stejný název hostitele. Organizační doména vychází z Public Suffix List, který ví, že názvy jako example.co.uk se počítají jako jedna registrovatelná doména. Když report uvádí zarovnání bez dalšího upřesnění, jde o porovnání s doménou From.

Co je BIMI?

BIMI zveřejňuje logo značky, které poskytovatelé e-mailu zobrazují vedle ověřených zpráv. Záznam se nachází na default._bimi.<domain> a odkazuje na logo SVG (l=) a u většiny poskytovatelů také na Verified Mark Certificate (a=). BIMI platí jen pro domény s vynucenou politikou DMARC, tedy quarantine nebo reject na 100 procent. echo.email zobrazí záznam a to, jestli politika DMARC požadavek splňuje.

Proč záleží na reverzním DNS?

Každá IP adresa, která posílá poštu, potřebuje záznam PTR odkazující na název hostitele a tento název potřebuje záznam A nebo AAAA odkazující zpět na stejnou IP adresu. Této kontrole tam a zpět se říká forward-confirmed reverse DNS neboli FCrDNS. Velcí poskytovatelé e-mailu považují FCrDNS za minimum pro odesílající server a pošta z IP adresy bez záznamu PTR bývá často hned odmítnuta.

Co je obecné reverzní DNS?

Některé záznamy PTR se řídí vzorem pojmenování poskytovatele internetu, například 192-0-2-10.dynamic.example.net. Takové názvy naznačují domácí připojení nebo server, který nikdo pro poštu nenastavil, a filtry k nim mají nedůvěru. Vlastní název v doméně odesílatele, například mail.example.com, ukazuje na záměrně nastavený poštovní server.

Jaký název HELO funguje nejlépe?

Odesílající server se na začátku komunikace SMTP představí názvem HELO nebo EHLO. Dobrý název patří odesílajícímu serveru, dá se přeložit v DNS a odpovídá záznamu PTR odesílající IP adresy. Holé IP adresy, názvy jako localhost a náhodné řetězce znaků jsou typické pro malware a spam typu snowshoe a filtry to berou v úvahu.

Proč kontrolovat TLS?

Oportunistické TLS šifruje komunikaci SMTP, když přijímající server nabízí STARTTLS. echo.email nabízí STARTTLS u každého připojení a zaznamenává verzi TLS a šifru, kterou zvolil odesílatel. Pošta odeslaná bez TLS putuje mezi oběma servery jako prostý text a Google a Yahoo vyžadují TLS od hromadných odesílatelů. Report počítá také odkazy a obrázky načítané přes obyčejné http, protože i tyto požadavky putují nešifrovaně.

Proč kontrolovat IPv6?

O připravenosti zprávy na IPv6 rozhodují dvě otázky. První otázka zní, jestli odesílatel dosáhne na poštovní servery, které používají jen IPv6. Zpráva, která dorazí přes IPv6, odpovídá ano přímo. Zpráva, která dorazí přes IPv4, se i tak počítá jako připravená na IPv6, když má odesílající hostitel záznam AAAA, reverzní DNS této adresy IPv6 odkazuje na stejného hostitele a SPF pro tuto adresu projde. Většina poštovních serverů volí IPv4 nebo IPv6 u každého připojení zvlášť, takže další zpráva od stejného hostitele často dorazí přes IPv6. Druhá otázka zní, jestli každý hostitel, který poskytuje obrázky a odkazy ze zprávy, má záznam AAAA, aby si obsah načetl i čtenář v síti jen s IPv6 nebo za NAT operátora (CGNAT). Report označí zprávu jako připravenou na IPv6, když obě odpovědi zní ano.

Jak se měří velikost e-mailu?

Velikost e-mailu je počet bajtů tak, jak byly přeneseny: všechny hlavičky, každá část MIME, přílohy a navýšení kvůli kódování base64 nebo quoted-printable. Gmail ořízne zprávy s více než přibližně 102 KB HTML a zbytek skryje za odkaz. Oříznutá část často obsahuje odkaz na odhlášení a sledovací pixel.

Co je velikost obrázků?

Velikost obrázků je celková velikost vzdálených obrázků uvedených ve značkách <img>, změřená jedním stažením každého obrázku. Číslo je minimum, protože obrázky z atributů srcset a pozadí v CSS se nepočítají. Velká zpráva se na mobilním připojení načítá pomalu a spotřebovává čtenáři data.

Co jsou zbytečná data v obrázcích?

Zbytečná data v obrázcích odhadují, kolik bajtů by odesílatel ušetřil, kdyby každý obrázek poskytoval ve velikosti bližší té, ve které ho zpráva zobrazuje. Obrázek do dvojnásobku zobrazené velikosti se počítá jako nula zbytečných dat, protože displeje s vysokou hustotou pixelů využijí pixely navíc. Nad dvojnásobkem zobrazené velikosti přidávají pixely navíc bajty bez dalších detailů. Obrázky menší než 1 KB, například výplňové obrázky, se nepočítají.

Jak echo.email pracuje s obrázky?

Analýza stáhne každý vzdálený obrázek jednou a zaznamená stav HTTP, přesměrování, velikost, typ obsahu a rozměry v pixelech. Potom tyto rozměry porovná s velikostí uvedenou v HTML. Stažení obrázku je přesně to, co dělá poštovní program, když čtenář zprávu otevře, takže sledování otevření zaznamená otevření. Stahování probíhá ze sítě Cloudflare a požadavky na soukromé nebo interní adresy se odmítají.

Odkazy se vyberou z HTML a seskupí podle hostitele a parametry dotazu se dekódují, aby byly čitelné. echo.email nikdy neotevírá běžné odkazy, protože otevření odkazu může potvrdit odběr, spustit nějakou akci nebo zaznamenat kliknutí. Jedinou výjimkou je URL pro odhlášení jedním kliknutím popsané níže.

Co je List-Unsubscribe?

List-Unsubscribe je hlavička definovaná v RFC 2369. Hlavička obsahuje jeden nebo více způsobů, jak se ze seznamu odhlásit, například adresu mailto:, URL https: nebo obojí. Poskytovatelé e-mailu podle této hlavičky zobrazují vedle jména odesílatele vlastní tlačítko pro odhlášení. URL s obyčejným http jsou zastaralá a očekává se https.

Co je odhlášení z odběru jedním kliknutím?

RFC 8058 přidává druhou hlavičku, List-Unsubscribe-Post, s pevnou hodnotou List-Unsubscribe=One-Click. Když jsou přítomné obě hlavičky, poskytovatel e-mailu pošle na URL https požadavek POST a příjemce se odhlásí ze seznamu, aniž by navštívil jakoukoli stránku. Google a Yahoo vyžadují odhlášení jedním kliknutím od hromadných odesílatelů.

echo.email pošle stejný požadavek POST a zobrazí odpověď. Za úspěch se považuje jakýkoli stav 2xx. Požadavek odhlásí z odběru jen dočasnou adresu echo.email.

Co znamená odhlášení z odběru bez interakce?

Odhlášení z odběru bez interakce proběhne, aniž by příjemce otevřel prohlížeč nebo cokoli potvrzoval. Preferovanou metodou je one-click podle RFC 8058. Počítá se i adresa mailto: v List-Unsubscribe, ale odhlášení e-mailem je pomalejší a příjemci nedá žádné potvrzení, proto ho poskytovatelé berou jako záložní řešení.

Proč je odkaz na odhlášení ve zprávě stále potřeba?

Zákony o marketingu ve většině zemí vyžadují viditelný způsob odhlášení přímo ve zprávě, obvykle odkaz v zápatí. Hlavičky slouží poskytovateli e-mailu a odkaz v zápatí slouží čtenáři. echo.email hledá odkaz s textem o odhlášení nebo URL, která vypadá jako odkaz na odhlášení. Detekce je heuristická a někdy vybere špatný odkaz. Vlastní sledovací parametr na odkazu v zápatí umožní ve statistikách odesílatele odlišit odhlášení ze zápatí od odhlášení přes hlavičku.

Co je List-Id?

List-Id (RFC 2919) pojmenovává e-mailový seznam, do kterého zpráva patří, například News <news.example.com>. Google a Yahoo tuto hlavičku nevyžadují. Přijímající servery a příjemci ji používají k řazení a filtrování pošty podle typu rozesílky, takže její přidání je osvědčený postup.

Co je seznam osvědčených postupů?

Seznam vychází z požadavků, které Google a Yahoo zveřejnily v roce 2024 pro hromadné odesílatele: zarovnané SPF, zarovnaný DKIM, forward-confirmed reverse DNS (FCrDNS), TLS, doména From, která nepatří bezplatné e-mailové službě a neselhává v DMARC, zveřejněná politika DMARC, alespoň jedna zarovnaná metoda ověření, odhlášení jedním kliknutím a viditelný odkaz na odhlášení. Každý řádek říká ano, nebo ne. Červený řádek je pravděpodobnou příčinou horšího umístění ve schránce u velkých poskytovatelů a plné skóre je základem pro hromadnou poštu.

Některé řádky se počítají, jen když se na zprávu vztahují. Dva řádky o odhlášení se počítají, když má zpráva hlavičku hromadného rozesílání: List-Unsubscribe, List-Unsubscribe-Post, List-Id nebo Precedence s hodnotou bulk, list nebo junk. V osobní zprávě bez těchto hlaviček se tyto řádky nepočítají. Zarovnání SPF se do skóre nepočítá, když byl odesílatel obálky přepsán pomocí SRS a DMARC projde díky zarovnanému DKIM. Po přepisu SRS kontroluje SPF doménu serveru, který adresu přepsal, místo domény From. Přeposílací služby používají SRS ve výchozím nastavení a některé odesílající servery uplatňují SRS na veškerou odchozí poštu, čímž se zarovnání SPF ztratí. Skóre ukazuje, kolik započítaných řádků je splněno.

Jak se zpráva zobrazuje?

Vykreslené zobrazení ukazuje část HTML v izolovaném rámu (sandbox). Vykresluje ji prohlížeč, takže výsledek odpovídá prohlížeči na počítači, ne konkrétnímu poštovnímu programu nebo zařízení. Skripty, formuláře a odkazy jsou v náhledu vypnuté. Další zobrazení ukazují zprávu se zablokovanými obrázky a s alternativním textem místo každého obrázku. Tak vidí zprávu poprvé mnoho čtenářů.

Co ukazuje část MIME?

MIME je vnitřní struktura zprávy: části, typy obsahu, znakové sady, přenosová kódování a hranice, které části oddělují. Běžný newsletter má kontejner multipart/alternative s částí text/plain a částí text/html. Chybějící textová část, chybějící uzavírací hranice nebo neobvyklé vnoření jsou ve stromu hned vidět.

Co ukazuje část Zdrojový kód zprávy?

Část Zdrojový kód zprávy ukazuje zprávu tak, jak byla přijata, se statistikami: celková velikost, počet řádků, nejdelší řádek, znaky mimo ASCII a konce řádků bez CR. RFC 5322 omezuje řádek na 998 znaků a některé servery delší řádky zalamují nebo odmítají. Konce řádků bez návratu vozíku (CR) jsou častou příčinou chyb DKIM, protože servery na cestě je přepisují.

Zobrazení zdrojového kódu zprávy začíná sledovacími hlavičkami, které mx.echo.email zaznamená při doručení: Return-Path, Authentication-Results, Received-SPF a Received. Pod nimi je zpráva přesně tak, jak byla přijata, a odkaz ke stažení poskytne nezměněný soubor .eml.

Které blokovací seznamy report kontroluje?

Příjemci vyhledávají IP adresu odesílatele a domény odesílatele v blokovacích seznamech DNS a výskyt na často používaném seznamu vede k odmítnutí nebo odfiltrování pošty. Report kontroluje stejné seznamy jako scan.mx: Spamhaus ZEN a AuthBL pro IP adresu, Spamhaus DBL a ZRD pro doménu From a doménu obálky a navíc SpamCop, GBUdb Truncate a PSBL pro adresy IPv4. Každý řádek říká, jestli je adresa na seznamu, nebo není, a obsahuje odkaz na stránku provozovatele seznamu pro vyřazení ze seznamu.

Záznam kvůli politice ve Spamhaus PBL označuje rozsah adres, ze kterých by se pošta neměla posílat přímo, například domácí připojení. Pošta z takové adresy má odcházet přes poštovní server poskytovatele. Výsledky se ukládají do mezipaměti na dvě hodiny, takže oprava se v novém testu projeví nejpozději za dvě hodiny.

Co znamená skóre SpamAssassin?

SpamAssassin je open source spamový filtr, který používá mnoho přijímajících serverů. Poštovní server ohodnotí každou testovací zprávu pomocí SpamAssassin a standardních pravidel, která se denně aktualizují. Report ukazuje součet, hranici spamu 5 a každé pravidlo, které se uplatnilo, počínaje pravidly s nejvyšším počtem bodů. Záporné body jdou ve prospěch zprávy, například za platný podpis DKIM.

Síťové testy vyhledávají IP adresu odesílatele a domény odkazů ve Spamhaus (přes DQS), URIBL, SURBL a dalších seznamech ze standardních pravidel. Bayesovské učení a sítě sdílených hashů Razor, Pyzor a DCC jsou vypnuté, takže skóre závisí jen na zprávě a žádné údaje o zprávě neopouštějí server kvůli učení.

Skóre je orientační a nepočítá se do skóre osvědčených postupů. Každý příjemce používá vlastní filtr s vlastními pravidly a hranicemi a Gmail ani Outlook SpamAssassin nepoužívají. Skóre nad nulou je normální. Pravidla s nejvíce body ukazují, kde změna pomůže nejvíc. Zprávy větší než 500 KB se nehodnotí.

Proč domény odesílatele potřebují poštovní servery?

Odpovědi chodí na doménu From a nedoručitelné zprávy na doménu odesílatele obálky. Obě domény potřebují záznam MX, nebo alespoň záznam adresy, který poštovní servery použijí náhradně. Null MX, tedy jediný MX odkazující na tečku (RFC 7505), oznamuje, že doména nepřijímá žádnou poštu, a někteří příjemci zprávy z takové domény odmítají.

Které prvky HTML se považují za rizikové?

Skripty, formuláře, iframe, object a embed jsou v e-mailu potřeba jen zřídka. Většina poštovních programů je odstraní a spamové filtry je hodnotí jako znak phishingu. Obyčejné odkazy a obrázky odvedou stejnou práci bez této penalizace. Část o obsahu ukazuje také velikost HTML a množství viditelného textu v HTML, protože zpráva složená téměř jen ze značek nebo obrázků působí na filtry podezřele.

Proč report upozorňuje na zkracovače odkazů?

Veřejné zkracovače jako bit.ly skrývají skutečný cíl. Phishingové kampaně je hojně používají, takže filtry nedůvěřují odkazům, které přes ně vedou. Odkazy vedoucí přímo na doménu odesílatele budují dobrou pověst.

Co ukazuje část DNS?

Každý dotaz DNS provedený pro report se objeví v části DNS, seskupený podle účelu: reverzní DNS, SPF, DKIM, DMARC, BIMI, poštovní servery a kontrola IPv6. Dotazy na blokovací seznamy se nezobrazují, protože jejich názvy obsahují přístupový klíč. Každá položka ukazuje název, typ záznamu, kód odpovědi, odpovědi s jejich TTL a případné autoritativní záznamy. Seznam ukazuje, ze kterých záznamů vznikl každý výsledek, což pomůže, když se nedávná změna v DNS ještě nedostala ke všem resolverům.

Další nástroje zdarma

scan.mx
Kontroluje nastavení e-mailu pro doménu: MX, SPF, DKIM, DMARC, BIMI.
portscan.com
Kontroluje, které porty TCP jsou na IP adrese otevřené, včetně portu 25.