De route van onder naar boven lezen
Elke server die een bericht verwerkt, voegt boven de bestaande regels een Received-regel toe. De oudste hop staat dus onderaan en de laatste, je eigen mailboxprovider, bovenaan. De analyzer zet ze in een lijst in de volgorde waarin het bericht is verzonden, met het tijdstip waarop elke server zegt het te hebben ontvangen en het tijdsverschil met de vorige hop.
Een verschil van enkele seconden is normaal. Minuten betekenen meestal dat het bericht in een wachtrij stond, omdat een ontvangende server om een nieuwe poging wegens greylisting vroeg, een relay bezet was of het uitgaande filter van de afzender het bericht tegenhield. Loopt de klok achteruit? Dan staat de tijd op een van de servers verkeerd.
Welke Authentication-Results je kunt vertrouwen
In Authentication-Results (RFC 8601) noteert een ontvangende server de resultaten voor SPF, DKIM, DMARC en soms ARC. Een bericht kan meerdere van deze regels bevatten, maar alleen de regel die is toegevoegd door de server die het bericht bij je heeft afgeleverd, telt. Alles daaronder is geschreven voordat je provider het bericht ontving, door servers die je niet hoeft te vertrouwen. Een afzender kan daar bovendien alles neerzetten.
De analyzer gebruikt het bovenste resultaat als eindoordeel en vermeldt de overige resultaten apart. Daarnaast zie je de drie domeinen die de uitlijning bepalen: het From-domein, het DKIM d=-domein en het Return-Path-domein waartegen SPF is gecontroleerd. DMARC slaagt alleen als SPF of DKIM slaagt voor een domein dat overeenkomt met het From-domein. Door deze domeinen te vergelijken, kun je vaak verklaren waarom de controle mislukt.
Waar vind je de e-mailheaders?
Open in Gmail het bericht, klik op de drie puntjes naast Beantwoorden en kies Origineel weergeven. Open in Outlook op het web het bericht, kies Meer acties en vervolgens Weergeven en Berichtdetails weergeven. In de Outlook-desktopapp ga je naar Bestand, vervolgens Eigenschappen en het vak Internetheaders. In Apple Mail kies je Weergave, Bericht, Alle headers. Kopieer alles tot aan de eerste lege regel, waar de berichttekst begint. Als je het volledige bericht plakt, wordt de berichttekst vóór de analyse verwijderd.
Headers bevatten IP-adressen en e-mailadressen. Ze worden in het geheugen gelezen om het resultaat op te bouwen en worden niet opgeslagen, gecachet of gelogd.
Vragen
Hoe lees je e-mailheaders?
Begin bij de onderste Received-regel en werk omhoog. Dat is de volgorde waarin de servers het bericht hebben verwerkt. Bekijk daarna de bovenste Authentication-Results-regel die je eigen provider heeft toegevoegd voor de resultaten van SPF, DKIM en DMARC.
Waarom slaagt DKIM, maar mislukt DMARC?
Voor DMARC is een geldige DKIM-handtekening nodig waarvan het d=-domein overeenkomt met het From-domein, of een geslaagde SPF-controle voor een Return-Path-domein dat daarmee overeenkomt. Een handtekening van het eigen domein van je verzendplatform kan slagen voor DKIM, maar telt dan nog steeds niet mee voor DMARC. De analyzer toont de drie domeinen naast elkaar, zodat het verschil zichtbaar is.
Volledige handleiding: DMARC fail
Wat betekent een lange vertraging tussen twee hops?
Het bericht heeft gewacht op de server waar de vertraging begint. Veelvoorkomende oorzaken zijn greylisting, waarbij de ontvanger de afzender vraagt het later opnieuw te proberen, een volle uitgaande wachtrij of een filter dat e-mail scant voordat deze wordt doorgestuurd. Eén vertraging van enkele minuten is zelden een afleverbaarheidsprobleem. Het verklaart wel waarom een bericht te laat aankwam.
Kunnen e-mailheaders worden vervalst?
Alles wat een afzender schrijft, kan worden vervalst. Received-regels onder de regels van je eigen provider en oude Authentication-Results-regels kunnen verzonnen zijn. Wat je provider bovenaan heeft toegevoegd, kan niet worden vervalst. Je provider kan bovendien de DKIM-handtekening controleren aan de hand van de openbare sleutel van de afzender. De analyzer verifieert handtekeningen niet zelf, maar leest het oordeel van je provider uit de bovenste regel.
Wat is ARC in e-mailheaders?
Met ARC (RFC 8617) kan een doorstuurservice, zoals een mailinglijst of doorstuuradres, de authenticatieresultaten vastleggen die de service zag voordat het bericht werd gewijzigd. De uiteindelijke ontvanger kan vervolgens besluiten die vastlegging te vertrouwen wanneer SPF of DKIM door het doorsturen niet meer slaagt.
Kan ik een bericht testen voordat ik het verstuur?
Ja. Headers bestaan pas nadat een bericht ergens is afgeleverd. Als je een campagne of transactionele e-mail wilt controleren voordat iemand deze ontvangt, stuur je het bericht naar een testadres op de homepage. Je krijgt deze resultaten plus blacklists, inhoud, links en de regels voor bulkverzenders in één rapport.