Veelgestelde vragen

echo.email analyseert één e-mail per adres en legt het resultaat uit. De antwoorden hieronder leggen uit hoe de dienst werkt en wat elke controle in het rapport betekent.

Hoe werkt echo.email?

De startpagina maakt een nieuw adres van drie woorden, zoals power.file.tube@echo.email. Een bericht naar dat adres komt aan op de mailserver van echo.email. Die legt het SMTP-gesprek vast en geeft het bericht door aan de analyse. Een paar seconden later toont de pagina een rapport over authenticatie, inhoud, naleving van de regels en bezorging. Je hoeft niets te installeren, en er zijn geen accounts.

Hoe lang blijft het adres geldig?

Het adres blijft actief zolang de pagina open is. De pagina neemt elke twee seconden contact op met de server. Als je de pagina binnen 10 minuten opnieuw laadt, houd je in hetzelfde tabblad hetzelfde adres. Als de pagina langer dan 10 minuten gesloten is, weigert de mailserver nieuwe berichten voor het adres met een permanente fout.

Alleen het eerste bericht dat binnenkomt telt. Latere berichten aan hetzelfde adres worden geweigerd, dus elk rapport hoort bij precies één e-mail. Berichten groter dan 10 MB worden tijdens het SMTP-gesprek geweigerd.

Hoe lang worden rapporten bewaard?

Elk rapport, het opgeslagen bericht en de gegevens van de opgehaalde afbeeldingen worden 24 uur na aankomst van het bericht automatisch verwijderd. Tijdens die 24 uur werkt de link naar het rapport voor iedereen die de link heeft. Daarna werkt de link niet meer. De enige uitzondering is het voorbeeldrapport, want dat komt van een testbericht dat daarvoor is verstuurd.

Wat gebeurt er met de inhoud van het bericht?

echo.email bewaart het hele bericht, dus headers, body en bijlagen, samen met gegevens over de SMTP-sessie, zoals het verzendende IP-adres, de HELO-naam en de TLS-versie. De gegevens blijven in de EU, en de mailserver draait in Falkenstein, Duitsland. Iedereen met de link naar het rapport ziet het volledige bericht, dus test bij voorkeur met inhoud die je kunt delen. Nieuwsbrieven bevatten vaak trackinglinks en een afmeldlink die aan één ontvanger is gekoppeld. Als je een kopie naar een testlijst stuurt, blijven die links privé.

Twee adressen komen rechtstreeks bij de beheerder van de dienst aan: contact@echo.email voor vragen en meldingen van misbruik, en privacy@echo.email voor verzoeken over gegevens. Het privacybeleid bevat alle details.

Wat test de SPF-controle?

SPF somt de servers op die e-mail mogen versturen met een domein in het return path. echo.email neemt het domein van de envelope-afzender (het MAIL FROM-adres, ook wel return path genoemd) en evalueert het SPF-record van dat domein voor het IP-adres van de server die het bericht bezorgt. Alleen een pass telt als goed resultaat. Bij softfail, neutral of none heeft de ontvanger geen SPF-bewijs voor de afzender.

De HELO-naam wordt niet gecontroleerd, net zoals de grote e-mailproviders dat doen als ze SPF voor bulkmail beoordelen. Het rapport toont elk record en elk mechanisme onderweg, zodat je ziet hoe het eindresultaat tot stand komt.

Waarom telt het aantal DNS-lookups?

Een SPF-evaluatie mag hoogstens 10 DNS-lookups doen. De mechanismen include, a, mx, ptr, exists en redirect tellen mee voor die grens, ook als ze in geneste includes staan. Bij overschrijding van de grens wordt het resultaat een permanente fout, en ontvangers behandelen het bericht dan alsof het helemaal geen geldig SPF heeft. Lege lookups, dus lookups die geen record opleveren, hebben een eigen grens van twee. De gebruikelijke oorzaak is een lange keten van includes van derden, en een kortere lijst met diensten lost het probleem op.

Wat bewijst DKIM?

DKIM voegt een cryptografische handtekening toe aan de headers van het bericht. Het ondertekenende domein publiceert de publieke sleutel in DNS onder een selector. echo.email haalt de sleutel op en controleert de handtekening op de headers en de body zoals die zijn aangekomen. Een pass betekent dat de ondertekende delen ongewijzigd zijn aangekomen en dat het ondertekenende domein ervoor instaat.

