Hoe controleer je DKIM voor applicatiemail?

Behandel een DKIM-controle als vier afzonderlijke tests

Een DNS-lookup alleen is geen volledige DKIM-controle. Controleer eerst of het bericht een DKIM-Signature-veld bevat en bepaal welke handtekening je wilt testen. Haal vervolgens het record met de publieke sleutel op dat die handtekening noemt en parse het. Verifieer daarna of de ondertekende headers en de gecanonicaliseerde body nog overeenkomen met de cryptografische handtekening. Bepaal tot slot of een geslaagd ondertekenend domein voor DMARC gealigned is met het zichtbare From-domein. Deze lagen beantwoorden verschillende vragen. Een gepubliceerd record kan ongebruikt zijn, een bericht kan verwijzen naar een ontbrekende selector, een handtekening kan falen nadat de content is gewijzigd, en een cryptografische pass kan niet gealigned zijn met het auteursdomein. Leg elke uitkomst vast in plaats van één groen vinkje te tonen. Houd ook transport- en mailboxstatussen gescheiden: acceptatie door de provider, acceptatie door de ontvangende server en inboxplaatsing zijn geen resultaten van DKIM-verificatie.

Begin bij de handtekening op een echt bericht

Haal het ruwe bericht op bij een ontvanger die je zelf beheert en die je via het normale applicatiepad hebt bereikt. Noteer in elk DKIM-Signature-veld het ondertekenende domein `d=`, de selector `s=`, het algoritme `a=`, de canonicalisatiemodi `c=`, de lijst met ondertekende headers `h=`, de body-hash `bh=`, de handtekeningdata `b=` en eventuele tijdstempels. RFC 6376 definieert de tags voor het ondertekenende domein en de selector en gebruikt ze om de publieke sleutel te vinden. Raad de selector niet op basis van een providerdashboard en vraag `_domainkey` niet op zonder selector. Een bericht kan meerdere handtekeningen bevatten van een afzender, tussenpartij of mailingsysteem, dus bewaar het resultaat per handtekening. Plak geen productieberichten in openbare checkers: ruwe headers en body's kunnen ontvangers, bericht-ID's, routeringsdetails, afmeldtokens en applicatiecontent blootleggen. Gebruik afgeschermde opslag en een geredigeerde diagnostische kopie als de volledige inhoud niet nodig is.

Vraag de exacte selector en het ondertekenende domein op

Stel de DNS-naam samen uit de handtekening als `<selector>._domainkey.<signing-domain>`. Als de header `s=app2026` en `d=notify.example.test` bevat, vraag je het TXT-record op bij `app2026._domainkey.notify.example.test`. Noteer de oorspronkelijke naam, de resolver, de respons, de TTL en een eventuele CNAME-keten. Parse het tag-value-record dat je terugkrijgt in plaats van naar een tekstfragment te zoeken. Het record kan de versie, het sleuteltype, een servicebeperking, flags, hash-algoritmen en de data van de publieke sleutel bevatten. Een lege waarde voor de publieke sleutel trekt de sleutel in. Maak onderscheid tussen NXDOMAIN, een leeg antwoord, misvormde inhoud, een niet-ondersteund algoritme, een onbruikbare sleutel en een tijdelijke fout van de resolver. Herhaal een gewijzigde lookup na het verlopen van de TTL via een onafhankelijke resolver, maar ga er niet van uit dat alle ontvangers direct zijn bijgewerkt. Een geslaagde DNS-lookup bewijst alleen dat er op dat moment een record werd teruggegeven; het bewijst niet dat het geteste bericht kan worden geverifieerd of dat de provider het huidige verkeer met die selector ondertekent.

Verifieer de headers, de body-hash en de handtekening

