SPF, DKIM et DMARC sur plans mails classiques (hébergement, MX)

Bonjour,

Voyez les réponses ici: https://community.ovh.com/t/Le-DKIM-%C2%BB-est-%C3%A0-pr%C3%A9sent-disponible-dans-votre-espace-client/61978/4
et ici: https://community.ovh.com/t/Le-sous-domaine-utilise-d%C3%A9j%C3%A0-un-enregistrement-DNS-Vous-ne-pouvez-pas-enregistrer-de-champ-CNAME-en-raison-dune-incompatibilit%C3%A9-Supprimez-les-enregistrements-existants-pour-ce-sous-domaine-afin-de-pouvoir-en-ajouter-un-de-type-CNAME/61154/23

Bonjour,

GMail et Yahoo annoncent qu'à partir du 1/2/2024 ils vont refuser les emails venant de domaines qui ne comportent pas de SPF et pas de DKIM pour tous les emails,

alors non ça c'est faux pour Gmail, la restriction SPF+DKIM c'est que pour ceux qui sont à plus de 5k mails/jours :


La seule question est de savoir comment Gmail va compter les 5k mails à savoir par IP ? Par domaine ?

Si c'est par IP cela va effectivement poser problème, et pas que chez OVH du coup, cela va également impacter TOUS les sites web qui utilise la fonction mail() si l'hébergeur ne prévoit pas de signer les mails qui sort de la fonction mail() avec du dkim.

Cordialement, janus57

```text Bonjour,
Oui donc c'est bien ce que je pensais, il n'y a pas, à l'heure actuelle, de solution pour les MXplan et les MXHosting, uniquement pour Exchange et EmailPro.

Je comprends les interrogations de EmailTeam concernant la base de calcul les envois de 5000 emails et plus (par IP, par domaine, ...) mais je pense que c'est un peu le souci mineur, je ne sais pas s'il y a beaucoup de "fous" qui tentent d'envoyer 5000 emails depuis un MXPlan, non le VRAI problème c'est que DKIM+SPF s'appliquent apparemment à l'email transactionnel, donc nos emails de tous les jours, à 1 ou 2 destinataires.

Voir par ex.: https://www.programmez.com/node/36019 https://www.programmez.com/node/36019 qui explique bien qu'à priori à partir de juin cela concerne absolument tous les emails, pour les envois par 5000 le DMARC est requis en plus.

@janus57: pour moi le texte est effectivement clair et concerne tous les expéditeurs, pour ceux qui en envoient + de 5K il y a des exigences en plus, il y a un lien spécifique dans le texte Google cité , mais le texte s'applique que l'on envoie un ou 10000 mails, pour 5K et plus il faut ajouter le DMARC. La seule info nouvelle que je vois c'est que ce serait SPF **ou** DKIM, ce qui effectivement change un peu la donne, mon lien lui dit SPF **et** DKIM.

Extrait de mon lien:
Les administrateurs de serveurs de messagerie doivent bien comprendre qu'au final les contrôles SPF et DKIM ne concerneront pas que les mailings, mais bien tous les mails, même envoyés à l'unité, comme c'est déjà le cas pour les 'nouveaux serveurs', ainsi que mentionnés ci-dessus. En clair, pour qu'un seul mail puisse arriver à une adresse gmail.com, yahoo.fr, etc. le serveur émetteur devra implémenter au moins SPF et DKIM en juin 2024. ```

Bonjour,

Extrait de mon lien:

le seul vrai lien qui indique les conditions Google : https://support.google.com/a/answer/81126?hl=fr&visit_id=638410938923158480-2640133450&rd=1#zippy=%2Cexigences-pour-tous-les-exp%C3%A9diteurs
Et c'est ce qui est sur ma capture.

Pour Yahoo :

Cf : https://senders.yahooinc.com/best-practices/

Chez les deux la problématique est pour les "gros" envoyeurs", sauf que Yahoo précise que ce serait domaine + toute info dispo, mais sans préciser le seuil, là ou google dit 5000, mais sans préciser.
[quote]
How does Yahoo classify a “bulk sender”?

* For the purposes of enforcement, a “sender” is viewed at the authenticated domain or From header domain level. However, we will use all of the information available (content, IP, etc.) to review sender compliance.
* A “bulk” sender is classified as an email sender sending a significant volume of mail. We will not specify a volume threshold.
[/Quote]
Cf : https://senders.yahooinc.com/faqs/