Het rapport toont het ondertekenende domein (d=), de selector (s=), de ondertekende headers (h=) en het type en de grootte van de sleutel. Een grens voor de lengte van de body (l=) wordt gemarkeerd, omdat iemand daarmee na de handtekening inhoud kan toevoegen.

Wat is DMARC?

DMARC koppelt SPF en DKIM aan het domein van het zichtbare From-adres. Het From-domein publiceert een beleid op _dmarc.<domain> dat ontvangers vertelt wat ze moeten doen met e-mail die de authenticatie niet doorstaat: none, quarantine of reject. Een bericht slaagt voor DMARC als SPF of DKIM slaagt voor een domein dat aligned is met het From-domein.

DMARC voegt zelf geen authenticatie toe. De waarde zit in de eis van alignment en in de geaggregeerde rapporten (rua=) die ontvangers naar de eigenaar van het domein sturen.

Wat betekent aligned?

Alignment vergelijkt een geauthenticeerd domein met het From-domein. Relaxed alignment vraagt hetzelfde organisatiedomein, dus mail.example.com is aligned met example.com. Strikte alignment vraagt precies dezelfde hostnaam. Het organisatiedomein komt uit de Public Suffix List, die weet dat namen zoals example.co.uk als één registreerbaar domein tellen. Als het rapport aligned zegt zonder verdere toelichting, gaat de vergelijking over het From-domein.

Wat is BIMI?

BIMI publiceert een merklogo dat e-mailproviders naast geauthenticeerde berichten tonen. Het record staat op default._bimi.<domain> en verwijst naar een SVG-logo (l=) en, voor de meeste providers, naar een Verified Mark Certificate (a=). BIMI geldt alleen voor domeinen met een afgedwongen DMARC-beleid, dus quarantine of reject op 100 procent. echo.email toont het record en of het DMARC-beleid aan de eis voldoet.

Waarom is reverse DNS belangrijk?

Elk IP-adres dat e-mail verstuurt, heeft een PTR-record nodig dat naar een hostnaam verwijst. Die naam heeft een A- of AAAA-record nodig dat terugverwijst naar hetzelfde IP-adres. Die controle heen en terug heet forward-confirmed reverse DNS, of FCrDNS. De grote e-mailproviders zien FCrDNS als het minimum voor een verzendende server, en e-mail van een IP-adres zonder PTR-record wordt vaak direct geweigerd.

Wat is generieke reverse DNS?

Sommige PTR-records volgen een naamgevingspatroon van de internetprovider, zoals 192-0-2-10.dynamic.example.net. Zulke namen wijzen op een thuisaansluiting of op een server die niemand voor e-mail heeft ingericht, en filters wantrouwen ze. Een eigen naam in het domein van de afzender, zoals mail.example.com, wijst op een mailserver die met opzet is ingericht.

Welke HELO-naam werkt het best?

De verzendende server stelt zich aan het begin van het SMTP-gesprek voor met een HELO- of EHLO-naam. Een goede naam hoort bij de verzendende server, is op te zoeken in DNS en komt overeen met het PTR-record van het verzendende IP-adres. IP-adressen zonder naam, namen zoals localhost en willekeurige tekenreeksen zijn typisch voor malware en snowshoe-spam, en filters wegen dat mee.

Waarom TLS controleren?

Opportunistische TLS versleutelt het SMTP-gesprek als de ontvangende server STARTTLS aanbiedt. echo.email biedt STARTTLS aan bij elke verbinding en legt de TLS-versie en de cipher vast die de afzender kiest. E-mail die zonder TLS wordt verstuurd, gaat als platte tekst tussen de twee servers, en Google en Yahoo eisen TLS van bulkafzenders. Het rapport telt ook links en afbeeldingen die via gewone http laden, want ook die verzoeken gaan onversleuteld.

Waarom IPv6 controleren?

