Ofte stillede spørgsmål

echo.email analyserer én e-mail pr. adresse og forklarer resultatet. Svarene nedenfor handler om, hvordan tjenesten virker, og hvad hvert tjek i rapporten betyder.

Hvordan virker echo.email?

Forsiden giver dig en ny adresse af tre ord, for eksempel power.file.tube@echo.email. En besked sendt til adressen lander på mailserveren hos echo.email. Serveren registrerer SMTP-samtalen og sender beskeden videre til analyse. Et par sekunder senere skifter siden til en rapport om autentificering, indhold, overholdelse af regler og levering. Du skal ikke installere noget, og der findes ingen konti.

Hvor længe er adressen gyldig?

Adressen er aktiv, så længe siden er åben. Siden kontakter serveren hvert andet sekund, og genindlæser du inden for 10 minutter, beholder du den samme adresse i den samme fane. Når siden har været lukket i mere end 10 minutter, afviser mailserveren ny mail til adressen med en permanent fejl.

Den første besked, der ankommer, vinder. Senere beskeder til den samme adresse bliver afvist, så hver rapport hører til præcis én e-mail. Beskeder større end 10 MB bliver afvist under SMTP-samtalen.

Hvor længe gemmes rapporterne?

Hver rapport, den gemte besked og de hentede billeddata bliver slettet automatisk 24 timer efter, at beskeden ankom. I de 24 timer virker rapportlinket for alle, der har linket, og bagefter holder linket op med at virke. Eksempelrapporten er den eneste undtagelse, fordi den kommer fra en testbesked, der er sendt til formålet.

Hvad sker der med beskedens indhold?

echo.email gemmer hele beskeden, altså headers, brødtekst og vedhæftede filer, sammen med oplysninger om SMTP-sessionen som den afsendende IP-adresse, HELO-navnet og TLS-versionen. Data opbevares i EU, og mailserveren kører i Falkenstein i Tyskland. Alle med rapportlinket kan se hele beskeden, så testbeskeder fungerer bedst med indhold, der er sikkert at dele. Nyhedsbreve har ofte trackinglinks og et afmeldingslink knyttet til én modtager. En kopi sendt til en testliste holder dem private.

To adresser går direkte til den ansvarlige: contact@echo.email til spørgsmål og henvendelser og privacy@echo.email til anmodninger om data. Privatlivspolitikken har alle detaljer.

Hvad tester SPF-tjekket?

SPF angiver de servere, der må sende mail med et domæne i return path. echo.email tager domænet fra konvolutafsenderen (MAIL FROM-adressen, også kaldet return path) og evaluerer domænets SPF-post mod IP-adressen på den server, der leverer beskeden. Kun pass tæller som et godt resultat. Ved softfail, neutral og none har den modtagende server intet SPF-bevis for afsenderen.

echo.email tjekker ikke HELO-navnet. De store mailudbydere evaluerer SPF for massemail på samme måde. Rapporten viser hver post og hver mekanisme undervejs, så vejen til det endelige resultat er synlig.

Hvorfor betyder antallet af DNS-opslag noget?

En SPF-evaluering må højst bruge 10 DNS-opslag. Mekanismerne include, a, mx, ptr, exists og redirect tæller hver især med i grænsen, også dem i indlejrede includes. Går evalueringen over grænsen, bliver resultatet en permanent fejl, og modtagende servere behandler så beskeden, som om den slet ikke har en gyldig SPF. Opslag uden resultat, altså forespørgsler uden en post, har en separat grænse på to. Lange kæder af includes fra tredjeparter er den typiske årsag, og en kortere liste af tjenester løser problemet.

Hvad beviser DKIM?

DKIM tilføjer en kryptografisk signatur til beskedens headers. Det signerende domæne offentliggør den offentlige nøgle i DNS under en selector. echo.email henter nøglen og verificerer signaturen mod headers og brødtekst, som de blev modtaget. Et pass betyder, at de signerede dele ankom uændret, og at det signerende domæne står inde for dem.

