Vanliga frågor

echo.email analyserar ett mejl per adress och förklarar resultatet. Svaren nedan förklarar hur tjänsten fungerar och vad varje kontroll i rapporten betyder.

Hur fungerar echo.email?

Startsidan skapar en ny adress av tre ord, till exempel power.file.tube@echo.email. Ett meddelande till den adressen kommer till e-postservern hos echo.email, som sparar SMTP-konversationen och skickar meddelandet vidare till analysen. Några sekunder senare visar sidan en rapport om autentisering, innehåll, regelefterlevnad och leverans. Du behöver inte installera något, och det finns inga konton.

Hur länge är adressen giltig?

Adressen är aktiv så länge sidan är öppen. Sidan kontaktar servern varannan sekund, och om du laddar om sidan inom 10 minuter behåller du samma adress i samma flik. När sidan har varit stängd i mer än 10 minuter avvisar e-postservern nya meddelanden till adressen med ett permanent fel.

Bara det första meddelandet som kommer fram räknas. Senare meddelanden till samma adress avvisas, så varje rapport hör till exakt ett mejl. Meddelanden över 10 MB avvisas under SMTP-konversationen.

Hur länge sparas rapporterna?

Varje rapport, det sparade meddelandet och data från hämtade bilder raderas automatiskt 24 timmar efter att meddelandet kom fram. Under de 24 timmarna fungerar länken till rapporten för alla som har länken. Därefter slutar länken att fungera. Det enda undantaget är exempelrapporten, eftersom den kommer från ett testmeddelande som skickades för det syftet.

Vad händer med innehållet i meddelandet?

echo.email sparar hela meddelandet, alltså headers, brödtext och bilagor, tillsammans med data från SMTP-sessionen, som den sändande IP-adressen, HELO-namnet och TLS-versionen. Uppgifterna stannar inom EU, och e-postservern körs i Falkenstein i Tyskland. Alla med länken till rapporten ser hela meddelandet, så testa helst med innehåll som du kan dela. Nyhetsbrev innehåller ofta spårningslänkar och en avregistreringslänk som är kopplad till en viss mottagare. Om du skickar en kopia till en testlista förblir de länkarna privata.

Två adresser går direkt till den som driver tjänsten: contact@echo.email för frågor och anmälningar om missbruk, och privacy@echo.email för förfrågningar om personuppgifter. Integritetspolicyn innehåller alla detaljer.

Vad testar SPF-kontrollen?

SPF listar de servrar som får skicka e-post med en domän i return path. echo.email tar domänen från kuvertavsändaren (MAIL FROM-adressen, även kallad return path) och utvärderar domänens SPF-post för IP-adressen hos servern som levererar meddelandet. Bara pass räknas som ett bra resultat. Med softfail, neutral eller none har mottagaren inget SPF-bevis för avsändaren.

HELO-namnet kontrolleras inte, på samma sätt som de stora e-postleverantörerna gör när de bedömer SPF för massutskick. Rapporten visar varje post och varje mekanism längs vägen, så att det syns hur slutresultatet uppstår.

Varför spelar antalet DNS-uppslag roll?

En SPF-utvärdering får göra högst 10 DNS-uppslag. Mekanismerna include, a, mx, ptr, exists och redirect räknas mot den gränsen, även de som finns i nästlade include. Om gränsen överskrids blir resultatet ett permanent fel, och mottagare behandlar meddelandet som om det inte hade någon giltig SPF alls. Tomma uppslag, alltså uppslag som inte returnerar någon post, har en egen gräns på två. Den vanliga orsaken är långa kedjor av include från tredje part, och en kortare lista med tjänster löser problemet.

Vad bevisar DKIM?

DKIM lägger till en kryptografisk signatur i meddelandets headers. Den signerande domänen publicerar den publika nyckeln i DNS under en selektor. echo.email hämtar nyckeln och verifierar signaturen mot headers och brödtext som de kom fram. Pass betyder att de signerade delarna kom fram oförändrade och att den signerande domänen står för dem.