DKIM-verificatie volgt de canonicalisatieregels die in de handtekening zijn opgegeven. De verifier canonicaliseert de body, berekent de hash en vergelijkt die met `bh=`. Daarnaast canonicaliseert hij de ondertekende headers die in `h=` staan, neemt hij het DKIM-Signature-veld mee zoals gespecificeerd en verifieert hij `b=` met de publieke sleutel. Gebruik een onderhouden verifierbibliotheek of het vertrouwde authenticatieresultaat van een ontvanger, in plaats van deze transformaties na te bouwen met stringbewerkingen. Een afwijkende body-hash betekent vaak dat de body na het ondertekenen is gewijzigd, terwijl een mislukte headerhandtekening kan wijzen op wijziging van ondertekende headers, een verkeerde sleutel, beschadigde handtekeningdata of een fout in de implementatie. Leg vast in welke fase het misging. Controleer of belangrijke velden zoals From, Subject, Date en Message-ID zijn ondertekend, maar verzin geen universeel beleid voor ondertekende headers. Canonicalisatie tolereert gedefinieerde opmaakwijzigingen; het maakt willekeurig ingevoegde footers, herschreven MIME, beschadigde regeleinden of wijzigingen tijdens transport niet veilig.

Lees de resultaten van de ontvanger binnen hun vertrouwensgrens

RFC 8601 definieert de Authentication-Results-header en de DKIM-resultaten none, pass, fail, policy, neutral, temperror en permerror. Een pass betekent dat de ontvanger een acceptabele handtekening heeft gevonden die de verificatietests heeft doorstaan. Een temperror kan wijzen op een situatie die waarschijnlijk verandert, zoals een tijdelijk mislukte sleutellookup; een permerror slaagt waarschijnlijk niet bij een latere poging zonder correctie. Noteer de rapporterende authenticatieservice, het ondertekenende domein, de selector en het algoritme, voor zover vermeld. Vertrouw alleen resultaten die binnen de gedocumenteerde grens van het ontvangende systeem zijn toegevoegd, want een afzender kan vóór verzending een vervalst Authentication-Results-veld toevoegen. Bekijk het bovenste vertrouwde resultaat voor de uiteindelijke ontvangende omgeving en houd rekening met tussenliggende hops. Als ontvangers het oneens zijn, vergelijk dan de exacte berichtversie, de DNS-weergave, het tijdstip van evaluatie, de ondersteunde algoritmen en het lokale beleid. Maak van `dkim=pass` geen bewering dat de mailboxprovider de content heeft goedgekeurd of in de inbox heeft geplaatst.

Controleer DMARC-alignment los van een DKIM-pass

Een DKIM-pass authenticeert het ondertekenende domein in `d=`; het vereist niet dat dat domein gelijk is aan het zichtbare RFC 5322 From-domein. RFC 9989 gebruikt een geslaagde, via DKIM geauthenticeerde identifier alleen voor DMARC als die gealigned is met het auteursdomein volgens de geldende strict- of relaxed-alignmentmodus. Een bericht van `billing.example.test` dat is ondertekend met `d=provider.test` kan bijvoorbeeld slagen voor DKIM maar niet gealigned zijn. Een geldige handtekening van `d=example.test` kan in relaxed-modus wel gealigned zijn, afhankelijk van de berekening van het organisatiedomein en het beleid. Rapporteer drie velden: het DKIM-resultaat, het ondertekenende domein en de beslissing over alignment. Een bericht kan ook slagen voor DMARC via gealigned SPF wanneer DKIM faalt of niet gealigned is, dus een DMARC-pass bewijst niet dat die specifieke DKIM-handtekening is geslaagd. De huidige richtlijnen van Gmail voor afzenders bevatten eisen voor authenticatie en alignment voor het betreffende verkeer, maar ook als je daaraan voldoet, is acceptatie door de ontvangende server of plaatsing in de mailbox niet gegarandeerd.

Controleer actuele algoritmen en sleutelrotatie

RFC 8301 werkt de cryptografische eisen van DKIM bij: ondertekenaars moeten `rsa-sha256` gebruiken, verifiers moeten het ondersteunen en `rsa-sha1` mag niet worden gebruikt. De RFC vereist ook RSA-ondertekeningssleutels van minstens 1024 bits en legt uit waarom grotere sleutels de voorkeur hebben als dat operationeel mogelijk is. Een checker moet het algoritme vaststellen en verouderd of onbruikbaar materiaal markeren, zonder te beweren dat sleutellengte alleen een mailstream betrouwbaar maakt. Workflows verschillen per provider. Amazon SES documenteert dat Easy DKIM standaard 2048-bits sleutels gebruikt en waarschuwt dat het wijzigen van ondertekeningsmethoden zonder tussenstap een periode kan veroorzaken waarin berichten niet met DKIM zijn ondertekend. Plan rotatie met twee geldige selectors of het gedocumenteerde overlapmechanisme van de provider, controleer dat nieuwe berichten de nieuwe selector gebruiken, houd de oude publieke sleutel aan zolang vertraagde mail nog kan binnenkomen en verwijder hem pas na de overlapperiode. Publiceer de private ondertekeningssleutel nooit in DNS, logs, tickets of prompts.