Rapporten viser det signerende domæne (d=), selectoren (s=), de signerede headers (h=) samt nøglens type og størrelse. En grænse for brødtekstens længde (l=) bliver markeret, fordi den gør det muligt at tilføje ekstra indhold efter signeringen.

Hvad er DMARC?

DMARC knytter SPF og DKIM til domænet i den synlige From-adresse. From-domænet offentliggør en politik på _dmarc.<domain>, der fortæller modtagende servere, hvordan de skal behandle mail, som fejler autentificeringen: none, quarantine eller reject. En besked består DMARC, når SPF eller DKIM består for et domæne, der er aligned med From-domænet.

DMARC tilføjer ingen autentificering i sig selv. Værdien ligger i kravet om alignment og i de samlede rapporter (rua=), som modtagende servere sender tilbage til domæneejeren.

Hvad betyder aligned?

Alignment sammenligner et autentificeret domæne med From-domænet. Lempelig alignment kræver det samme organisatoriske domæne, så mail.example.com er aligned med example.com. Streng alignment kræver præcis det samme hostnavn. Det organisatoriske domæne kommer fra Public Suffix List, som ved, at navne som example.co.uk tæller som ét registrerbart domæne. Når rapporten skriver aligned uden yderligere angivelse, er sammenligningen med From-domænet.

Hvad er BIMI?

BIMI offentliggør et brandlogo, som mailudbydere kan vise ved siden af autentificeret mail. Posten ligger på default._bimi.<domain> og peger på et SVG-logo (l=) og, hos de fleste udbydere, et Verified Mark Certificate (a=). BIMI gælder kun for domæner med en håndhævet DMARC-politik, altså quarantine eller reject ved 100 procent. echo.email viser posten, og om DMARC-politikken opfylder kravet.

Hvorfor er reverse DNS vigtigt?

Hver IP-adresse, der sender mail, skal have en PTR-post, der peger på et hostnavn, og hostnavnet skal have en A- eller AAAA-post, der peger tilbage på den samme IP-adresse. Den tur frem og tilbage hedder forward-confirmed reverse DNS, eller FCrDNS. Store mailudbydere ser FCrDNS som minimumskravet for en afsendende server, og mail fra en IP-adresse uden PTR-post bliver ofte afvist med det samme.

Hvad er generisk reverse DNS?

Nogle PTR-poster følger et navnemønster fra en internetudbyder, for eksempel 192-0-2-10.dynamic.example.net. Navne som disse tyder på en privat forbindelse eller en server, som ingen har sat op til mail, og filtre behandler dem med mistanke. Et dedikeret navn i afsenderens eget domæne, for eksempel mail.example.com, viser en bevidst opsat mailserver.

Hvilket HELO-navn virker bedst?

Den afsendende server præsenterer sig med et HELO- eller EHLO-navn i starten af SMTP-samtalen. Et godt navn tilhører den afsendende server, kan slås op i DNS og matcher PTR-posten for den afsendende IP-adresse. Rene IP-adresser, navne som localhost og tilfældige tegnstrenge er typiske for malware og snowshoe-spam, og filtre vægter dem derefter.

Hvorfor tjekke TLS?

Opportunistisk TLS krypterer SMTP-samtalen, når den modtagende server tilbyder STARTTLS. echo.email tilbyder STARTTLS på hver forbindelse og registrerer den TLS-version og cipher, som afsenderen valgte. Mail sendt uden TLS rejser som klartekst mellem de to servere, og Google og Yahoo kræver TLS af masseafsendere. Rapporten tæller også links og billeder, der hentes over almindelig http, fordi de forespørgsler også rejser ukrypteret.

Hvorfor tjekke IPv6?

