Een aanbieder kan naar waarheid melden dat zijn post passeert DKIM terwijl u ondertekent met een domein dat geen verband houdt met uw zichtbare Van-adres. Als het doel is om het auteurdomein van uw organisatie te verifiëren DMARC, vraag om een ondersteunde afgestemde DKIM identiteit en definieer hoe deze wordt geverifieerd. Een algemeen verzoek om DKIM in te schakelen is te dubbelzinnig.
Begin met een gecontroleerd bericht van de daadwerkelijke dienst en route. Behoud het ruwe ontvangen formulier en het vertrouwde ontvangerresultaat. Dit geeft de provider een concrete identiteitsmismatch om te onderzoeken zonder aan te nemen dat het product bij elk abonnement of transport een aangepaste domeinondertekening biedt.
Vermeld de identiteiten afzonderlijk
Neem het zichtbare Van-domein op, envelop afzender identiteit, SPF resultaat, elk DKIM d-domein, keuzeschakelaar en verificatieresultaat. Neerzetten uitlijning op een apart veld. RFC 9989 §4.4 beschouwt authenticatiesucces en identificatie-uitlijning als verschillende vereisten; een niet-gerelateerd passerend DKIM domein wordt niet uitgelijnd omdat het eigendom is van de verzendende provider.
Strikte DKIM uitlijning vereist een exacte domeinmatch onder RFC 9989 §3.2.10. Ontspannen afstemming vergelijkt organisatiedomeinen onder RFC 9989 §4.10.2. Vraag welk d-domein de provider daadwerkelijk kan uitzenden en vergelijk dit vervolgens met uw beoogde Van-domein en beleid. Vraag niet om een bepaalde DNS waarde voordat de provider de ondersteunde identiteit en accountconfiguratie bevestigt.
Toon de misleidende pas duidelijk
Illustratief identiteitswerkblad:
- Alleen identiteit van provider: From= brand.example ; d=provider.example; aangenomen DKIM pas; niet op elkaar afgestemd, ervan uitgaande dat dit niet-gerelateerde organisatiedomeinen zijn.
- Klantidentiteit: Van= brand.example ; d=brand.example; aangenomen DKIM pas; exacte domeinovereenkomst.
Neem de resultaten aan die voor dit voorbeeld worden getoond. Ze vormen geen testbewijs voor ontvangen berichten. In het eerste geval kan DMARC nog steeds door uitgelijnde SPF passeren. Claim dus geen algehele DMARC fout zonder de identiteit van de envelop en SPF resultaat te controleren. Het werkblad isoleert de DKIM eigenschap die wordt aangevraagd.
Stuur een nauwkeurig technisch verzoek
Vraag de provider of het genoemde product, het accountplan en de verzendroute een door de klant gecontroleerd ondertekeningsdomein ondersteunen dat is afgestemd op het beoogde Van-adres. Voeg indien van toepassing API-, SMTP , campagne- of transactieroutedetails toe. Vraag of het gedrag verschilt voor aliassen, subdomeinen en gedelegeerde gebruikers.
Vraag de exacte selectornamen, DNS recordtypen en -waarden, activeringsstap en verificatieprocedure op. Vraag wie de privésleutels beheert, hoe rotatie wordt uitgevoerd en wat er gebeurt met verificatierecords na offboarding. Als een CNAME nodig is, bevestig dan het doel en de reikwijdte ervan in plaats van deze te vervangen door een vermoeden TXT record.
Deel een geredigeerd identiteitswerkblad of gecontroleerd testbericht in plaats van een klantbericht met onnodige persoonlijke inhoud. Voor een ondersteuningsverzoek van een provider is geen persoonlijke ondertekeningssleutel of mailboxwachtwoord nodig. Houd gevoelige inloggegevens uit gewone tickets.
Ga akkoord met acceptatiecriteria voordat u DNS wijzigt
Een nuttige acceptatietest vereist een nieuw bericht van de daadwerkelijke productie-equivalente route, een beoogde passage DKIM -handtekening bij een vertrouwde ontvanger en afstemming onder het betreffende beleid. Test belangrijke berichtformaten en routes afzonderlijk. Alleen het publiceren DNS records of het zien van een geverifieerde badge is onvolledig bewijs.
Als de aanbieder ook zijn eigen handtekening toevoegt, controleer dan beide. Meerdere handtekeningen zijn toegestaan onder RFC 6376 §4.2, en een passerende uitgelijnde handtekening levert het DKIM pad eronder RFC 9989 §4.4.1. Registreer de selector en het d-domein dat daadwerkelijk is waargenomen, in plaats van te vertrouwen op de eerste handtekening die een headertool weergeeft.
Ga eerlijk om met niet-ondersteunde mogelijkheden
Als op maat gemaakte DKIM niet beschikbaar is, vraag dan naar de ondersteunde alternatieven en hun beperkingen. Een passerend uitgelijnd SPF pad kan voldoen aan DMARC voor een toepasselijke directe route, maar het creëert geen uitgelijnde DKIM of garandeert veerkracht door doorsturen; RFC 7208 §10.3 bespreekt de beperkingen SPF mediator. Voor de vereisten van de organisatie kan een andere ondersteunde verzendidentiteit of -service nodig zijn.
Sluit het verzoek met de overeengekomen identiteit, route, DNS eigendom, sleutelbeheerder en bewijs van ontvangen berichten. Als een mogelijkheid niet wordt ondersteund, leg deze dan expliciet vast. Het resultaat zou een verifieerbaar verzendontwerp moeten zijn in plaats van een belofte dat een DKIM pas uw merkidentiteit bewijst.
Noteer de volgende beslissing
Bereid deze velden voor voordat u contact opneemt met de ondersteuning: product en route; bedoeld van; waargenomen d/s en vertrouwd resultaat; vereiste uitlijningsmodus; capaciteitsvraag; aangevraagde gegenereerde DNS -instructies; sleutelbewaarder; rotatie- en exitvragen; en acceptatiecriteria. Onnodige persoonlijke gegevens redigeren. Dit is een checklist voor technische verzoeken, geen verzonden ticket, een goedgekeurde DNS wijziging of een bewijs van geconfigureerde service.