Rapporten visar den signerande domänen (d=), selektorn (s=), de signerade headers (h=) samt nyckelns typ och storlek. En gräns för brödtextens längd (l=) markeras, eftersom den gör det möjligt att lägga till innehåll efter signaturen.

Vad är DMARC?

DMARC kopplar SPF och DKIM till domänen i den synliga From-adressen. From-domänen publicerar en policy på _dmarc.<domain> som talar om för mottagarna hur de ska hantera e-post som inte klarar autentiseringen: none, quarantine eller reject. Ett meddelande godkänns av DMARC när SPF eller DKIM godkänns för en domän som är alignerad med From-domänen.

DMARC lägger inte till någon egen autentisering. Värdet ligger i kravet på alignment och i de sammanställda rapporterna (rua=) som mottagarna skickar till domänens ägare.

Vad betyder alignerat?

Alignment jämför en autentiserad domän med From-domänen. Avslappnad alignment kräver samma organisationsdomän, så mail.example.com är alignerad med example.com. Strikt alignment kräver exakt samma värdnamn. Organisationsdomänen kommer från Public Suffix List, som vet att namn som example.co.uk räknas som en enda registrerbar domän. När rapporten säger alignerat utan någon annan förklaring gäller jämförelsen From-domänen.

Vad är BIMI?

BIMI publicerar en varumärkeslogotyp som e-postleverantörer kan visa bredvid autentiserade meddelanden. Posten finns på default._bimi.<domain> och pekar på en SVG-logotyp (l=) och, för de flesta leverantörer, på ett Verified Mark Certificate (a=). BIMI gäller bara domäner med en tillämpad DMARC-policy, alltså quarantine eller reject till 100 procent. echo.email visar posten och om DMARC-policyn uppfyller kravet.

Varför spelar omvänd DNS roll?

Varje IP-adress som skickar e-post behöver en PTR-post som pekar på ett värdnamn, och det namnet behöver en A- eller AAAA-post som pekar tillbaka på samma IP-adress. Den kontrollen fram och tillbaka kallas forward-confirmed reverse DNS, eller FCrDNS. De stora e-postleverantörerna ser FCrDNS som ett minimikrav för en sändande server, och e-post från en IP-adress utan PTR-post avvisas ofta direkt.

Vad är generisk omvänd DNS?

Vissa PTR-poster följer ett namnmönster från internetleverantören, till exempel 192-0-2-10.dynamic.example.net. Sådana namn tyder på en hemanslutning eller en server som ingen har konfigurerat för e-post, och filter misstror dem. Ett eget namn i avsändarens domän, till exempel mail.example.com, visar att e-postservern är konfigurerad med avsikt.

Vilket HELO-namn fungerar bäst?

Den sändande servern presenterar sig med ett HELO- eller EHLO-namn i början av SMTP-konversationen. Ett bra namn tillhör den sändande servern, går att slå upp i DNS och stämmer med PTR-posten för den sändande IP-adressen. IP-adresser utan namn, namn som localhost och slumpmässiga teckensträngar är typiska för skadlig kod och snowshoe-spam, och filter väger in det.

Varför kontrollera TLS?

Opportunistisk TLS krypterar SMTP-konversationen när den mottagande servern erbjuder STARTTLS. echo.email erbjuder STARTTLS vid varje anslutning och sparar den TLS-version och det chiffer som avsändaren väljer. E-post som skickas utan TLS går i klartext mellan de två servrarna, och Google och Yahoo kräver TLS av avsändare som gör massutskick. Rapporten räknar också länkar och bilder som laddas via vanlig http, eftersom även de förfrågningarna går okrypterade.

Varför kontrollera IPv6?