To spørgsmål afgør, om en afsender er klar til IPv6. Det første er, om afsenderen kan nå mailservere, der kun bruger IPv6. En besked, der ankommer over IPv6, svarer direkte ja. En besked, der ankommer over IPv4, tæller stadig som klar til IPv6, når den afsendende host har en AAAA-post, reverse DNS for den IPv6-adresse angiver den samme host, og SPF består for adressen. De fleste mailservere vælger IPv4 eller IPv6 for hver forbindelse, så den næste besked fra den samme host ankommer ofte over IPv6. Det andet spørgsmål er, om hver host, der leverer billeder og links i beskeden, har en AAAA-post, så en læser på et netværk med kun IPv6 eller bag carrier-grade NAT stadig kan hente indholdet. Rapporten markerer beskeden som klar til IPv6, når begge svar er ja.

Hvordan måles e-mailens størrelse?

E-mailens størrelse er antallet af bytes, sådan som beskeden blev sendt: alle headers, hver MIME-del, vedhæftede filer og den ekstra plads, som base64- eller quoted-printable-kodning fylder. Gmail klipper beskeder med mere end cirka 102 KB HTML og skjuler resten bag et link. Den klippede del indeholder ofte afmeldingslinket og trackingpixlen.

Hvad er billedvægt?

Billedvægt er den samlede størrelse af de eksterne billeder, der henvises til i <img>-tags, målt ved at hente hvert billede én gang. Tallet er et minimum, fordi billeder fra srcset-attributter og CSS-baggrunde ikke tælles med. En tung besked indlæses langsomt på mobilforbindelser og koster læseren data.

Hvad er overflødig billedvægt?

Overflødig billedvægt er et skøn over de bytes, en afsender sparer ved at levere hvert billede tættere på den størrelse, beskeden viser det i. Et billede op til dobbelt visningsstørrelse tæller som nul overflødig vægt, fordi skærme med høj pixeltæthed bruger de ekstra pixels. Ud over dobbelt visningsstørrelse tilføjer de ekstra pixels bytes uden at tilføje detaljer. Billeder under 1 KB, for eksempel spacere, tælles ikke med.

Hvordan håndterer echo.email billeder?

Analysen henter hvert eksternt billede én gang og registrerer HTTP-status, omdirigeringer, størrelse, indholdstype og dimensioner i pixels. Derefter sammenligner den dimensionerne med den størrelse, der er angivet i HTML-koden. En mailklient henter også billederne, når en læser åbner beskeden, så åbningssporing registrerer en åbning. Billederne hentes fra Cloudflares netværk, og forespørgsler til private eller interne adresser bliver afvist.

Links læses ud af HTML-koden og grupperes efter host, med forespørgselsparametrene afkodet, så de er lettere at læse. echo.email følger aldrig almindelige links, fordi et klik på et link kan bekræfte et abonnement, udløse en handling eller registrere et klik. Den eneste undtagelse er URL’en til afmelding med ét klik, som er beskrevet nedenfor.

Hvad er List-Unsubscribe?

List-Unsubscribe er en header defineret i RFC 2369. Headeren indeholder en eller flere måder at forlade listen på, som en mailto:-adresse, en https:-URL eller begge. Mailudbydere bruger headeren til at vise deres egen afmeldingsknap ved siden af afsenderens navn. Almindelige http-URL’er er forældede, og https er den forventede form.

Hvad er afmelding med ét klik?

RFC 8058 tilføjer en ekstra header, List-Unsubscribe-Post, med den faste værdi List-Unsubscribe=One-Click. Når begge headers findes, sender mailudbyderen en POST-forespørgsel til https-URL’en, og modtageren forlader listen uden at besøge en webside. Google og Yahoo kræver afmelding med ét klik af masseafsendere.

echo.email sender den samme POST-forespørgsel og viser svaret. Enhver 2xx-status tæller som succes. Forespørgslen afmelder kun den midlertidige echo.email-adresse.

Hvad betyder afmelding uden interaktion?

En afmelding uden interaktion gennemføres, uden at modtageren åbner en browser eller bekræfter noget. Afmelding med ét klik efter RFC 8058 er den foretrukne metode. En mailto:-adresse i List-Unsubscribe tæller også med. En afmelding via mail er dog langsommere og giver modtageren ingen bekræftelse, så udbydere bruger mailto som reserveløsning.