Twee vragen bepalen of een bericht klaar is voor IPv6. De eerste vraag is of de afzender mailservers bereikt die alleen IPv6 gebruiken. Een bericht dat via IPv6 aankomt, beantwoordt die vraag direct met ja. Een bericht dat via IPv4 aankomt, telt toch als geschikt voor IPv6 als de verzendende host een AAAA-record heeft, de reverse DNS van dat IPv6-adres naar dezelfde host verwijst en SPF voor dat adres slaagt. De meeste mailservers kiezen per verbinding tussen IPv4 en IPv6, dus het volgende bericht van dezelfde host komt vaak via IPv6 aan. De tweede vraag is of elke host die afbeeldingen en links in het bericht levert een AAAA-record heeft, zodat een lezer op een netwerk met alleen IPv6 of achter carrier-grade NAT (CGNAT) de inhoud toch laadt. Het rapport markeert het bericht als klaar voor IPv6 als het antwoord op beide vragen ja is.

Hoe wordt de grootte van de e-mail gemeten?

De grootte van de e-mail is het aantal bytes zoals ze zijn verstuurd: alle headers, elk MIME-deel, bijlagen en de extra ruimte door base64- of quoted-printable-codering. Gmail kapt berichten met meer dan ongeveer 102 KB HTML af en verbergt de rest achter een link. Het afgekapte deel bevat vaak de afmeldlink en de trackingpixel.

Wat is het gewicht van de afbeeldingen?

Het gewicht van de afbeeldingen is de totale grootte van de externe afbeeldingen in <img>-tags, gemeten door elke afbeelding één keer op te halen. Het getal is een minimum, want afbeeldingen uit srcset-attributen en CSS-achtergronden tellen niet mee. Een zwaar bericht laadt traag op mobiele verbindingen en kost de lezer data.

Wat is het overgewicht van de afbeeldingen?

Het overgewicht schat hoeveel bytes een afzender zou besparen door elke afbeelding dichter bij het formaat te leveren waarop het bericht de afbeelding toont. Een afbeelding tot twee keer de weergavegrootte telt als nul overgewicht, want schermen met een hoge pixeldichtheid gebruiken de extra pixels. Boven twee keer de weergavegrootte voegen extra pixels bytes toe zonder extra detail. Afbeeldingen kleiner dan 1 KB, zoals spacers, tellen niet mee.

Hoe gaat echo.email om met afbeeldingen?

De analyse haalt elke externe afbeelding één keer op en legt de HTTP-status, doorverwijzingen, grootte, het contenttype en de afmetingen in pixels vast. Daarna vergelijkt de analyse die afmetingen met de grootte die in de HTML staat. Een afbeelding ophalen is wat een e-mailprogramma doet als een lezer het bericht opent, dus open-tracking registreert een opening. De downloads komen uit het netwerk van Cloudflare, en verzoeken naar privé- of interne adressen worden geweigerd.

Links worden uit de HTML verzameld en per host gegroepeerd, met gedecodeerde queryparameters zodat ze leesbaar zijn. echo.email volgt nooit gewone links, want een link volgen kan een inschrijving bevestigen, een actie starten of een klik registreren. De enige uitzondering is de URL voor afmelden met één klik, die hieronder staat beschreven.

Wat is List-Unsubscribe?

List-Unsubscribe is een header uit RFC 2369. De header bevat een of meer manieren om je af te melden, zoals een mailto:-adres, een https:-URL of allebei. E-mailproviders gebruiken de header om een eigen afmeldknop naast de naam van de afzender te tonen. URL’s met gewone http zijn verouderd, en https is de verwachte keuze.

Wat is afmelden met één klik?

RFC 8058 voegt een tweede header toe, List-Unsubscribe-Post, met de vaste waarde List-Unsubscribe=One-Click. Als beide headers aanwezig zijn, stuurt de e-mailprovider een POST-verzoek naar de https-URL, en de ontvanger is afgemeld zonder een pagina te bezoeken. Google en Yahoo eisen afmelden met één klik van bulkafzenders.

echo.email stuurt hetzelfde POST-verzoek en toont het antwoord. Elke 2xx-status telt als geslaagd. Met het verzoek wordt alleen het tijdelijke echo.email-adres afgemeld.

Wat betekent afmelden zonder interactie?

Afmelden zonder interactie lukt zonder dat de ontvanger een browser opent of iets bevestigt. One-click volgens RFC 8058 is de voorkeursmethode. Een mailto:-adres in List-Unsubscribe telt ook, maar afmelden per e-mail is trager en geeft de ontvanger geen bevestiging, dus providers zien mailto als reserveoptie.

