DKIM fail: oorzaken onderzoeken en fouten herstellen

DKIM fail is een concrete verificatiefout, geen vrijblijvende waarschuwing. De ontvanger kon een DKIM-handtekening niet valideren. Dat is niet automatisch een oordeel over de betrouwbaarheid van de hele boodschap, maar het kan de filtering en aflevering beïnvloeden. Voor de rest van uw configuratie helpt onze gids voor zakelijke e-mail: SPF, DKIM, DMARC, routering en postvakken moeten samen kloppen.

Bij u lijkt het bericht normaal, maar Gmail, Microsoft of Yahoo rapporteert dkim=fail. Afhankelijk van ander authenticatiebewijs en het ontvangstbeleid kan mail in spam belanden, tijdelijk worden beperkt of worden geweigerd. Dat kan leiden tot minder respons en supportvragen. De oorzaak kan in DNS, de verzender of een systeem liggen dat onderweg berichten aanpast.

Werk daarom als bij een incident: lees het authenticatieresultaat, bepaal het fouttype, controleer selector en sleutel en onderzoek wat de boodschap na het ondertekenen heeft gewijzigd. Herstel daarna de vastgestelde oorzaak.

Wat betekent dkim fail precies?

DKIM fail betekent dat de ontvanger de cryptografische handtekening niet kon valideren. Mogelijke oorzaken zijn gewijzigde ondertekende inhoud of een niet-passende sleutel. Een ontbrekende DNS-sleutel of mislukte query kan ook een permanent of tijdelijk foutresultaat geven; onderscheid die van een mislukte verificatie.

DKIM kent volgens RFC 6376 de bodyhash in bh= en de handtekening over de berichtkoppen in b=. Een mismatch kan verificatie laten mislukken. Dat bewijst niet dat er sprake is van spoofing: te vroeg ondertekenen, een verkeerde sleutel of wijzigingen door een volgende hop zijn ook mogelijke oorzaken.

Vergelijk DKIM met een verzegeling op een pakket. Een afwijkend zegel betekent dat de controle niet slaagt, maar verklaart op zichzelf nog niet wie de wijziging heeft gemaakt of of de inhoud onbetrouwbaar is.

Begin bij de berichtkop Authentication-Results van de mislukte boodschap. Die vermeldt het resultaat en kan helpen het fouttype te bepalen. Het volgende voorbeeld combineert echter resultaten die bij normale uitgelijnde SPF niet zo verwacht worden: geslaagde SPF voor hetzelfde From-domein zou doorgaans DMARC laten slagen, ook bij mislukte DKIM. Gebruik het voorbeeld niet als voorspelling.

Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
  spf=pass smtp.mailfrom=example.com;
  dmarc=fail header.from=example.com

Wilt u eerst de domeinrecords controleren, vergelijk ze dan met TrekMail's vereiste DNS-records.

Veelvoorkomende typen DKIM-problemen

Een nuttige indeling is: afwijkende bodyhash, verkeerde selector of sleutel, ongeldig of afgekapt DNS-record en wijzigingen door doorsturen of relays. Een juiste classificatie voorkomt dat u sleutels vervangt terwijl het probleem elders zit.

De tabel helpt bij triage. Onderzoek vervolgens welke oorzaak daadwerkelijk aanwezig is.

Fouttype 1: afwijkende bodyhash

Bij een bodyhash-mismatch verschilt de ontvangen ondertekende body na canonicalisatie van de body waarop de hash is berekend. Het gaat niet om een eenvoudige byte-voor-bytevergelijking van de hele boodschap. Daaruit kunt u ook niet afleiden dat DNS correct is.

Volgens RFC 6376 leidt een opnieuw berekende bodyhash die niet overeenkomt met bh= tot een permanente verificatiefout. Onderzoek wijzigingen in het ondertekende deel en de berekening of verwerking aan beide kanten.

Mogelijke oorzaken:

• Microsoft 365, Exchange of beveiligingsgateways voegen na ondertekening een juridische disclaimer toe.
• Mimecast, Barracuda, Proofpoint of vergelijkbare filters herschrijven links.
• Een relay wijzigt witruimte of regeleinden op een manier die niet door de gekozen canonicalisatie wordt geneutraliseerd.
• Een app ondertekent voordat een gateway MIME-grenzen aanpast of banners zoals [External] toevoegt.