Två frågor avgör om ett meddelande är klart för IPv6. Den första frågan är om avsändaren når e-postservrar som bara använder IPv6. Ett meddelande som kommer via IPv6 svarar ja direkt. Ett meddelande som kommer via IPv4 räknas ändå som klart för IPv6 när den sändande värden har en AAAA-post, den omvända DNS:en för IPv6-adressen pekar på samma värd och SPF godkänns för den adressen. De flesta e-postservrar väljer IPv4 eller IPv6 vid varje anslutning, så nästa meddelande från samma värd kommer ofta via IPv6. Den andra frågan är om varje värd som levererar bilder och länkar i meddelandet har en AAAA-post, så att en läsare på ett nätverk med bara IPv6 eller bakom operatörens NAT (CGNAT) ändå kan ladda innehållet. Rapporten markerar meddelandet som klart för IPv6 när båda svaren är ja.

Hur mäts mejlets storlek?

Mejlets storlek är antalet byte som skickades: alla headers, varje MIME-del, bilagor och det extra utrymmet från kodning med base64 eller quoted-printable. Gmail kortar meddelanden med mer än cirka 102 KB HTML och döljer resten bakom en länk. Den bortkortade delen innehåller ofta avregistreringslänken och spårningspixeln.

Vad är bildernas vikt?

Bildernas vikt är den totala storleken på de externa bilder som anges i <img>-taggar, mätt genom att varje bild hämtas en gång. Talet är ett minimum, eftersom bilder i srcset-attribut och CSS-bakgrunder inte räknas. Ett tungt meddelande laddas långsamt på mobilanslutningar och förbrukar läsarens data.

Vad är överflödig bildvikt?

Överflödig bildvikt uppskattar hur många byte en avsändare skulle spara genom att leverera varje bild närmare den storlek som meddelandet visar den i. En bild upp till dubbla visningsstorleken räknas som noll överflödig vikt, eftersom skärmar med hög pixeltäthet använder de extra pixlarna. Över dubbla visningsstorleken lägger de extra pixlarna till byte utan att lägga till detaljer. Bilder under 1 KB, till exempel utfyllnadsbilder, räknas inte.

Hur hanterar echo.email bilder?

Analysen hämtar varje extern bild en gång och sparar HTTP-status, omdirigeringar, storlek, innehållstyp och mått i pixlar. Sedan jämförs måtten med storleken som anges i HTML-koden. Att hämta en bild är vad ett e-postprogram gör när en läsare öppnar meddelandet, så öppningsspårningen registrerar en öppning. Hämtningarna görs från Cloudflares nätverk, och förfrågningar till privata eller interna adresser avvisas.

Länkarna plockas ut ur HTML-koden och grupperas efter värd, med avkodade frågeparametrar så att de blir läsbara. echo.email följer aldrig vanliga länkar, eftersom en länk kan bekräfta en prenumeration, starta en åtgärd eller registrera ett klick. Det enda undantaget är URL:en för avregistrering med ett klick, som beskrivs nedan.

Vad är List-Unsubscribe?

List-Unsubscribe är en header som definieras i RFC 2369. Headern innehåller ett eller flera sätt att lämna listan, till exempel en mailto:-adress, en https:-URL eller båda. E-postleverantörer använder headern för att visa en egen avregistreringsknapp bredvid avsändarens namn. URL:er med vanlig http är föråldrade, och https är det som förväntas.

Vad är avregistrering med ett klick?

RFC 8058 lägger till en andra header, List-Unsubscribe-Post, med det fasta värdet List-Unsubscribe=One-Click. När båda headers finns skickar e-postleverantören en POST-förfrågan till https-URL:en, och mottagaren lämnar listan utan att besöka någon sida. Google och Yahoo kräver avregistrering med ett klick av avsändare som gör massutskick.

echo.email skickar samma POST-förfrågan och visar svaret. Alla 2xx-statusar räknas som lyckade. Förfrågan avregistrerar bara den tillfälliga adressen hos echo.email.

Vad betyder avregistrering utan interaktion?

En avregistrering utan interaktion slutförs utan att mottagaren öppnar en webbläsare eller bekräftar något. One-click enligt RFC 8058 är den föredragna metoden. En mailto:-adress i List-Unsubscribe räknas också, men avregistrering via e-post går långsammare och ger mottagaren ingen bekräftelse, så leverantörer ser mailto som en reservlösning.

Varför behövs det fortfarande en avregistreringslänk i meddelandet?