Analyseer fouten vanuit het bericht naar buiten

Als een controle faalt, bewaar dan het ruwe bericht en het resultaat van de ontvanger voordat je DNS wijzigt. Controleer of de verwachte applicatie en provider het bericht echt hebben geproduceerd. Als er geen handtekening is, controleer dan of ondertekening was ingeschakeld voor die identiteit, regio, tenant of berichtklasse. Als de selectorlookup faalt, vergelijk dan de exacte waarden van `d=` en `s=`, de DNS-zone, het CNAME-doel, de TTL en recente rotaties. Als de sleutel correct wordt geparset maar de body-hash faalt, controleer dan gateways, footers van mailinglijsten, herschreven trackinglinks, MIME-transformaties, regeleinden en beveiligingsproducten die de content na ondertekening kunnen wijzigen. Als de cryptografische handtekening faalt terwijl de body-hash overeenkomt, onderzoek dan gewijzigde ondertekende headers, een niet-overeenkomende sleutel en de ondertekeningsimplementatie. Als DKIM slaagt maar DMARC faalt, test dan de alignment in plaats van dezelfde sleutel opnieuw te publiceren. Test opnieuw via ontvangers die je zelf beheert nadat de relevante TTL of configuratiewijziging is doorgevoerd, en leg per berichtklasse bewijs vast in plaats van het hele domein op basis van één geslaagd voorbeeld hersteld te verklaren.

Houd een controleerbaar record bij van DKIM-controles

Bewaar voor elk gecontroleerd bericht een niet-gevoelige correlatie-identifier, het verzendende systeem, het provideraccount of de workspace, het zichtbare From-domein, het ontvangende systeem, het tijdstip van het bericht en het volledige resultaat per handtekening. Neem `d=`, `s=`, `a=`, canonicalisatie, ondertekende headers, de naam van de DNS-query, het tijdstip en de TTL van de DNS-respons, de status van het sleutelrecord, het resultaat van de body-hash, het resultaat van de handtekening, de vertrouwde Authentication-Results-waarde, de beslissing over DMARC-alignment en de verantwoordelijke voor herstel op. Sla ruwe berichten alleen op waar passende toegangs- en bewaarcontroles gelden. Voeg het testscenario toe: normale verzending vanuit de applicatie, migratie van provider, sleutelrotatie, gatewaypad of doorsturen. Zo worden regressies vergelijkbaar en wordt een screenshot niet permanent bewijs nadat selectors of berichtverwerking zijn gewijzigd. Controleer opnieuw na wijzigingen in de providerconfiguratie, DNS, de ondertekeningsmethode of de routering, of bij een nieuwe berichtklasse. Een operationeel dashboard moet de statussen onbekend en niet beschikbaar expliciet tonen in plaats van ze stilzwijgend als pass of fail te behandelen.

Begrijp hoe SendHQ in de controle past

SendHQ vereist een geverifieerd From-domein en biedt bezorgevents. Verstuur voor een DKIM-check een gecontroleerd bericht via het bedoelde applicatiepad, inspecteer de ontvangen handtekening, vraag de daadwerkelijke `d=`- en `s=`-waarden op en leg alignment afzonderlijk vast. Leid niet alleen uit productdocumentatie een selector, sleutellengte, ondertekeningsalgoritme, inboxplaatsing of bezorggarantie af.

Veelgestelde vragen

Bronnen

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — RFC Editor
• RFC 8301: Cryptographic Algorithm and Key Size Update to DomainKeys Identified Mail (DKIM) — RFC Editor
• RFC 8601: Authentication-Results Header Field — RFC Editor
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor
• Richtlijnen voor e-mailafzenders van Gmail — Google
• Easy DKIM gebruiken in Amazon SES — Amazon Web Services
• OpenAPI-contract van SendHQ — SendHQ