Cordialement, janus57

Ben oui et je lis bien les conditions de Google qui sont titrées "Consignes pour les expéditeurs de messages" et donc ça s'applique bien à tous les envois. Il y a à l'intérieur de ce texte un second lien vers les contraintes si l'on doit envoyer à plus de 5000 destinataires mais le texte cité s'applique bien à tous.
Idem pour Yahoo, ce sont des "requirements for all senders".

Et donc pour Google c'est:
1-4999: SPF ou DKIM
5000+: SPF et DKIM et DMARC

Mon lien parle d'une autre échéance en juin ou ce serait SPF et DKIM dès le premier destinataire, je ne sais pas d'ou ils tiennent ces infos.

Un des soucis que je vois c'est l'ajout des en-têtes ARC en cas de transfert, en particulier quand on fait des redirections genre contact@domaine.fr vers machin@, truc@ et bidule@ au niveau du panel OVH ....

```text Bonjour,

les contraintes si l'on doit envoyer à plus de 5000 destinataires mais le texte cité s'applique bien à tous.

non c'est si vous envoyer +5000 **mails** (envoyer 1 mail à 5000 destinataires ou 5000mails à un même destinataire sera pareil) par jour.

Mon lien parle d'une autre échéance en juin ou ce serait SPF et DKIM dès le premier destinataire, je ne sais pas d'ou ils tiennent ces infos.

si l’info n'est pas validée par aucun des prestataires (ici Google et/ou Yahoo), perso j'appel ça une rumeur infondée.
Surtout que ça fait au minimum depuis octobre 2023 que Google indique qu’un changement de politique va avoir lieu en février 2024.
Source : http://web.archive.org/web/20231004060130/https://support.google.com/a/answer/81126

Un des soucis que je vois c'est l'ajout des en-têtes ARC en cas de transfert, en particulier quand on fait des redirections genre contact@domaine.fr vers machin@, truc@ et bidule@ au niveau du panel OVH

c'est déjà cassé depuis plusieurs mois à destination de Google, de manière générale le transfert de mail externe est a éviter (depuis quelques années déjà) il est préférable de faire du pull de mail.

Cordialement, janus57 ```

en particulier quand on fait des redirections genre contact@domaine.fr vers machin@, truc@ et bidule@ au niveau du panel OVH

J'ai quand même un contre-exemple un peu chelou.

Il s'agit d'un domaine qui a 20 ans, avec un hébergement 60gp qui a aussi 20 ans, dont la messagerie mxplan5-hosting a été migrée vers la nouvelle infra (OVH peut vérifier: mxplan-1xwaony-1)

Les redirections effectuées par cet hébergement utilisent une méthode tout-à-fait acceptable.

L'envoi initial depuis quelqu.un@quelque.part à `tresorier@example.be` a été redirigé par les bons soins d'OVH à une autre adresse, et dans cette opération l'expéditeur quelqu.un@quelque.part a été remplacé par `tresorier+_redir+pt301p70g66h88xoj4r8dc8ds@example.be`.
Ce qui fait que le serveur du destinataire voit un mail qui provient du domaine qui a effectué la redirection, avec son SPF, et non celui de l'expéditeur original.
Si le SPF (et le futur DKIM) de example.be est correctement configuré, le mail devrait être accepté après la redirection.
Du coup, si on envoie peu de temps après un mail à cette adresse reconstruite par OVH, il faudrait le faire suivre à son expéditeur original. Exemple: un message d'erreur: boîte pleine ...
C'est une fonctionnalité que ARC ou SRS gèrent correctement.

Dans notre cas, un mail envoyé quelques minutes plus tard à l'adresse ainsi construite par OVH semble disparaître dans un trou noir (le message est accepté et disparaît, aucun message d'erreur)
`Jan 17 14:17:14 UTC to=, relay=mx0.ovh.net[178.33.43.154] Ok: queued as 4TFScp2bggz2XrGK0`

Ci-dessus, la seule édition est le nom de domaine qui n'est pas example.
Tout le reste est authentique. Si OVH veut vérifier...

non c'est si vous envoyer +5000 mails (envoyer 1 mail à 5000 destinataires ou 5000mails à un même destinataire sera pareil) par jour.