Marknadsföringslagar i de flesta länder kräver ett synligt sätt att lämna listan i själva meddelandet, oftast en länk i sidfoten. Headers är till för e-postleverantören, och länken i sidfoten är till för läsaren. echo.email letar efter en länk med avregistreringstext eller en URL som ser ut som en avregistreringslänk. Identifieringen är en tumregel och väljer ibland fel länk. En egen spårningsparameter på länken i sidfoten gör att avsändarens statistik kan skilja avregistreringar via sidfoten från avregistreringar via headern.

Vad är List-Id?

List-Id (RFC 2919) ger ett namn åt den e-postlista som ett meddelande hör till, till exempel News <news.example.com>. Google och Yahoo kräver inte headern. Mottagande servrar och mottagare använder headern för att sortera och filtrera e-post per utskicksflöde, så det är god praxis att lägga till den.

Vad är listan över god praxis?

Listan följer de krav som Google och Yahoo publicerade 2024 för avsändare som gör massutskick: alignerad SPF, alignerad DKIM, forward-confirmed reverse DNS (FCrDNS), TLS, en From-domän som inte är en gratis e-posttjänst och som inte underkänns av DMARC, en publicerad DMARC-policy, minst en alignerad autentiseringsmetod, avregistrering med ett klick och en synlig avregistreringslänk. Varje rad säger ja eller nej. En röd rad är en trolig orsak till sämre placering i inkorgen hos de stora leverantörerna, och full poäng är grunden för massutskick.

Vissa rader räknas bara när de är tillämpliga. De två raderna om avregistrering räknas när meddelandet har en header för massutskick: List-Unsubscribe, List-Unsubscribe-Post, List-Id eller Precedence med värdet bulk, list eller junk. I ett personligt meddelande utan någon av de headers räknas raderna inte. SPF-alignment ingår inte i poängen när kuvertavsändaren har skrivits om med SRS och DMARC godkänns med alignerad DKIM. Efter en SRS-omskrivning kontrollerar SPF domänen för servern som skrev om adressen i stället för From-domänen. Vidarebefordringstjänster använder SRS som standard, och vissa sändande servrar tillämpar SRS på all utgående e-post, vilket gör att SPF-alignment går förlorad. Poängen visar hur många av de räknade raderna som är uppfyllda.

Hur visas meddelandet?

Den renderade vyn visar HTML-delen i en isolerad ram (sandbox). Det är webbläsaren som renderar, så resultatet motsvarar en webbläsare på en dator och inte ett visst e-postprogram eller en viss enhet. Skript, formulär och länkar är avstängda i förhandsvisningen. Andra vyer visar meddelandet med blockerade bilder och med alt-texten i stället för varje bild, och så ser många läsare ett meddelande första gången.

Vad visar MIME-avsnittet?

MIME är meddelandets inre struktur: delarna, innehållstyperna, teckenuppsättningarna, överföringskodningarna och gränserna som skiljer delarna åt. Ett vanligt nyhetsbrev har en multipart/alternative-behållare med en text/plain-del och en text/html-del. En saknad textdel, en saknad avslutande gräns eller en ovanlig nästling syns tydligt i trädet.

Vad visar avsnittet Rått meddelande?

Avsnittet Rått meddelande visar meddelandet som det togs emot, med statistik: total storlek, antal rader, den längsta raden, tecken utanför ASCII och radbrytningar utan CR. RFC 5322 begränsar en rad till 998 tecken, och vissa servrar bryter eller avvisar längre rader. Radbrytningar utan vagnretur (CR) är en vanlig orsak till DKIM-fel, eftersom servrar längs vägen skriver om dem.

Vyn för det råa meddelandet börjar med de spårningsheaders som mx.echo.email sparar vid leveransen: Return-Path, Authentication-Results, Received-SPF och Received. Under dem finns meddelandet exakt som det togs emot, och nedladdningslänken ger den oförändrade .eml-filen.

Vilka blocklistor kontrolleras i rapporten?

