Validity Helpcentrum

het veld DKIM signature header is een speciale header die in elk e-mailbericht wordt geplaatst en informatie bevat over de afzender, het bericht en de publieke sleutellocatie die nodig is voor verificatie. Dit koptekstveld is vereist door alle mailboxproviders die DKIM gebruiken om uw identiteit te verifiëren, inclusief AOL, Gmail, Outlook.com en Yahoo!.,

Hier is een voorbeeld van een DKIM signature header:

de DKIM signature header bestaat uit verschillende informatieve elementen die worden weergegeven door het gebruik van tag=value paren. De tag is meestal een enkele letter gevolgd door een gelijk teken (=). De waarde van elke tag geeft een specifiek stukje informatie aan over de locatie van de afzender, het bericht en de openbare sleutel.

Er zijn tal van tags beschikbaar voor een afzender; sommige tags zijn vereist en andere tags zijn optioneel., Het missen van een vereiste tag in de DKIM handtekening leidt tot een verificatiefout met de mailbox provider, terwijl het missen van een optionele tag niet.

Het is belangrijk op te merken dat tags die zijn opgenomen in de DKIM-handtekening en die geen waarde hebben die eraan is gekoppeld, worden behandeld als tags die een lege waarde hebben. Tags die niet in de DKIM-handtekening zijn opgenomen, worden echter behandeld als tags die de standaardwaarde hebben.

vereiste tags

Hieronder staan de vereiste tags van een DKIM signature header. Alle DKIM-handtekeningen die deze tags missen, zullen een fout ondervinden tijdens het verificatieproces.,

• v = geeft de versie van de ondertekeningsspecificatie aan. De waarde moet altijd worden ingesteld op 1.
• a= geeft het algoritme aan dat wordt gebruikt om de handtekening te genereren. De waarde moet rsa-sha256 zijn. Afzenders met verminderde CPU-mogelijkheden kunnen rsa-sha1 gebruiken. Het gebruik van rsa-sha1 wordt echter afgeraden vanwege potentiële veiligheidsrisico ‘ s.
• s= geeft de selectorrecordnaam aan die met het domein wordt gebruikt om de publieke sleutel in DNS te vinden. De waarde is een naam of nummer gemaakt door de afzender.,
• hier is een voorbeeld van een DNS selector record. De tags in dit voorbeeld verschijnen alleen in dit record binnen DNS en niet in de e-mailheader zelf: <selector (s=)._domainkey.domein (d=)>. TXT v=DKIM1; k = rsa; p=<public key>
• b= is de hashgegevens van de headers in de H= tag; deze hash wordt ook de DKIM signature genoemd en gecodeerd in Base64.,
• bh= is de berekende hash van de berichttekst. De waarde is een tekenreeks die de hash vertegenwoordigt die bepaald wordt door het hash-algoritme.
• d= geeft het domein aan dat wordt gebruikt met de selector record (s=) om de publieke sleutel te vinden. De waarde is een domeinnaam die eigendom is van de afzender.
• h= is een lijst van headers die gebruikt zullen worden in het ondertekeningsalgoritme om de hash te maken die gevonden wordt in de B= tag., De volgorde van de headers in de H = tag is de volgorde waarin ze werden gepresenteerd tijdens DKIM ondertekening, en daarom is ook de volgorde waarin ze moeten worden gepresenteerd tijdens de verificatie. De waarde is een lijst met kopvelden die niet zullen veranderen of worden verwijderd.

optioneel en aanbevolen tags

Hieronder staan de optionele tags die u kunt opnemen in een DKIM signature header. DKIM-handtekeningen die deze tags missen, zullen geen fout ondervinden tijdens de verificatie, maar ze worden aanbevolen als een middel om spam te identificeren.

Spammers stellen normaal gesproken geen tijdwaarden in., Lege of onjuiste tijdwaarden, zoals een vervaldatum die is gedateerd vóór de tijdstempel van de e-mail, zullen ertoe leiden dat sommige mailboxproviders het bericht weigeren.

• t= is de DKIM signature timestamp. Het is bedoeld om aan te geven wanneer dat bericht wordt verzonden. Het formaat is het aantal seconden vanaf 00: 00: 00 op 1 januari 1970 in de UTC tijdzone.
• x= is de DKIM signature expiration time in hetzelfde formaat als hierboven. De waarde van deze tag moet groter zijn dan de waarde van de tijdstempel tag als beide worden gebruikt in de DKIM signature., DKIM-handtekeningen kunnen als ongeldig worden beschouwd als de verificatietijd bij de verificateur voorbij de vervaldatum is, dus zorg ervoor dat u de vervaldatum niet te vroeg instelt.

voltooi het testen om er zeker van te zijn dat deze tags goed werken en dat de verlooptijd niet te snel na de implementatie wordt ingesteld.

optionele tags

Hieronder staan de optionele tags die niet vereist zijn in de DKIM-handtekening.,

• c= is het canonicalisatiealgoritme dat Voor een postbus-provider definieert welk niveau van wijzigingen aanwezig kunnen zijn als de e-mail onderweg is naar de postbus-provider. Wijzigingen kunnen witruimte of regelafbreking omvatten. Sommige e-mailservers maken kleine wijzigingen aan de e-mail tijdens de doorvoer die de handtekening ongeldig kan maken.
• hier is de waarde die bepaalt welk tolerantieniveau de doelserver moet hebben wanneer een bericht deze kleine wijzigingen heeft: value1/value2.,

waarde1 vertegenwoordigt de kop van het bericht en waarde2 vertegenwoordigt de inhoud van het bericht. Value1 en value2 kunnen worden aangeduid als” eenvoudig”, dat zeer weinig of geen modificatie tolereert, of” ontspannen ” dat veel voorkomende modificaties tolereert.

• i= geeft de identiteit van de gebruiker of agent aan. De waarde is een e-mailadres dat het domein of subdomein bevat zoals gedefinieerd in de D= tag.,

Optionele en niet aanbevolen tags

• l= is het aantal tekens uit de berichttekst dat werd gebruikt om de hoofdtekst hash (bh=) te berekenen. Als deze waarde er niet is, dan wordt aangenomen dat de hele berichttekst is gebruikt. We raden u niet aan deze tag te gebruiken, omdat het moeilijk te controleren kan zijn en kan leiden tot verificatiefouten.
• z= is een lijst van de oorspronkelijke headers van het bericht en kan afwijken van de headers in de H= tag., Deze tag kan worden gebruikt door sommige mailbox providers in het proces van het diagnosticeren van een verificatiefout. De waarde ervan is niet goed gedefinieerd.

niet-herkende tags

alle tags die niet zijn gespecificeerd in RFC 6376 maken geen deel uit van het DKIM-protocol en moeten tijdens het verificatieproces worden genegeerd. Niet alle mailbox providers negeren niet-herkende tags, dus u kunt een fout zien tijdens het verificatieproces.

volledige informatie over de DKIM-handtekening is te vinden op de DKIM-website of op RFC 6376.