Waarom is er toch een afmeldlink in het bericht nodig?

De marketingwetten van de meeste landen eisen een zichtbare manier om je af te melden in het bericht zelf, meestal een link in de footer. De headers zijn er voor de e-mailprovider, en de link in de footer is er voor de lezer. echo.email zoekt een link met afmeldtekst of een URL die op een afmeldlink lijkt. Die herkenning is een heuristiek en kiest soms de verkeerde link. Een eigen trackingparameter op de link in de footer maakt in de statistieken van de afzender het verschil zichtbaar tussen afmeldingen via de footer en via de header.

Wat is List-Id?

List-Id (RFC 2919) geeft een naam aan de mailinglijst waar een bericht bij hoort, bijvoorbeeld News <news.example.com>. Google en Yahoo eisen de header niet. Ontvangende servers en ontvangers gebruiken de header om e-mail per verzendstroom te sorteren en te filteren, dus de header toevoegen is goede praktijk.

Wat is de lijst met goede praktijk?

De lijst volgt de eisen die Google en Yahoo in 2024 voor bulkafzenders hebben gepubliceerd: SPF aligned, DKIM aligned, forward-confirmed reverse DNS (FCrDNS), TLS, een From-domein dat geen gratis e-maildienst is en dat niet faalt voor DMARC, een gepubliceerd DMARC-beleid, minstens één aligned authenticatiemethode, afmelden met één klik en een zichtbare afmeldlink. Elke regel zegt ja of nee. Een rode regel is een waarschijnlijke oorzaak van een slechtere plek in de inbox bij de grote providers, en de volle score is de basis voor bulkmail.

Sommige regels tellen alleen als ze van toepassing zijn. De twee afmeldregels tellen als het bericht een bulkheader heeft: List-Unsubscribe, List-Unsubscribe-Post, List-Id of Precedence met de waarde bulk, list of junk. Bij een persoonlijk bericht zonder een van die headers tellen die regels niet mee. SPF-alignment telt niet mee als de envelope-afzender met SRS is herschreven en DMARC slaagt met aligned DKIM. Na een SRS-herschrijving controleert SPF het domein van de server die het adres herschreef, in plaats van het From-domein. Doorstuurdiensten gebruiken standaard SRS, en sommige verzendende servers passen SRS toe op alle uitgaande e-mail, waardoor de SPF-alignment verdwijnt. De score toont hoeveel van de meegetelde regels in orde zijn.

Hoe wordt het bericht weergegeven?

De weergave toont het HTML-deel in een afgeschermd kader (sandbox). Je browser doet de weergave, dus het resultaat komt overeen met een desktopbrowser en niet met een bepaald e-mailprogramma of apparaat. Scripts, formulieren en links zijn in het voorbeeld uitgeschakeld. Andere weergaven tonen het bericht met geblokkeerde afbeeldingen en met de alt-tekst op de plek van elke afbeelding. Zo zien veel lezers een bericht de eerste keer.

Wat toont het MIME-onderdeel?

MIME is de interne opbouw van een bericht: de delen, contenttypes, tekensets, transfer-encodings en de grenzen die de delen scheiden. Een gewone nieuwsbrief heeft een multipart/alternative-container met een text/plain-deel en een text/html-deel. Een ontbrekend tekstdeel, een ontbrekende afsluitende grens of een ongewone nesting valt op in de boomstructuur.

Wat toont het onderdeel Ruw bericht?

Het onderdeel Ruw bericht toont het bericht zoals het is ontvangen, met statistieken: totale grootte, aantal regels, de langste regel, niet-ASCII-tekens en regeleinden zonder CR. RFC 5322 beperkt een regel tot 998 tekens, en sommige servers breken langere regels af of weigeren ze. Regeleinden zonder carriage return (CR) zijn een veelvoorkomende oorzaak van DKIM-fouten, omdat servers onderweg ze herschrijven.

De weergave van het ruwe bericht begint met de trace-headers die mx.echo.email bij de bezorging vastlegt: Return-Path, Authentication-Results, Received-SPF en Received. Daaronder staat het bericht precies zoals het is ontvangen, en de downloadlink levert het ongewijzigde .eml-bestand.

Welke blocklists controleert het rapport?