Hvorfor er et afmeldingslink i selve beskeden stadig nødvendigt?

Markedsføringslove i de fleste lande forventer en synlig måde at forlade listen på inde i beskeden, typisk et link i sidefoden. Headerne er til mailudbyderen, og linket i sidefoden er til læseren. echo.email leder efter et link med ord om afmelding eller en URL, der ligner en afmeldings-URL. Genkendelsen er en tommelfingerregel og vælger af og til det forkerte link. En separat trackingparameter på linket i sidefoden holder afmeldinger via sidefoden og via headeren adskilt i afsenderens statistik.

Hvad er List-Id?

List-Id (RFC 2919) angiver den mailingliste, en besked hører til, for eksempel News <news.example.com>. Google og Yahoo kræver ikke headeren. Modtagende servere og modtagere bruger headeren til at sortere og filtrere mail efter strøm, så det er god praksis at tilføje den.

Hvad er tjeklisten for god praksis?

Tjeklisten følger de krav, som Google og Yahoo offentliggjorde for masseafsendere i 2024: aligned SPF, aligned DKIM, forward-confirmed reverse DNS, TLS, et From-domæne uden for de gratis mailudbydere og med en DMARC-kontrol, der ikke fejler, en offentliggjort DMARC-politik, mindst én aligned autentificeringsmetode, afmelding med ét klik og et synligt afmeldingslink. Hver række viser ja eller nej. En rød række er en sandsynlig årsag til dårligere placering i indbakken hos de store udbydere, og fuld score er udgangspunktet for massemail.

Nogle rækker tæller kun med, når de er relevante. De to afmeldingsrækker tæller med, når beskeden har en header for massemail: List-Unsubscribe, List-Unsubscribe-Post, List-Id eller Precedence sat til bulk, list eller junk. En personlig besked uden nogen af dem springer rækkerne over. SPF-alignment indgår ikke i scoren, når konvolutafsenderen er omskrevet med SRS, og DMARC består med aligned DKIM. Efter en SRS-omskrivning tjekker SPF domænet for den server, der omskrev, i stedet for From-domænet. Videresendere bruger SRS som en del af deres funktion, og nogle afsendende servere bruger SRS på al udgående mail og opgiver dermed SPF-alignment. Scoren viser antallet af beståede rækker ud af de rækker, der tæller med.

Hvordan bliver beskeden renderet?

Den renderede visning viser HTML-delen i en sandboxet ramme. Browseren står for renderingen, så resultatet svarer til en browser på en computer og ikke til en bestemt mailklient eller enhed. Scripts, formularer og links er slået fra i forhåndsvisningen. Separate visninger viser beskeden med blokerede billeder og med alt-tekst i stedet for hvert billede. Sådan ser mange læsere en besked første gang.

Hvad viser MIME-afsnittet?

MIME er strukturen inde i en besked: delene, deres indholdstyper, tegnsæt, overførselskodninger og de boundaries, der adskiller dem. Et typisk nyhedsbrev har en multipart/alternative-container med en text/plain-del og en text/html-del. En manglende ren tekst-del, en manglende afsluttende boundary eller usædvanlig indlejring springer i øjnene i træet.

Hvad viser payload-afsnittet?

Payload-afsnittet viser den rå besked, som den blev modtaget, med statistik: samlet størrelse, antal linjer, den længste linje, tegn uden for ASCII og linjeskift uden CR. RFC 5322 begrænser en linje til 998 tegn, og nogle servere bryder eller afviser længere linjer. Linjeskift (LF) uden carriage return er en almindelig årsag til DKIM-fejl, fordi servere undervejs omskriver dem.

Visningen af den rå besked starter med de trace-headers, som mx.echo.email registrerer ved levering: Return-Path, Authentication-Results, Received-SPF og Received. Under dem står beskeden præcis, som den blev modtaget, og downloadlinket leverer den uberørte .eml-fil.

Hvilke blokeringslister tjekker rapporten?