Mottagare slår upp den sändande IP-adressen och avsändardomänerna i blocklistor i DNS, och en listning på en lista som används mycket leder till avvisad eller filtrerad e-post. Rapporten kontrollerar samma listor som scan.mx: Spamhaus ZEN och AuthBL för IP-adressen, Spamhaus DBL och ZRD för From-domänen och kuvertdomänen, samt SpamCop, GBUdb Truncate och PSBL för IPv4-adresser. Varje rad säger listad eller inte listad, med en länk till sidan för borttagning hos den som driver listan.

En listning enligt policy i Spamhaus PBL markerar ett adressintervall som inte ska skicka e-post direkt, till exempel en hemanslutning. E-post från en sådan adress ska gå via leverantörens e-postserver. Resultaten cachas i två timmar, så en rättelse syns i ett nytt test senast två timmar senare.

Vad betyder SpamAssassin-poängen?

SpamAssassin är ett skräppostfilter med öppen källkod som många mottagande servrar använder. E-postservern sätter poäng på varje testmeddelande med SpamAssassin och standardreglerna, som uppdateras varje dag. Rapporten visar summan, skräppostgränsen 5 och varje regel som slog till, med de regler som ger flest poäng först. Negativa poäng räknas till meddelandets fördel, till exempel för en giltig DKIM-signatur.

Nätverkstesterna slår upp den sändande IP-adressen och länkarnas domäner hos Spamhaus (via DQS), URIBL, SURBL och de andra listorna i standardreglerna. Bayesiansk inlärning och de delade hashnätverken Razor, Pyzor och DCC är avstängda, så poängen beror bara på meddelandet, och inget om meddelandet lämnar servern för inlärning.

Poängen är vägledande och räknas inte in i poängen för god praxis. Varje mottagare använder ett eget filter med egna regler och gränser, och Gmail och Outlook använder inte SpamAssassin. En poäng över noll är normalt. Reglerna med flest poäng visar var en ändring hjälper mest. Meddelanden över 500 KB får ingen poäng.

Varför behöver avsändardomäner e-postservrar?

Svar går till From-domänen, och studsar går till kuvertavsändarens domän. Båda behöver en MX-post, eller åtminstone en adresspost som e-postservrar använder som reserv. En null MX, alltså en enda MX som pekar på en punkt (RFC 7505), anger att en domän inte tar emot någon e-post, och vissa mottagare avvisar meddelanden från en sådan domän.

Vilka HTML-element räknas som riskabla?

Skript, formulär, iframe, object och embed behövs sällan i ett mejl. De flesta e-postprogram tar bort dem, och skräppostfilter ser dem som tecken på nätfiske. Enkla länkar och bilder gör samma jobb utan den nackdelen. Innehållsavsnittet visar också HTML-kodens storlek och hur mycket synlig text HTML-koden innehåller, eftersom ett meddelande som nästan bara består av kod eller bilder ser misstänkt ut för filter.

Varför markeras länkförkortare?

Offentliga länkförkortare som bit.ly döljer den verkliga destinationen. Nätfiskekampanjer använder dem ofta, så filter misstror länkar som går via dem. Länkar som pekar direkt till avsändarens domän bygger upp ett gott rykte.

Vad visar DNS-avsnittet?

Varje DNS-uppslag som görs för rapporten visas i DNS-avsnittet, grupperat efter syfte: omvänd DNS, SPF, DKIM, DMARC, BIMI, e-postservrar och IPv6-kontrollen. Uppslag mot blocklistor visas inte, eftersom namnen i de uppslagen innehåller en åtkomstnyckel. Varje post visar namnet, posttypen, svarskoden, svaren med deras TTL och eventuella auktoritativa poster. Listan visar vilka poster som gav varje resultat, och det hjälper när en nyligen gjord ändring i DNS ännu inte har nått alla resolvrar.

Fler gratis verktyg

scan.mx
Kontrollerar e-postinställningarna för en domän: MX, SPF, DKIM, DMARC, BIMI.
portscan.com
Kontrollerar vilka TCP-portar som är öppna på en IP-adress, även port 25.