Ontvangers zoeken het verzendende IP-adres en de afzenderdomeinen op in DNS-blocklists, en een vermelding op een veelgebruikte lijst leidt tot geweigerde of gefilterde e-mail. Het rapport controleert dezelfde lijsten als scan.mx: Spamhaus ZEN en AuthBL voor het IP-adres, Spamhaus DBL en ZRD voor het From-domein en het envelope-domein, plus SpamCop, GBUdb Truncate en PSBL voor IPv4-adressen. Elke regel zegt vermeld of niet vermeld, met een link naar de verwijderpagina van de beheerder van de lijst.

Een vermelding op basis van beleid in de Spamhaus PBL markeert een adresbereik dat niet rechtstreeks e-mail hoort te versturen, zoals een thuisaansluiting. E-mail van zo’n adres hoort via de mailserver van de provider te gaan. De resultaten blijven twee uur in de cache, dus een correctie verschijnt in een nieuwe test binnen hoogstens twee uur.

Wat betekent de SpamAssassin-score?

SpamAssassin is een opensource-spamfilter dat veel ontvangende servers gebruiken. De mailserver geeft elk testbericht een score met SpamAssassin en de standaardregels, die dagelijks worden bijgewerkt. Het rapport toont het totaal, de spamgrens van 5 en elke regel die raak was, met de regels met de meeste punten bovenaan. Negatieve punten tellen in het voordeel van het bericht, bijvoorbeeld bij een geldige DKIM-handtekening.

De netwerktests zoeken het verzendende IP-adres en de linkdomeinen op bij Spamhaus (via DQS), URIBL, SURBL en de andere lijsten in de standaardregels. Bayesiaans leren en de gedeelde hashnetwerken Razor, Pyzor en DCC staan uit, dus de score hangt alleen van het bericht af, en er gaat niets over het bericht naar buiten om van te leren.

De score is een indicatie en telt niet mee in de score voor goede praktijk. Elke ontvanger gebruikt een eigen filter met eigen regels en grenzen, en Gmail en Outlook gebruiken SpamAssassin niet. Een score boven nul is normaal. De regels met de meeste punten laten zien waar een aanpassing het meest helpt. Berichten groter dan 500 KB krijgen geen score.

Waarom hebben afzenderdomeinen mailservers nodig?

Antwoorden gaan naar het From-domein, en bounces gaan naar het domein van de envelope-afzender. Beide hebben een MX-record nodig, of in elk geval een adresrecord, waar mailservers op terugvallen. Een null MX, dus één MX die naar een punt verwijst (RFC 7505), verklaart dat een domein geen e-mail aanneemt, en sommige ontvangers weigeren berichten van zo’n domein.

Welke HTML-elementen tellen als riskant?

Scripts, formulieren, iframes, objects en embeds zijn zelden nodig in een e-mail. De meeste e-mailprogramma’s halen ze weg, en spamfilters zien ze als teken van phishing. Gewone links en afbeeldingen doen hetzelfde werk zonder die straf. Het inhoudsonderdeel toont ook de grootte van de HTML en hoeveel zichtbare tekst de HTML bevat, want een bericht dat bijna alleen uit opmaak of afbeeldingen bestaat, lijkt verdacht voor filters.

Waarom linkverkorters markeren?

Openbare linkverkorters zoals bit.ly verbergen de echte bestemming. Phishingcampagnes gebruiken ze veel, dus filters wantrouwen links die erdoorheen gaan. Links die direct naar het domein van de afzender wijzen, bouwen reputatie op.

Wat toont het DNS-onderdeel?

Elke DNS-lookup voor het rapport staat in het DNS-onderdeel, gegroepeerd per doel: reverse DNS, SPF, DKIM, DMARC, BIMI, mailservers en de IPv6-controle. Lookups bij blocklists staan er niet bij, omdat de namen van die lookups een toegangssleutel bevatten. Elke regel toont de naam, het recordtype, de antwoordcode, de antwoorden met hun TTL en eventuele authority-records. De lijst laat zien welke records elk resultaat opleverden. Dat helpt als een recente DNS-wijziging nog niet bij alle resolvers is aangekomen.

Meer gratis tools

scan.mx
Controleert de e-mailinstellingen van een domein: MX, SPF, DKIM, DMARC, BIMI.
portscan.com
Controleert welke TCP-poorten open staan op een IP-adres, inclusief poort 25.