Poznaj nas
Pomoc
Obsługa klienta
Formularz kontaktowy
Tel: +48 695 742 350
E-mail: biuro@roan24.pl
w dni robocze pon.-pt.
w godz. 7:00-21:00
© 2023 ROAN Agencja Interaktywna Maria Łukin w spadku. Korzystając z tej strony, zgadzasz się z naszą polityką cookies.
Formularz kontaktu
Tel: +48 695 742 350
E-mail: biuro@roan24.pl
w dni robocze pon.-pt.
w godz. 7:00-21:00
© 2023 ROAN Agencja Interaktywna Maria Łukin. Korzystanie z serwisu oznacza akceptację polityki cookies.
Należy pamiętać, że korzystając z witryny bez zmiany ustawień przeglądarki, użytkownik wyraża zgodę na politykę prywatności i przechowywanie plików cookie, które umożliwiają sprawne działanie naszej witryny.
DKIM probleem
Vandaag deed zich een interessante situatie voor toen een van onze werknemers geen contact kon krijgen met een extern bedrijf. Hij deelde me mee dat hij geen e-mail kreeg van een domein, laten we aannemen dat het domein.com was, hoewel zijn berichten wel doorkwamen, kreeg de andere partij geen retourberichten met vermelding van de reden voor de weigering van de e-mail. Hij vroeg mij het probleem te controleren, ik zal kort uiteenzetten hoe ik te werk ben gegaan en wat de oorzaak was.
Nieuws diagnostiek – Exim
Aangezien we exim gebruiken als onze MTA, zullen de commando’s hier specifiek zijn voor dat systeem, maar het proces kan gemakkelijk ook in postfix gebruikt worden.
Het eerste stukje informatie is dat, indien berichten niet worden teruggestuurd naar de afzender, dit betekent dat zij ergens zijn blijven steken, dat zij een tijdelijke fout hebben opgelopen en dat een van de servers zal proberen ze opnieuw af te leveren. Dit is een standaard actie en er is hier niets vreemds aan mensen die ons artikel hebben gelezen hoe de post werkt zullen dit weten. En de belangrijke informatie is dat de berichten werden verzonden vanaf domain.com.
Als berichten ergens blijven steken, controleren wij onze wachtrij van af te leveren berichten om te zien of zij bij ons blijven steken of ons zelfs niet hebben bereikt:
Dat wil zeggen dat het bericht al 66 minuten in onze wachtrij staat en niet kan worden afgeleverd, wat misschien een beetje verwonderlijk is dat het bericht op onze server staat en toch de geadresseerde niet heeft bereikt, maar daar zullen we het te zijner tijd over hebben. De volgende test is het controleren van de logs met het handige commando exigrep, dat zoekt naar berichten op basis van gegeven gegevens, b.v. een domein, en alle informatie weergeeft over wat ermee gebeurd is. Een eenvoudige grep zou er in deze situatie toe leiden dat we niet alle informatie hebben.
Dat wil zeggen, we hebben de reden, het bericht is niet afgeleverd omdat het de DKIM entry niet kan vinden in de DNS zone, en het bericht zelf is ondertekend en zou gecontroleerd moeten worden of het van een echte bron komt, dus voor de zekerheid controleren we of zo’n entry bestaat, want het zou een probleem kunnen zijn met onze lokale DNS server. We zullen de publieke DNS server van Google gebruiken om te controleren:
Dus we hebben de reden, de txt entry voor het domein zendesk1._domainkey.domain.com bestaat niet en daar gaat onze server op zoek naar de DKIM sleutel waarmee hij de handtekening kan controleren. Ten eerste, waarom zendesk1._domainkey.domain.com? Nou, eerder in het log hadden we DKIM gegevens gegeven: „d=domain.com s=zendesk1 c=relaxed/relaxed a=rsa-sha256 t=1431354869″ zoals je kunt zien is de entry s= eigenlijk zendesk1 en s staat voor selector. Het vertelt ons onder welk domein we moeten zoeken naar de DKIM invoer, in dit geval zendesk1._domainkey.domain.com, volgens het patroon: value s._domainkey.value d, waarbij d het domein is. Als daar geen txt-vermelding staat, betekent dit dat er een tijdelijk probleem is met de DNS-server of dat iemand het daar niet heeft ingevoerd, zoals het geval was met dit domein.
De dig query zelf leverde nog een stukje informatie op, namelijk dat de DNS-servers worden onderhouden bij Cloudflare. Dit is een bedrijf waarmee wij hebben samengewerkt en wij zullen er zeker meer over schrijven. Cloudflare fungeert als een proxy voor de webserver, maar hiervoor moet u ook uw eigen DNS-server opgeven, wat betekent dit? Wel, die iemand heeft gewoon de DKIM sleutel niet ingevoerd in de DNS zone, zodat onze server niet kon controleren of het bericht correct ondertekend is, en wachtte met afleveren tot iemand een DNS entry toevoegde of de DNS server begon te reageren, maar dit gebeurde pas 6 uur nadat het bericht op onze server was aangekomen en het automatisch werd teruggestuurd naar de afzender als onbestelbaar wegens een DKIM fout. Ik heb uiteraard de andere partij op de hoogte gebracht van het probleem en wij wachten nu tot zij het oplossen.
Een goed hulpmiddel om de juiste e-mailconfiguratie te controleren is de website , stuur gewoon een e-mail naar het opgegeven adres en klik op de knop en u krijgt een volledig rapport. E-mails verstuurd vanaf onze domeinen krijgen 10/10 punten.
Bonus – Wat is de DKIM selector?
Een selector is niets meer dan informatie over met welke DKIM sleutel het bericht is ondertekend, en waar deze sleutel gezocht moet worden. Het werd ingevoerd om beheerders de mogelijkheid te geven meerdere sleutels voor één domein in te voeren, zodat oude of gecompromitteerde sleutels gemakkelijk kunnen worden ingetrokken, of u hoeft de sleutel niet in het oog te houden omdat hij zoekraakt, u kunt snel de selector wijzigen en beginnen te ondertekenen met de nieuwe sleutel, of zelfs helemaal niet wijzigen maar onmiddellijk beginnen te ondertekenen met de nieuwe sleutel, maar dit betekent wel dat berichten die tijdens de wijziging worden verzonden, kunnen worden teruggezonden vanwege de verkeerde sleutel.