Controleer c= in de handtekening. Met c=simple/simple bent u gevoeliger voor bepaalde opmaakwijzigingen. Relaxed bodycanonicalisatie uit RFC 6376 negeert onder meer witruimte aan regeleinden en reduceert herhaalde witruimte binnen regels. Ze herstelt geen inhoudelijke wijzigingen, zoals toegevoegde tekst of herschreven links.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=tm1; h=from:to:subject:date:mime-version;
 bh=...; b=...

Onderteken bij voorkeur na alle door u beheerde wijzigingen aan voetteksten, links, routering en compliance-inhoud. De laatste beheerde uitgaande hop is vaak geschikt. Dat voorkomt geen wijzigingen door externe systemen verderop.

Gebruikt u doorsturen, lees dan e-mail doorsturen en domeinmail doorsturen naar Gmail. Een extra hop kan authenticatie anders laten uitpakken dan in een directe test.

Fouttype 2: verkeerde selector of sleutel

Een probleem ontstaat als de boodschap selector X gebruikt, maar DNS daarvoor geen bruikbare sleutel bevat of een sleutel die niet bij de gebruikte privésleutel hoort. Het ontbrekende record kan een permanent foutresultaat geven; een niet-passende sleutel kan verificatie laten mislukken.

Zoek de selector en het domein in de handtekening:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...

Vraag precies die selector op:

dig txt k1._domainkey.example.com +short

Een leeg antwoord kan op een ontbrekend of verkeerd geplaatst record wijzen, maar ook op caches of andere queryproblemen. Bekijk de volledige respons. Is er een record, vergelijk het dan met de sleutel van de actieve verzender. Bij migraties of verschillende verzendplatforms kan één systeem al een nieuwe sleutel gebruiken terwijl een ander nog met de oude ondertekent.

Dat komt bijvoorbeeld voor bij appmail via SES, supportmail via Microsoft 365 en campagnes via een andere ESP. Een DNS-wijziging kan dan slechts een deel van het verkeer raken. Gebruik waar passend aparte selectors per verzender.

Voor de beheerde verzendroute van TrekMail volgt u Beheerde TrekMail SMTP en controleert u de plaats van ondertekening. Voor Nano of een externe verzender raadpleegt u eigen SMTP (BYO): TrekMail is dan de client en de daadwerkelijk ingestelde verzender moet DKIM verzorgen.

Fouttype 3: lange sleutels verkeerd gepubliceerd

Een sleutel van 2048 bits kan verkeerd in DNS terechtkomen als het invoerpaneel de TXT-waarde niet goed verwerkt. Dat kan permerror, een formaatschending of een onvolledige sleutel opleveren.

RFC 8301 vereist RSA-sleutels van minimaal 1024 bits en beveelt minimaal 2048 bits aan. Controleer daarnaast of het DNS-paneel lange TXT-waarden correct opslaat.

Afgekapt of verkeerd aangehaald sleutelmateriaal kan fouten veroorzaken, ook als de privésleutel op de verzender correct is. Het onderstaande patroon is illustratief: gebruik de volledige echte sleutel, verdeeld over tekenreeksen binnen hetzelfde TXT-record.

; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
  "restOfThePublicKeyContinuesHere..."
)

Vraag het record op en bekijk alle delen van de respons:

dig txt k1._domainkey.example.com +short

Controleer dit vooral na een DNS-providerwissel, zoneverplaatsing of handmatig kopiëren. De toepassing voegt de tekenreeksen van hetzelfde record zonder extra spaties samen.

Fouttype 4: doorsturen, relays en ontbrekende uitlijning

Doorsturen kan DKIM verstoren wanneer een tussensysteem ondertekende gegevens wijzigt. SPF voor de oorspronkelijke verzender kan tegelijkertijd mislukken. DMARC faalt dan alleen als er geen andere geslaagde, uitgelijnde authenticatie beschikbaar is; afwijzing hangt af van het ontvangende beleid.

U stuurt bijvoorbeeld mail van example.com naar een universiteit, die haar doorstuurt naar Gmail. SPF kan mislukken omdat de doorstuurserver niet de oorspronkelijke verzender is. DKIM kan geldig blijven zolang de ondertekende gegevens voldoende intact blijven. Een nieuwe voettekst, herschreven link of gewijzigd ondertekend onderwerp kan DKIM verstoren. Zonder andere uitgelijnde authenticatie kan DMARC dan falen.

