Configuration de DomainKeys

J'ai essayé d'améliorer la sécurité de mes e-mails (et d'éviter qu'ils soient marqués comme spam) en ajoutant les enregistrements SPF et DKIM. J'ai donc créé les deux et j'ai testé les résultats avec check-auth@port25.com. Voici le résultat:

==========================================================
Summary of Results
==========================================================
SPF check: pass
DomainKeys check: neutral
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham

Donc, tout s'est passé sauf pour DomainKeys . Le rapport détaillé est:

----------------------------------------------------------
DomainKeys check details:
----------------------------------------------------------
Result: neutral (message not signed)
ID(s) verified: header.From=myemail@mydomain.com
DNS record(s):

J'ai ensuite essayé d'ajouter l'enregistrement TXT _domainkey.mydomain.comavec le contenu t=y; o=~et j'ai vérifié à nouveau, mais le résultat était le même (le DNS s'est propagé, car j'ai vérifié l'enregistrement DNS de mxtoolbox et je l'ai obtenu).

Que dois-je faire pour résoudre ce problème?

La bonne réponse à «que dois-je faire pour résoudre ce problème» consiste à supprimer l'enregistrement DomainKeys. La confusion vient de l'idée que DomainKeys et DomainKeys Identified Mail (DKIM) sont les mêmes. Ils ne le sont pas. DomainKeys était une technologie spécifique à Yahoo qui est officiellement morte depuis 2007. Comme l'a déclaré Chris S., DKIM (DomainKeys Identified Mail) est le successeur de DomainKeys. Depuis 2007.

Il y a quelques années, j'ai exécuté à la fois un DomainKeys et un validateur DKIM sur le courrier entrant. J'ai vu quelques e-mails portant des signatures DomainKeys mais je serais surpris si c'était toujours le cas. Il n'y a plus aucune raison de déployer DomainKeys car aucun logiciel de signature DomainKeys n'est toujours pris en charge.

C'est tout ce dont vous devez vous soucier:

Chèque DKIM: réussite

Et tu es bon.

De plus, Chris S. se trompe sur l'ID de l'expéditeur. Il n'est ni n'a jamais été proposé comme successeur du SPF. L'ID de l'expéditeur est une norme proposée par Microsoft qui a été construite au sommet de SPF. SPF et Sender ID ne font pas les mêmes choses. L'ID de l'expéditeur était la tentative de Microsoft d'ajouter des vérifications de validation d'en-tête au sommet de SPF (qui valide l'expéditeur d'enveloppe). Le reste de la communauté de la messagerie électronique l'a rejeté en partie parce que Microsoft a revendiqué des droits de brevet et ne les a abandonnés qu'après la naissance de l'ID de l'expéditeur. En dehors de hotmail.com et des serveurs Exchange sur site, l'adoption de l'ID de l'expéditeur peut être décrite avec précision comme une erreur d'arrondi.

Microsoft a cessé de valider l'ID de l'expéditeur sur hotmail, ne laissant que sur les serveurs Exchange sur site les derniers vestiges de l'ID de l'expéditeur sur Internet. Ils ont annoncé des changements à venir dans Exchange qui arrêteront de briser les signatures DKIM lorsque les messages passeront par les serveurs Exchange. Bien que DMARC empêche simplement le phishing, Microsoft a officiellement sauté sur le train de marche DMARC embrassant à la fois DKIM et SPF.

Pour que DKIM fonctionne, vous devez signer chaque courrier sortant avec votre clé privée dkim (sur le serveur de messagerie). La clé publique doit être ajoutée à votre enregistrement dkim dns, afin que d'autres personnes puissent vérifier vos e-mails signés.

pour la signature dkim j'utilise:

http://www.opendkim.org/

spf est facile à implémenter - dkim demande un peu plus d'efforts