Je ne vais pas polémiquer 2 heures, je ne lis apparemment pas la même chose que vous, pour moi le texte cité titré "**Exigences pour tous les expéditeurs**" s'applique clairement à tous les envois que ce soit d'un mail ou de 5000 et seulement si on envoie plus de 5000 mails on suit le second lien qui liste les obligations spécifiques, il s'appelle "**Conditions requises pour envoyer 5000 messages ou plus par jour** ".
Ok pour les autres remarques.

Bonjour,

Je ne vais pas polémiquer 2 heures

ma remarque était sur le "5000 destinataires" de votre message qui est incorrect, car c'est 5000 mails et mails!=destinataire.

En informatique chaque mot peut avoir une incidence et dans ce contexte en particulier les deux sont différents.

Pour le reste j'ai pas remis en cause la notion de "Exigences pour tous les expéditeurs" vs "Conditions requises pour envoyer 5000 messages ou plus par jour ".

Maintenant il reste juste la définition de ce que Google entend par "5 000 messages ou plus par jour" que personne ne sait (pour le moment) mais qu'on va très vite découvrir en février.

Il s'agit d'un domaine qui a 20 ans, avec un hébergement 60gp qui a aussi 20 ans, dont la messagerie mxplan5-hosting a été migrée vers la nouvelle infra (OVH peut vérifier: mxplan-1xwaony-1)

sur un serveur exchange je présume ?
Car je dirais que ce mécanisme n'est pas présent avec les offres qui sont roundcube en webmail et j'ai un exemple ou cela casse le SPF (seule DKIM semble survivre à la redirection).

Cordialement, janus57

j'ai un exemple ou cela casse le SPF

Sur d'autres Exchange, OVH ne l'a pas implémenté.
Je dirais même que tous les autres hébergements mail (linux ou exchange) n'ont pas ce comportement et cassent SPF.

Evidemment tous mes tests passent car
- je signe DKIM
- tous ces domaines hébergés chez OVH ont le SPF d'OVH...

Je vois qu'on est pas les seules a avoir des débats sur SPF/DKIM/DMARC/ARC/SRS.

Voila notre status, en février, Gmail va demander le SPF et DKIM pour les flux envoyant plus de 5 000 messages par jours. Sachant que le flux n'est pas défini IP, domaine, adresse email.
En juin, je n'ai pas d'information officiel pour savoir si ce sera aussi le cas pour les flux de moins de 5 000 messages par jours.

Dans tous les cas, nous avions planifié de vous proposez le DKIM sur MXPlan vers Avril/Mai, si la situation en février est impactante, nous seront en mesure de l'appliquer en "urgence" (potentiellement sans interface pour le gérer) assez rapidement.

PS: J'ai déjà du DKIM sur mon MXPlan de test.


