Sujets abordés dans ce domaine :
les paramètres minimaux requis
Prenez le contrôle total de la réputation de vos emails
Contrôlez ce qui arrive à vos e-mails
vérifie automatiquement le bon fonctionnement des services toutes les dix minutes
Sujets abordés dans ce domaine :
Introduction au cadre de politique de l'expéditeur
validez vos paramètres SPF de messagerie en envoyant un message électronique
Introduction au courrier électronique identifiée par DomainKeys
validez vos paramètres DKIM de messagerie en envoyant un message électronique
SPF est l'abréviation de Sender Policy Framework, une norme d'authentification des e-mails
qui vous permet de déclarer quels serveurs SMTP sont autorisés à envoyer des e-mails pour votre domaine.
Cela vous permet de confirmer l'adresse de l'expéditeur et son lien avec le serveur ayant envoyé le message.
Si des courriels sont envoyés depuis votre domaine d'expéditeur, le destinataire peut vérifier s'ils proviennent d'un serveur SMTP que vous connaissez.
Il est recommandé de le configurer, car certains destinataires peuvent rejeter vos messages si le protocole SPF n'est pas du tout configuré.
Il existe deux approches différentes :
La configuration « souple » entraînera moins de rejets, voire aucun, de la part des destinataires.
La configuration « stricte » entraînera le rejet de certains messages si le serveur n'a pas été déclaré ou dans certains cas si le courriel a été redirigé ou envoyé via une liste de diffusion.
La configuration « rigide » donne au serveur de messagerie de destination plus de latitude pour décider d'accepter ou non le message ; c'est l'approche que nous suggérons.
La configuration SPF nécessite de savoir précisément quels serveurs vous utilisez pour envoyer des messages électroniques.
Avec RealSender, l'enregistrement TXT de votre domaine (example.com) doit contenir la chaîne
a:example.realsender.com et ressembler à ceci :
example.com TXT "v=spf1 a:example.realsender.com ~all" Avec HighSender, l'enregistrement TXT de votre domaine (exemple.com) doit contenir la chaîne
include:spf.realsender.com et ressembler à ceci :
example.com TXT "v=spf1 include:spf.realsender.com ~all" Ces outils vous aideront à valider la configuration :
www.kitterman.com/spf/validate.html *
récupère les enregistrements SPF pour le nom de domaine spécifié et détermine si l’enregistrement est valide
. Vérification SPF en ligne :
valide les paramètres SPF de votre messagerie lors de l’envoi d’un e-mail.
* = lien vers un site web externe, s'ouvrira dans une nouvelle page
Même si tout est correctement configuré, la vérification du message peut échouer
si le courriel a été redirigé (transféré) ou envoyé via une liste de diffusion.
Dans ces cas, pour garantir la cohérence de l'authentification des e-mails,
configurez le domaine de signature DKIM afin qu'il corresponde à l'adresse d'envoi.
Voir : Authentification des e-mails (niveau avancé ) » <dkim> alignment for dmarc.
spf@tester.realsender.comhttps://tester.realsender.com/spfLa vérification SPF en ligne de RealSender ajoutera un préfixe au sujet si le message n'a pas été correctement authentifié :
!! Échec SPF !! Le serveur SMTP n'est pas autorisé et le courriel doit être rejeté ou supprimé. !! Échec SPF partiel !! Le serveur SMTP n'est pas autorisé, mais ce cas doit être traité comme un échec partiel. !! Neutre SPF !! L'enregistrement SPF indique explicitement qu'aucune information ne peut être donnée concernant la validité. !! Aucun SPF !! Le domaine de l'expéditeur ne contient aucune information permettant d'authentifier le courriel Il arrive que les informations enregistrées au niveau du domaine soient incorrectes ou incompréhensibles.
!! spf-permerror !! Une erreur permanente s'est produite (par exemple, un enregistrement SPF mal formaté) !! spf-temperror !! Une erreur transitoire s'est produiteUne vérification SPF est effectuée sur l'adresse e-mail « Mail-From », qui est masquée dans les en-têtes du courriel.
Seule l'adresse e-mail « From » est visible. Si leurs domaines racines sont différents, l'avertissement suivant s'affiche :
!! spf-diff !! Les domaines racines « Mail-From » et « From » sont différentsSi le message réussit à la fois la vérification SPF ET la vérification d'alignement SPF pour DMARC (alignement relâché), vous obtiendrez :
|OK| Votre e-mail réussit le contrôle SPF et le contrôle d'alignement SPFSi un seul, SPF OU DKIM, réussit le contrôle d'alignement pour DMARC (alignement relâché),
le message est toujours considéré comme « OK » (de confiance) et le symbole ~ (tilde) est ajouté au début :
|~OK| Votre adresse e-mail passe le contrôle SPF (mais pas l'alignement) + vérification de l'alignement DKIM
DKIM est l'acronyme de DomainKeys Identified Mail, une norme d'authentification des e-mails
conçue pour garantir que l'e-mail (y compris les pièces jointes) n'a pas été modifié depuis l'apposition de la « signature ».
Il y parvient en apposant une signature numérique, liée à un nom de domaine, à chaque message électronique sortant.
Deux clés sont utilisées : une clé « publique » et une clé « privée » :
Lors de l'envoi d'un message, le serveur SMTP génère une « signature de hachage chiffrée », basée sur le contenu du message électronique et la clé privée.
Le système du destinataire peut vérifier la signature dans l'en-tête du courriel en la comparant au contenu du courriel et à la clé « publique » de l'expéditeur.
Les signatures DKIM ne sont pas immédiatement visibles pour les utilisateurs finaux ; elles sont ajoutées et vérifiées par l'infrastructure de messagerie.
Les serveurs SMTP de RealSender signent tous les messages électroniques sortants avec la signature DKIM.
RealSender signe initialement tous les messages sortants avec son propre domaine connecté au serveur SMTP ;
aucune configuration n'est nécessaire côté utilisateur/administrateur.
Pour obtenir l’«alignement de domaine DKIM pour DMARC»,
le message doit être signé avec le même domaine que l’expéditeur.
Avec RealSender, vous devez ajouter deux enregistrements CNAME
dans les paramètres DNS de votre domaine (exemple.com), comme ceux-ci :
clé1._domainkey.example.com CNAME clé1._domainkey.yourcompany.realsender.com clé2._domainkey.example.com CNAME clé2._domainkey.yourcompany.realsender.comCet outil vous aidera à valider la configuration :
toolbox.googleapps.com *
* = lien vers un site web externe, s'ouvrira dans une nouvelle page
Un message scellé DKIM ne peut pas être modifié, mais il peut toujours être lu par n'importe qui.
Un message signé qui ne passe pas la vérification est généralement rejeté.
Si aucune modification n'a été apportée entre l'expéditeur et le destinataire, cela ne devrait pas se produire.
Nous avons rencontré de rares cas, tous liés à la longueur des lignes (990 caractères maximum).
Certaines applications envoient le contenu sur une seule ligne ou transmettent une ligne très longue dans le code HTML.
Dans ces cas, la signature DKIM est corrompue, ce qui provoque l'erreur « dkim=fail » lors du contrôle.
dkim@tester.realsender.comhttps://tester.realsender.com/dkimLa vérification DKIM en ligne de RealSender ajoutera un préfixe de sujet si le message n'a pas été signé correctement :
!! dkim-none !! Aucun en-tête DKIM-Signature (valide ou invalide) n'a été trouvé !! dkim-fail !! Un en-tête DKIM-Signature valide a été trouvé, mais la signature ne contient pas de valeur correcte pour le message Il est parfois impossible d'effectuer la vérification :
!! dkim-invalid !! Un problème est survenu au niveau de la signature ou de l'enregistrement de clé publique. Autrement dit, la signature n'a pas pu être traitée. !! dkim-temperror !! Une erreur temporaire a été détectée, probablement de nature transitoire, comme par exemple une impossibilité temporaire de récupérer une clé publiqueLorsqu'un message est signé avec un domaine différent, une alerte « diff » est ajoutée à l'objet.
Cet avertissement ne s'affiche PAS si l'expéditeur réussit le contrôle SPF et l'alignement SPF pour DMARC.
!! dkim-diff !! Le message n'a PAS été signé par le domaine de l'expéditeurSi le message réussit à la fois la vérification DKIM ET la vérification d'alignement DKIM pour DMARC (alignement relâché), vous obtiendrez :
|OK| Votre adresse e-mail passe la vérification DKIM + la vérification d'alignement DKIMSi un seul, DKIM OU SPF, réussit le contrôle d'alignement pour DMARC (alignement relâché),
le message est toujours considéré comme « OK » (de confiance) et le symbole ~ (tilde) est ajouté au début :
|~OK| Votre adresse e-mail passe le contrôle DKIM (mais pas l'alignement) et le contrôle d'alignement SPFSujets abordés dans ce domaine :
Un mauvais alignement des domaines SPF peut entraîner l'échec du contrôle DMARC
Des domaines DKIM mal alignés peuvent entraîner l'échec de la vérification DMARC
Authentification, rapports et conformité des messages basés sur le domaine
Collecte en ligne des messages RUA et génération des rapports DMARC quotidiens
DMARC est une norme d'authentification des e-mails, développée pour lutter contre l'usurpation d'identité.
Pour l'alignement des domaines, elle exige que :
Lorsqu'un expéditeur authentifie son courriel à l'aide de SPF et/ou DKIM, au moins un des domaines doit correspondre au domaine d'envoiPour l'obtenir dans le cadre du SPF (Sender Policy Framework), vous devez gérer deux domaines :
DMARC propose deux types d'alignement SPF : l'alignement souple et l'alignement strict.
Si vous ne spécifiez pas d'alignement strict, l'alignement souple est utilisé par défaut.
Avec un alignement souple, seul le domaine racine de l'adresse Mail-From doit correspondre au domaine racine de l'adresse From.
L'alignement souple autorise l'utilisation de n'importe quel sous-domaine tout en respectant l'exigence d'alignement des domaines.
exemple:
Si votre domaine d'envoi est mail.abc.com et votre domaine d'expédition est abc.com,
votre e-mail passera le test d'alignement SPF (les domaines racines « abc.com » correspondent).
Si votre domaine d'envoi est abc.mail.com et votre domaine d'expédition est abc.com,
votre e-mail ne passera pas l'alignement SPF (les domaines racines « mail.com » et « abc.com » ne correspondent pas).
En cas d'alignement strict, le domaine de l'adresse Mail-From doit correspondre exactement au domaine de l'adresse From.
exemple:
Si votre domaine d'envoi est mail.abc.com et que votre domaine d'expédition est également mail.abc.com,
votre e-mail passera le test d'alignement SPF (les domaines « mail.abc.com » correspondent).
Si votre domaine d'envoi est mail.abc.com et votre domaine d'expédition est abc.com,
votre e-mail ne passera pas l'alignement SPF (les domaines « mail.abc.com » et « abc.com » ne correspondent pas).
DMARC est une norme d'authentification des e-mails, développée pour lutter contre l'usurpation d'identité.
Concernant l'alignement des domaines, elle exige que :
Lorsqu'un expéditeur authentifie son courriel à l'aide de SPF et/ou DKIM, au moins un des domaines doit correspondre au domaine d'envoiPour l'obtenir dans DKIM (DomainKeys Identified Mail),
le domaine de signature DKIM (DKIM-Signature : d=…) doit correspondre au domaine d'envoi.
DMARC autorise deux types d'alignement DKIM : l'alignement souple et l'alignement strict.
Si vous ne spécifiez pas d'alignement strict, l'alignement souple est utilisé par défaut.
Avec un alignement assoupli, seul le domaine racine de signature DKIM doit correspondre au domaine d'envoi.
L'alignement assoupli permet l'utilisation de n'importe quel sous-domaine tout en respectant l'exigence d'alignement des domaines.
exemple:
Si votre domaine de signature DKIM est mail.abc.com et votre domaine d'expéditeur est abc.com,
votre e-mail passera l'alignement DKIM (les domaines racines « abc.com » correspondent).
Si votre signature DKIM est abc.mail.com et que votre domaine d'expéditeur est abc.com,
votre e-mail ne passera pas l'alignement DKIM (les domaines racines « mail.com » et « abc.com » ne correspondent pas).
En cas d'alignement strict, le domaine de signature DKIM doit correspondre exactement au domaine de l'adresse d'envoi.
exemple:
Si votre domaine de signature DKIM est mail.abc.com et que votre domaine d'envoi est mail.abc.com,
votre e-mail passera l'alignement DKIM (les domaines « mail.abc.com » correspondent).
Si votre domaine de signature DKIM est mail.abc.com et votre domaine d'expéditeur est abc.com,
votre e-mail ne passera pas l'alignement DKIM (les domaines « mail.abc.com » et « abc.com » ne correspondent pas).
DMARC signifie : Authentification, rapport et conformité des messages basés sur le domaine.
Il s’agit d’une norme d’authentification des courriels, développée pour lutter contre l’usurpation d’identité par un nom de domaine.
Expéditeurs :
Récepteurs :
Avec certains fournisseurs de messagerie, cela influe considérablement sur la délivrabilité. Voir :
Comment DMARC fonctionne avec Google Mail et Office 365 en 2020. *
« Office 365 est généralement compatible avec l’authentification SPF et DKIM.
Pour garantir une délivrabilité optimale et une réception dans la boîte de réception, il est nécessaire d’associer ces authentifications à DMARC. »
* = lien vers un site web externe, s'ouvrira dans une nouvelle page
DMARC utilise SPF (Sender Policy Framework) et DKIM (Domain Keys Identified Emails)
pour gérer les situations où un e-mail échoue aux tests d'authentification.
Le protocole SPF exige que vous indiquiez les serveurs utilisés pour l'envoi de vos courriels.
Consultez la documentation relative à la configuration SPF pour en savoir plus et la paramétrer correctement.
Les serveurs SMTP de RealSender signent tous les courriels sortants avec la signature DKIM.
Une configuration est nécessaire si vous souhaitez signer avec le même domaine que l'expéditeur.
Consultez la documentation sur la configuration DKIM pour en savoir plus.
RealSender vous fournit une boîte aux lettres qui collecte les rapports DMARC générés par les destinataires.
_dmarc.example.com. EN TXT "v=DMARC1; p=none; rua=mailto:dmarc.example@rsbox.com"Dès le lendemain, vous recevrez les rapports DMARC RUA en ligne.
Il se peut que vous ayez oublié d'authentifier une campagne e-mail envoyée par un tiers.
Dans ce cas, authentifiez-la et vérifiez que le prochain envoi réussit les tests DMARC.
Lorsque les rapports seront corrects pendant quelques semaines, demandez aux fournisseurs de messagerie de rejeter/bloquer les courriels frauduleux/d'hameçonnage.
L'enregistrement TXT _dmarc de votre domaine devra être modifié comme suit :
"v=DMARC1 ; p=rejeter ; rua=mailto:dmarc.example@rsbox.com"Si votre organisation met en œuvre DMARC, vous devrez effectuer une vérification minutieuse
avant d'introduire toute nouvelle méthode d'envoi d'e-mails.
DMARC applique des politiques strictes concernant les tests SPF et DKIM ;
cela peut entraîner
le rejet par les fournisseurs de messagerie de courriels qui, autrement, réussiraient ces tests.
Même si tout est correctement configuré, la vérification peut échouer :
RealSender collecte et analyse pour vous les rapports dmarc rua(*).
* = rua signifiant : URI de rapport pour les données agrégées. Dans RealSender, le « rua » est l'adresse e-mail fournie aux clients,
à laquelle sont envoyés les rapports agrégés par les domaines
ayant reçu des e-mails prétendant provenir de votre domaine.
Les rapports sont générés chaque jour à 13h00 (CET) et contiennent les données des sept derniers jours.
Voici un exemple de rapport DMARC en ligne :
Sujets abordés dans ce domaine :
rapports détaillés par mois, jour, heure, hôte, e-mail de l'expéditeur
Journaux de courriels, notifications d'état de livraison (DSN), notifications de livraison réussie
Examinez les messages électroniques envoyés pour comprendre ce qui se passe
RealSender propose des rapports détaillés sur l'activité de chaque serveur SMTP et de chaque e-mail sortant.
Les données sont mises à jour automatiquement toutes les cinq minutes.
Sur demande, nous pouvons vous envoyer un résumé hebdomadaire par courriel.
Remarque : ces erreurs sont générées par des tentatives non autorisées d'envoi de courriels via le serveur
RealSender vous permet d'accéder via votre navigateur aux données des e-mails traités :
Les données affichées peuvent être enregistrées localement directement depuis le navigateur, ou automatiquement enregistrées à intervalles réguliers (par exemple une fois par jour), afin de conserver un historique.
31 mai 06:26:22 rs336 v4V4QL1K030027 : de=sender@yourcompany.com
31 mai 06:26:25 rs336 v4V4QL1K030027 : à=recipient@yourcustomer.com, dsn=2.0.0, stat=Envoyé (Message accepté pour livraison)
31 mai 08:58:04 rs336 v4V6w3jN001390 : de=sender@yourcompany.com
31 mai 08:58:05 rs336 v4V6w3jN001390 : à=recipient@yourcustomer.com, dsn=4.0.0, stat=Différé : 421 recipient@yourcustomer.com Service indisponible - réseau trop occupé
31 mai 09:02:03 rs336 v4V6w3jN001390 : à=recipient@yourcustomer.com, dsn=4.0.0, stat=Différé : 421 recipient@yourcustomer.com Service indisponible - réseau trop occupé
31 mai 09:12:42 rs336 v4V6w3jN001390 : à=recipient@yourcustomer.com, dsn=2.0.0, stat=Envoyé (Message accepté pour livraison)
31 mai 10:00:22 rs336 v4V80L9Z004176 : from=sender@yourcompany.com
31 mai 10:00:24 rs336 v4V80L9Z004176 : to=recipient@yourcustomer.com, dsn=4.7.1, stat=Deferred: 451 4.7.1 recipient@yourcustomer.com : Adresse du destinataire rejetée : Greylisting en cours, veuillez réessayer plus tard.
31 mai 10:02:03 rs336 v4V80L9Z004176 : to=recipient@yourcustomer.com, dsn=4.7.1, stat=Deferred: 451 4.7.1 recipient@yourcustomer.com : Adresse du destinataire rejetée : Greylisting en cours, veuillez réessayer plus tard.
31 mai 10:12:04 rs336 v4V80L9Z004176 : à=recipient@yourcustomer.com, dsn=2.0.0, stat=Envoyé (Message accepté pour livraison)
31 mai 16:17:14 rs336 v4VEHCk6017038 : de=sender@yourcompany.com
31 mai 16:17:15 rs336 v4VEHCk6017038 : à=recipient@yourcustomer.com, dsn=5.1.1, stat=Utilisateur inconnu
31 mai 16:17:15 rs336 v4VEHCk6017038 : v4VEHFk5017041 : DSN : Utilisateur inconnu
25 mai 12:43:37 rs336 v4PAhZw1019212 : de=sender@yourcompany.com
25 mai 12:43:38 rs336 v4PAhZw1019212 : à=recipient@yourcustomer.com, dsn=5.0.0, stat=Service indisponible
25 mai 12:43:38 rs336 v4PAhZw1019212 : v4PAhcw0019217 : DSN : Service indisponible
25 mai 09:17:41 rs336 v4P7Hc6P011481 : de=sender@yourcompany.com
25 mai 09:17:42 rs336 v4P7Hc6P011481 : à=recipient@yourcustomer.com, dsn=4.1.1, stat=Différé : 452 4.1.1 recipient@yourcustomer.com 4.2.2 Boîte aux lettres pleine
[…] le système réessaie la livraison toutes les dix minutes* […]
25 mai 13:25:47 rs336 v4P7Hc6P011481 : à=recipient@yourcustomer.com, dsn=4.1.1, stat=Différé : 452 4.1.1 recipient@yourcustomer.com 4.2.2 Boîte aux lettres pleine
25 mai 13:25:48 rs336 v4P7Hc6P011481 : v4PBPko0020848 : notification de l'expéditeur : Impossible d'envoyer le message pendant 4 heures*
* = voir la note à la fin du paragraphe suivant
Les courriels rejetés (par exemple, utilisateur inconnu) sont renvoyés à l'adresse électronique de l'expéditeur ou à l'adresse de retour (si elle est spécifiée).
En cas de retard dans la livraison des messages, vous recevrez un avertissement après 30 minutes*, comme ceci :
Objet : Avertissement : impossible d'envoyer le message depuis 30 minutes Corps du message : ********************************************** ** CECI EST UN MESSAGE D'AVERTISSEMENT UNIQUEMENT ** ** VOUS N'AVEZ PAS BESOIN DE RENVOYER VOTRE MESSAGE ** ********************************************** [...] Le système réessaiera automatiquement pendant quatre heures*. Si vous ne recevez plus de notifications, cela signifie que le message a bien été remis. Vous pouvez consulter les détails dans les journaux (voir les exemples mentionnés ci-dessus).
Après quatre heures* de tentatives infructueuses, une erreur définitive sera renvoyée à l'adresse électronique de l'expéditeur ou à l'adresse de retour (si elle est spécifiée), comme ceci :
Objet : Courrier retourné : voir la transcription pour plus de détails. Corps du message : Le message original a été reçu à… ----- Les adresses suivantes ont rencontré des erreurs fatales permanentes -----<recipient@yourcustomer.com> ----- Transcription de la session ci-dessous ----- Différé : Délai de connexion expiré avec votreclient.com. Le message n'a pas pu être remis pendant 4 heures. Le message sera supprimé de la file d'attente [...] * = lors de l'envoi de courriels en masse :
les notifications d'état de livraison retardée sont désactivées,
l'intervalle entre les tentatives de livraison est augmenté (de dix à trente minutes),
la durée maximale de présence dans la file d'attente est plus longue (de quatre à vingt-quatre heures).
Sur demande, nous pouvons activer la « notification de distribution » pour les courriels distribués avec succès. Ainsi, pour chaque message distribué, l'expéditeur recevra un accusé de réception du serveur de destination, comme celui ci-dessous. Cette option est utile pour ceux qui ont besoin d'un accusé de réception pour chaque courriel envoyé.
Objet : Accusé de réception Corps : Le message original a été reçu à ... ----- Les adresses suivantes ont reçu des notifications de livraison réussies -----<recipient@yourcustomer.com> (Message distribué avec succès dans la boîte aux lettres) ----- Transcription de la session ci-dessous -----<recipient@yourcustomer.com> ... Livraison réussie [...]Dans de rares cas (moins de 1 % des courriels envoyés), l'accusé de réception n'est pas transmis à l'expéditeur. Cela se produit si le destinataire a activé l'option « confidentialité / absence d'accusé de réception » sur son serveur de messagerie. Ce paramètre est généralement déconseillé car il bloque également l'envoi des notifications de non-distribution.
Parfois, pour comprendre ce qui se passe, il est nécessaire d'examiner les courriels qui ont été envoyés.
Sur demande, RealSender peut activer la copie automatique de tous les courriels sortants dans une boîte aux lettres dédiée.
La boîte mail est configurée pour recevoir un grand nombre de courriels rapidement et sans problème.
Les messages sont automatiquement supprimés après 7 jours.
Attention : si les messages sont envoyés depuis des comptes de messagerie personnels (même s’il s’agit de comptes professionnels),
vous devez informer l’expéditeur que les communications qu’il envoie peuvent être lues à des fins de vérification technique.
Afin de vérifier le bon fonctionnement du service,
nous avons activé un environnement de contrôle automatique.
Une application externe se connecte à chaque serveur SMTP toutes les dix minutes
et envoie un message. L'envoi réussi de ce message nous permet de garantir
la disponibilité et le bon fonctionnement du système.
Le résultat est publié sur la page « statut » de votre serveur RealSender,
accessible gratuitement à l’adresse web : rsXXX-realsender.com/status
Les données sont affichées en temps réel, comme l'illustre l'exemple ci-dessous.
Les informations présentées concernent les dernières 24 heures.
2024-09-11 06:25:26 UTC rsXXX - Vérification de disponibilité toutes les dix minutes (un e-mail a été envoyé avec succès) - OK 2024-09-11 06:16:18 UTC rsXXX - Vérification de disponibilité toutes les dix minutes (un e-mail a été envoyé avec succès) - OK 2024-09-11 06:05:56 UTC rsXXX - Vérification de disponibilité toutes les dix minutes (un e-mail a été envoyé avec succès) - OK 2024-09-11 05:55:41 UTC rsXXX - Vérification de disponibilité toutes les dix minutes (un e-mail a été envoyé avec succès) - OK 2024-09-11 05:45:57 UTC rsXXX - Vérification de disponibilité toutes les dix minutes (un e-mail a été envoyé avec succès) - OK 2024-09-11 05:35:58 UTC rsXXX - Vérification de disponibilité toutes les dix minutes VÉRIFICATION (un e-mail a été envoyé avec succès) - OK 2024-09-11 05:25:27 UTC rsXXX - toutes les dix minutes VÉRIFICATION DE DISPONIBILITÉ (un e-mail a été envoyé avec succès) - OK 2024-09-11 05:16:30 UTC rsXXX - toutes les dix minutes VÉRIFICATION DE DISPONIBILITÉ (un e-mail a été envoyé avec succès) - OK 2024-09-11 05:05:57 UTC rsXXX - toutes les dix minutes VÉRIFICATION DE DISPONIBILITÉ (un e-mail a été envoyé avec succès) - OK 2024-09-11 04:55:36 UTC rsXXX - toutes les dix minutes VÉRIFICATION DE DISPONIBILITÉ (un e-mail a été envoyé avec succès) - OK