Modtagende servere slår den afsendende IP-adresse og afsenderdomænerne op på DNS-blokeringslister, og en notering på en udbredt liste fører til afvist eller filtreret mail. Rapporten tjekker de samme lister som scan.mx: Spamhaus ZEN og AuthBL for IP-adressen, Spamhaus DBL og ZRD for From-domænet og konvolutdomænet samt SpamCop, GBUdb Truncate og PSBL for IPv4-adresser. Hver række viser listet eller ikke listet, med et link til listeoperatørens side for afnotering.

En politiknotering på Spamhaus PBL markerer et adresseområde, der ikke er beregnet til at sende mail direkte, for eksempel en privat internetforbindelse. Mail fra sådan en adresse skal sendes via udbyderens mailserver. Resultaterne gemmes i to timer, så en rettelse vises i en ny test efter højst to timer.

Hvad betyder SpamAssassin-scoren?

SpamAssassin er et open source-spamfilter, som mange modtagende servere bruger. Mailserveren giver hver testbesked en score med SpamAssassin og standardreglerne, der opdateres dagligt. Rapporten viser totalen, spamgrænsen på 5 og hver regel, der ramte, med de højeste point først. Negative point taler til beskedens fordel, for eksempel en gyldig DKIM-signatur.

Netværkstestene slår den afsendende IP-adresse og domænerne i linkene op på Spamhaus (via DQS), URIBL, SURBL og de andre lister i standardreglerne. Bayesiansk læring og de delte hashnetværk Razor, Pyzor og DCC er slået fra. Scoren afhænger derfor kun af beskeden, og intet om beskeden forlader serveren til læring.

Scoren er vejledende og tæller ikke med i scoren for god praksis. Hver modtagende server kører sit eget filter med egne regler og grænser, og Gmail og Outlook bruger slet ikke SpamAssassin. En score over nul er normal. Reglerne med flest point viser, hvor en ændring hjælper mest. Beskeder større end 500 KB får ingen score.

Hvorfor skal afsenderdomænerne have mailservere?

Svar går til From-domænet, og bounces går til domænet for konvolutafsenderen. Begge skal have en MX-post eller i det mindste en adressepost, som mailservere bruger som reserve. En null MX, en enkelt MX, der peger på et punktum (RFC 7505), erklærer, at et domæne slet ikke modtager mail, og nogle modtagende servere afviser beskeder fra sådan et domæne.

Hvilke HTML-elementer tæller som risikable?

Scripts, formularer, iframes, objects og embeds hører sjældent hjemme i e-mail. De fleste mailklienter fjerner dem, og spamfiltre ser dem som et tegn på phishing. Almindelige links og billeder gør det samme arbejde uden straf. Indholdsafsnittet viser også HTML-størrelsen, og hvor meget synlig tekst HTML-koden har, fordi en besked, der næsten kun består af markup eller billeder, virker mistænkelig på filtre.

Hvorfor markere linkforkortere?

Offentlige linkforkortere som bit.ly skjuler den egentlige destination. Phishingkampagner bruger dem meget, så filtre har mistillid til links gennem dem. Links, der peger direkte på afsenderens domæne, opbygger i stedet et godt omdømme.

Hvad viser DNS-afsnittet?

Hver DNS-forespørgsel, der er lavet til rapporten, står i DNS-afsnittet, grupperet efter formål: reverse DNS, SPF, DKIM, DMARC, BIMI, mailservere og IPv6-tjekket. Opslag på blokeringslister er ikke med på listen, fordi deres forespørgselsnavne indeholder en adgangsnøgle. Hver post viser navn, posttype, svarkode, svar med TTL og eventuelle authority-poster. Listen viser, hvilke poster der gav hvert resultat. Det hjælper, når en nylig DNS-ændring endnu ikke har nået alle resolvere.

Flere gratis værktøjer

scan.mx
Tjekker mailopsætningen for et domæne: MX, SPF, DKIM, DMARC, BIMI.
portscan.com
Tjekker, hvilke TCP-porte der er åbne på en IP-adresse, også port 25.