Sinon, sur les redirections/mailing list et SPF/DKIM/DMARC/ARC/SRS:
Les redirections standard (sans SRS) casse le SPF
Les redirections avec SRS ne cassent pas le SPF, mais malheureusement, elles cassent le DMARC (l'alignement plus précisément).
La seule façon de faire des redirections semble être d'avoir ARC avec des redirections standards.
Les mailing list (celle OVH) cassent le DKIM et le DMARC.
Il semble qu'il faudrait avoir un système de mailing list utilisant le "send as/send on behalf" et avoir ARC.
Sans ARC, il semble qu'a terme les redirections/mailing list vers l’extérieur n'ai pas un grand avenir (et c'est déjà compliqué aujourd'hui).

Donc, actuellement, on s'occupe de DKIM puis on lance Zimbra, puis on regarde ARC, les redirections et les mailing list. On a pas prévu de se reposer en 2024.

On a pas prévu de se reposer en 2024.

Courage les gars, votre situation est "chaud boulette" vu la quantité de plateformes que vous gérez, sans compter tout ce qui a été greffé sur les systèmes e-mail durant les 25 années d'existence d'OVH.

Bonjour à tous,

Merci pour ces discussions passionnantes !
Et aussi pour la bonne nouvelle ci-dessous.

PS: J'ai déjà du DKIM sur mon MXPlan de test.

Avec un MxPlan, dans l'onglet zone DNS d'un nom de domaine, si on fait "Ajouter une entrée", la fenêtre qui s'ouvre nous permet de choisir différents types de champs comprennent (entre autres) "SPF", "DKIM" et "DMARC".
N'est ce pas une solution pour permettre d'ajouter au moins le DKIM à un MxPlan ?

Il suffirait de savoir où trouver les informations à renseigner dans la création du champ "DKIM".
Pour le moment, je n'ai pas trouvé toutes les explications utiles, mais cela semble être un voie praticable,.
Qu'en pensez-vous ?

Merci par avance et bonne soirée !

Bonjour,

N'est ce pas une solution pour permettre d'ajouter au moins le DKIM à un MxPlan ?

non il faut que cela soit implanté côté serveur mail

Qu'en pensez-vous ?

comme dit plus haut, cela viendra en temps et en heure, mais pas tout de suite pour les MX Plan.

Cordialement, janus57

si on fait "Ajouter une entrée", la fenêtre qui s'ouvre nous permet de choisir différents types de champs comprennent (entre autres) "SPF", "DKIM" et "DMARC".

Détrompez-vous, je vais un peu freiner votre enthousisame.

Tous ces enregistrements sont en fait des enregistrements DNS de type TXT, etc chacun d'entre eux a une présentation particulière.

Le SPF est toujours à la racine du domaine, je considère que vous connaissez déjà cet enregistrement.

Si vous créez un enregistrement TXT qui commence par "v=spf1 ..." , il s'agit d'un enregistrement SPF.

Dans la console OVH, ce que OVH présente comme enregistrement SPF est un enregistrement TXT.

Il est donc trop facile de créer 2 enregistrements TXT de type SPF dans votre domaine sans vous en rendre compte, et ceci est une violation de protocole.

Passons à DMARC en sautant au-dessus de DKIM, on y reviendra après.

Un enregistrement DMARC est toujours attaché au sous-domaine fictif \_dmarc (donc \_dmarc.example.com. pour le domaine example.com)
OVh dans sa gratitude ne propose même pas le sous-domaine _dmarc dans l'outil de création d'un enregistrement DMARC, et évidemment cet enregistrement ne sera pas interprété si vous ne l'avez pas ajouté vous-même.

Concernant DKIM c'est plus compliqué.
DKIM est un procédé de signature électronique (sceau d'authenticité) apposé par le serveur de messagerie qui produit l'e-mail.
Tant que l'e-mail n'est pas altéré en chemin, la signature doit rester valide.
Si on change le sujet du mail par exemple en ajoutant [SPAM], le mail est altéré et son DKIM est invalide. Il en est de même si on change le contenu du mail.
Les mécanismes de signature électronique se basent à peu près tous sur une paire de clés complémentaires. L'une est une clé privée à ne jamais divulguer. L'autre, la clé publique doit être accessible à tout le monde ou au moins à celui qui doit vérifier la validité de la signature.
Dans le cas de DKIM c'est l'opérateur du serveur de mail d'envoi qui détient la clé privée et ne la donne à personne.
La clé publique est postée dans DNS, dans un enregistrement TXT à l'adresse selector.\_domainkey.example.com.
Le mot "selector" doit correspondre à un mot correspondant trouvé dans l'e-mail signé. Ceci permet d'avoir plusieurs serveurs avec des paires de clés différentes et des selector différents.
Enfin si le serveur d'envoi donne du service à beaucoup de domaines différents, il peut tout signer au moyen de la même clé, et au lieu de diffuser le clé publique complète dans des enregistrements DKIM dans tous ses domaines affiliés, il suffit de faire un enregistrement CNAME chez tous ces domaines.

J'imagine bien que c'est la manière qu'OVH pourrait utiliser pour activer DKIM en une fois chez tout le monde, ajouter un enregistrement CNAME "improbable._domainkey.example.com. " chez tous ses clients MX Mail (avec "improbable" ne risquant pas de créer un conflit chez qui que ce soit) et tout signer au moyen de la même clé. Le CNAME pointant vers la clé DKIM en usage chez OVH.

Bonjour @janus57 @Fritz2cat ,

Merci pour ces précisions importantes.

Effectivement, si la bouteille est vide, on aura beau mettre une belle étiquette dessus, on n'aura jamais l'effet souhaité.

Vos précisions sont tout à fait convaincantes (et m'évitent de nombreuses recherches vaines) !

Bonne fin de semaine.