Google vraagt van algemene verzenders naar persoonlijke Gmail-accounts SPF of DKIM; voor bulkverzenders gelden SPF én DKIM plus DMARC en de bijbehorende uitlijning. Voor doorsturen en mailinglijsten wordt ook ARC aanbevolen waar van toepassing. Of een ontvanger ARC vertrouwt en gebruikt, is diens beslissing. Een DKIM-fout onderweg is dus niet vanzelf bewijs dat de basisconfiguratie verkeerd is.

SRS en zorgvuldige routering kunnen helpen bij doorsturen. Controleer de beschikbare SRS-functionaliteit in uw TrekMail-configuratie. SRS herschrijft de envelopafzender en kan SPF voor die nieuwe afzender laten slagen, maar maakt haar niet automatisch uitgelijnd met het oorspronkelijke From-domein. Het vervangt DKIM niet.

Bij veel aliassen zijn ook doorsturen met een e-mailalias en e-mail met uw eigen domein maken nuttig. Onderzoek de werkelijke doorstuurroute in plaats van alleen de aliasinstellingen.

Waar begint u het onderzoek naar dkim fail?

Volg een vaste volgorde: authenticatieresultaat, selectorquery, ondertekeningsroute en uitlijning. Daarmee voorkomt u onnodige DNS-wijzigingen wanneer de echte oorzaak een latere berichtwijziging is.

1. Open de oorspronkelijke boodschap en zoek Authentication-Results. Noteer het exacte DKIM-resultaat.
2. Zoek d=, s= en c= in de berichtkop DKIM-Signature.
3. Vraag de selector op met dig. Controleer de hostnaam selector._domainkey.example.com.
4. Stel vast welk platform werkelijk ondertekent. Verschillende platforms kunnen wisselende resultaten verklaren.
5. Controleer wijzigingen aan body of ondertekende koppen door gateways, filters en doorstuurservers.
6. Controleer de uitlijning van d= met het zichtbare From:-domein om DKIM aan DMARC te laten bijdragen.

Losse fragmenten in een externe checker kunnen onjuiste bodyhash-fouten geven doordat de boodschap niet volledig is. Onderzoek de volledige bron of een geëxporteerd bestand .eml.

Een samenhangende aanpak met TrekMail

Losse DNS-ingrepen en onderzoek naar relays en voetteksten bij verschillende leveranciers maken de oorzaak moeilijk zichtbaar. Plaats ondertekening na de laatste beheerde wijziging, controleer DNS en houd beheerde verzending bewust gescheiden van eigen SMTP.

Volgens de hier beschreven opzet gebruikt het gratis Nano eigen SMTP. Betaalde abonnementen beginnen bij $3.50 per maand en omvatten beheerde SMTP; controleer actuele prijzen en mogelijkheden. Wilt u TrekMail laten ondertekenen, kies de ondersteunde beheerde route. Wilt u SES, SendGrid of Mailgun gebruiken, onderzoek dan DKIM bij die verzender. Voor betaalde abonnementen kan een proefperiode van 14 dagen gelden waarvoor een creditcard nodig is. Bekijk de voorwaarden bij TrekMail-prijzen.

Dat onderscheid helpt het onderzoek af te bakenen. Bij eigen SMTP controleert u selector, sleutel en berichtwijzigingen op de externe verzendroute; neem niet zonder bewijs aan dat het postvak zelf de oorzaak is.

Laatste checklist voor een DKIM-incident

Behandel DKIM fail als een specifieke verificatiefout. Lees het resultaat, test de selector en onderzoek de ondertekeningsroute voordat u configuratie wijzigt. Dat maakt herstel gerichter.

Controleer vóór een productiewijziging:

• Lees de volledige authenticatiekop, niet alleen een samenvatting van een bounce.
• Onderscheid een bodyhash-fout, handtekeningfout, permerror en temperror.
• Vraag de exacte selector op in DNS.
• Controleer of de sleutel volledig en correct aangehaald is.
• Verplaats ondertekening na de laatste beheerde wijziging indien nodig.
• Overweeg c=relaxed/relaxed als uw omgeving dat ondersteunt; inhoudelijke wijzigingen blijven een probleem.
• Controleer DMARC-uitlijning tussen d= en het zichtbare From:-domein.

Blijft dkim fail terugkomen, verzamel dan bewijs in plaats van alleen af te wachten. Onderzoek ondertekening, selector, sleutel en latere wijzigingen en herstel de aangetoonde oorzaak.