Thèmes abordés dans ce domaine :
les paramètres minimaux requis
Prenez le contrôle total de la réputation de vos e-mails
gérer ce qu'il advient de vos e-mails
vérifie automatiquement le bon fonctionnement des services toutes les dix minutes
Thèmes abordés dans ce domaine :
Présentation du Sender Policy Framework
Vérifiez la configuration SPF de votre adresse e-mail en envoyant un message électronique
Présentation de DomainKeys Identified Mail
Vérifiez la configuration DKIM de votre adresse e-mail 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éfinir quels sont les serveurs SMTP autorisés à envoyer des e-mails pour votre domaine.
Cela vous permet de vérifier l'adresse de l'expéditeur et sa relation avec le serveur qui a envoyé le message.
Si les e-mails sont envoyés avec votre domaine d'expéditeur, le destinataire peut vérifier s'ils proviennent d'un serveur SMTP que vous reconnaissez.
Il est recommandé de le configurer, car certains destinataires pourraient rejeter vos messages si le SPF n'est pas configuré du tout.
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, lorsque l'e-mail a été redirigé ou envoyé via une liste de diffusion.
La configuration « stricte » laisse au serveur de messagerie destinataire une plus grande latitude pour décider d'accepter ou non le message ; c'est l'approche que nous recommandons.
La configuration de SPF nécessite de connaître précisément les serveurs que vous utilisez pour envoyer des e-mails.
Avec RealSender, l'enregistrement TXT de votre domaine (exemple.com) doit contenir la chaîne
a:exemple.realsender.com et se présenter comme suit :
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 se présenter comme suit :
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 vos paramètres SPF de messagerie en envoyant un e-mail
* = lien vers un site web externe, s'ouvrira dans une nouvelle fenêtre
Même si tout est correctement configuré, la vérification du message peut échouer
si l'e-mail a été redirigé (transféré) ou envoyé via une liste de diffusion.
In these cases, to keep the email authentication consistent,
configure the dkim signature domain to be aligned with the sender’s From address.
See: email authentication advanced » <dkim> alignment for dmarc.
spf@tester.realsender.comhttps://tester.realsender.com/spfLa vérification SPF en ligne de RealSender ajoutera un préfixe à l'objet si le message n'a pas été authentifié correctement :
!! spf-fail !! Le serveur SMTP ne figure pas parmi les serveurs autorisés
et l'e-mail doit être rejeté ou supprimé
!! spf-softfail !! Le serveur SMTP ne figure pas parmi les serveurs autorisés
mais ce cas doit être traité comme un « softfail »
!! spf-neutral !! l'enregistrement SPF précise explicitement qu'aucune conclusion ne peut être tirée quant à la validité
!! spf-none !! le domaine de l'expéditeur ne contient aucune information permettant d'authentifier l'e-mail Il arrive parfois que les informations enregistrées au niveau du domaine ne soient pas correctes ou compréhensibles.
!! spf-permerror !! Une erreur permanente s'est produite (par exemple, un enregistrement SPF mal formaté)
!! spf-temperror !! Une erreur temporaire s'est produiteLa vérification SPF s'effectue par rapport à l'adresse e-mail « Mail-From », qui est masquée dans les en-têtes de l'e-mail.
Seule l'adresse e-mail « From » est visible. Si leurs domaines racines sont différents, cet avertissement s'affiche :
!! spf-diff !! Les domaines racines « Mail-From » et « From » sont différentsSi le message passe à la fois le contrôle SPF ET le contrôle d'alignement SPF pour DMARC (alignement assoupli), vous obtiendrez :
|OK| spf-pass Votre adresse e-mail passe le contrôle SPF et le contrôle d'alignement SPFSi l'un des deux, SPF OU DKIM, satisfait au contrôle de conformité DMARC (conformité assouplie),
le message est tout de même considéré comme « OK » (fiable) et le symbole ~ (tilde) est ajouté au début :
|~OK| spf-pass Votre adresse e-mail passe le contrôle SPF (mais pas celui de l'alignement) + contrôle 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 ».
Pour ce faire, il appose une signature numérique, associée à un nom de domaine, à chaque e-mail envoyé.
On utilise deux clés : 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 », calculée à partir du contenu du message électronique et de la clé privée.
Le système destinataire peut vérifier la signature figurant dans l'en-tête du courriel en la comparant au contenu du message 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 RealSender signent tous les e-mails sortants à l'aide de la signature DKIM.
RealSender signe d'emblée tous les messages sortants avec son propre domaine, associé au serveur SMTP
.
Aucune configuration n'est nécessaire de la part de l'utilisateur ou de l'administrateur.
Pour obtenir l'«alignement de domaine DKIM pour DMARC »,
le message doit être signé avec le même domaine que celui de l'expéditeur.
Avec RealSender, vous devez ajouter deux enregistrements CNAME
dans les paramètres DNS de votre domaine (exemple.com), comme suit :
key1._domainkey.example.com CNAME key1._domainkey.votreentreprise.realsender.com
key2._domainkey.example.com CNAME key2._domainkey.votreentreprise.realsender.comCet outil vous aidera à vérifier la configuration :
toolbox.googleapps.com *
* = lien vers un site web externe, s'ouvrira dans une nouvelle fenêtre
Un message signé par DKIM ne peut pas être modifié, mais il peut tout de même ê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é des cas exceptionnels, tous liés à la longueur des lignes (qui ne doit pas dépasser 990 caractères).
Certaines applications envoient le contenu sur une seule ligne ou transmettent une ligne très longue dans le code HTML.
Dans ces cas-là, la signature DKIM est corrompue, ce qui entraîne un résultat de vérification « dkim=fail ».
dkim@tester.realsender.comhttps://tester.realsender.com/dkimLa vérification DKIM en ligne de RealSender ajoutera un préfixe à l'objet si le message n'a pas été signé correctement :
!! dkim-none !! aucun en-tête DKIM-Signature (valide ou non) 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 arrive parfois que la vérification ne puisse pas être effectuée :
!! dkim-invalid !! Il y a un problème au niveau de la signature elle-même ou de l'enregistrement de la clé publique.
En d'autres termes, la signature n'a pas pu être traitée
!! dkim-temperror !! Une erreur a été détectée ; il s'agit probablement d'un problème temporaire,
tel qu'une impossibilité temporaire de récupérer une clé publiqueLorsque le message a été signé à l'aide d'un domaine différent, une alerte « diff » sera ajoutée à l'objet.
Cet avertissement ne s'affichera PAS si l'expéditeur passe avec succès 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 passe à la fois le contrôle DKIM ET le contrôle d'alignement DKIM pour DMARC (alignement assoupli), vous obtiendrez :
|OK| dkim-pass Votre adresse e-mail passe le contrôle DKIM et le contrôle d'alignement DKIMSi l'un des deux, DKIM OU SPF, satisfait au contrôle de conformité DMARC (conformité assouplie),
le message est tout de même considéré comme « OK » (fiable) et le symbole ~ (tilde) est ajouté au début :
|~OK| dkim-pass Votre e-mail a passé le contrôle DKIM (mais pas celui de la conformité) + contrôle de conformité SPFThèmes abordés dans ce domaine :
Des domaines SPF non alignés peuvent entraîner l'échec de la vérification DMARC
Un décalage entre les domaines DKIM peut entraîner l'échec de la vérification DMARC
Authentification, notification et conformité des messages basées sur le domaine
Collecte des messages RUA et génération quotidienne de rapports DMARC en ligne
DMARC est une norme d'authentification des e-mails, mise au point pour lutter contre les e-mails provenant de domaines usurpés.
Pour l'alignement des domaines, elle impose les conditions suivantes :
lorsqu'un expéditeur authentifie son e-mail à l'aide de SPF et/ou DKIM,
au moins l'un des domaines doit correspondre au domaine « De » de l'expéditeurPour respecter les règles du SPF (Sender Policy Framework), vous devez tenir compte de deux domaines :
DMARC prend en charge deux types d'alignement SPF : l'alignement souple et l'alignement strict.
Si vous ne spécifiez pas l'alignement strict, l'alignement souple est utilisé par défaut.
Avec l'alignement assoupli, seul le domaine racine de l'adresse « Mail-From » doit correspondre au domaine racine de l'adresse « From ».
L'alignement assoupli permet d'utiliser n'importe quel sous-domaine tout en respectant l'exigence d'alignement des domaines.
exemple :
Si votre domaine « Mail-From » est mail.abc.com et que votre domaine « From » est abc.com,
votre e-mail passera le contrôle d'alignement SPF (les domaines racines « abc.com » correspondent)
Si votre domaine « Mail-From » est abc.mail.com et que votre domaine « From » est abc.com,
votre e-mail ne passera PAS le contrôle d'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 à celui de l'adresse « From ».
exemple :
Si votre domaine « Mail-From » est mail.abc.com et que votre domaine « From » est également mail.abc.com,
votre e-mail passera le contrôle d'alignement SPF (les domaines « mail.abc.com » correspondent)
Si votre domaine « Mail-From » est mail.abc.com et que votre domaine « From » est abc.com,
votre e-mail ne passera PAS le contrôle d'alignement SPF (les domaines « mail.abc.com » et « abc.com » ne correspondent pas)
DMARC est une norme d'authentification des e-mails, mise au point pour lutter contre les e-mails provenant de domaines usurpés.
En ce qui concerne l'alignement des domaines, elle exige que :
lorsqu'un expéditeur authentifie son e-mail à l'aide de SPF et/ou DKIM,
au moins l'un des domaines doit correspondre au domaine « De » de l'expéditeurPour que cela fonctionne avec DKIM (DomainKeys Identified Mail),
le domaine de signature DKIM (DKIM-Signature: d=…) doit correspondre au domaine d'expédition (From).
DMARC prend en charge deux types d'alignement DKIM : l'alignement souple et l'alignement strict.
Si vous ne spécifiez pas l'alignement strict, l'alignement souple est utilisé par défaut.
Avec l'alignement assoupli, seule la racine du domaine de signature DKIM doit correspondre au domaine « From » de l'expéditeur.
L'alignement assoupli permet d'utiliser 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 que votre domaine « De » est abc.com,
votre e-mail passera le contrôle de cohérence 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 le contrôle d'alignement DKIM (les domaines racines « mail.com » et « abc.com » ne correspondent pas)
Pour que la correspondance soit stricte, le domaine de signature DKIM doit correspondre exactement au domaine de l'adresse « De » de l'expéditeur.
exemple :
Si votre domaine de signature DKIM est mail.abc.com et que votre domaine « De » est mail.abc.com,
votre e-mail passera le contrôle d'alignement DKIM (les domaines « mail.abc.com » correspondent)
Si votre domaine de signature DKIM est mail.abc.com et que votre domaine « De » est abc.com,
votre e-mail ne passera PAS le contrôle de cohérence DKIM (les domaines « mail.abc.com » et « abc.com » ne correspondent pas)
DMARC signifie : « Domain-based Message Authentication, Reporting and Conformance » (Authentification, rapport et conformité des messages basés sur le domaine).
Il s'agit d'une norme d'authentification des e-mails, mise au point pour lutter contre les e-mails provenant de domaines usurpés.
Expéditeurs :
Receveurs :
Chez certains fournisseurs de messagerie, cela a une incidence significative sur la délivrabilité ; voir :
Fonctionnement de DMARC avec Gmail et Office 365 en 2020 *
« Office 365 réagit généralement bien aux authentifications SPF et DKIM.
La seule façon d'obtenir des résultats constants et d'atteindre la boîte de réception est de les associer à DMARC »
* = lien vers un site web externe, s'ouvrira dans une nouvelle fenêtre
DMARC utilise les protocoles SPF (Sender Policy Framework) et DKIM (Domain Keys Identified Mail)
pour gérer les cas où un e-mail échoue aux tests d'authentification.
Le protocole SPF exige que vous indiquiez les serveurs que vous utilisez pour envoyer des e-mails.
Consultez les instructions de configuration du protocole SPF pour en savoir plus et le configurer correctement.
Les serveurs SMTP RealSender signent tous les e-mails sortants à l'aide de la signature DKIM.
Une configuration est nécessaire si vous souhaitez signer avec le même domaine que celui de l'expéditeur.
Consultez la procédure de configuration de DKIM pour en savoir plus.
RealSender met à votre disposition une boîte aux lettres qui recueille les rapports DMARC générés par les destinataires.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc.example@rsbox.com"Dès le lendemain, vous commencerez à recevoir les rapports DMARC RUA en ligne.
Vous pourriez vous rendre compte que vous avez oublié d'authentifier une campagne d'e-mails envoyée par un tiers.
Si cela se produit, il vous suffit de l'authentifier et de vérifier que le prochain envoi passe les tests DMARC.
Une fois que les rapports se seront confirmés pendant quelques semaines, demandez aux fournisseurs de messagerie de rejeter/bloquer ces e-mails usurpés ou de hameçonnage.
L'enregistrement TXT _dmarc de votre domaine doit être modifié pour ressembler à ceci :
« v=DMARC1 ; p=reject ; rua=mailto:dmarc.example@rsbox.com »Si votre organisation utilise le protocole DMARC, vous devrez consulter attentivement la page
avant de mettre en place toute nouvelle méthode d'envoi d'e-mails.
Dmarc applique des règles strictes concernant la manière dont les protocoles SPF et DKIM sont vérifiés
ce qui peut entraîner le rejet par les fournisseurs de messagerie de courriels qui, autrement, auraient satisfait à ces tests
.
Même si tout est correctement configuré, la vérification peut échouer :
RealSender collecte et analyse pour vous les rapports DMARC RUA(*).
* = Signification de « rua » :
URI de déclaration pour les données agrégées. Dans RealSender, la « rua » correspond à 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 tous les jours à 13 h (CET) et contiennent les données des sept derniers jours.
Voici un rapport DMARC en ligne, page d'exemple :
Thèmes abordés dans ce domaine :
rapports détaillés par mois, jour, heure, hôte et adresse e-mail de l'expéditeur
journaux des e-mails, notifications de statut de livraison (DSN), notifications de livraison réussie
examinez les e-mails qui ont été envoyés pour comprendre ce qui se passe
RealSender fournit des rapports détaillés sur l'activité de chaque serveur SMTP et des e-mails sortants.
Les données sont mises à jour automatiquement toutes les cinq minutes.
Sur demande, nous pouvons vous envoyer un récapitulatif hebdomadaire par e-mail.
Remarque : ces erreurs sont générées par des tentatives non autorisées d'envoi d'e-mails via le serveur
RealSender vous permet d'accéder via un navigateur aux données des e-mails traités :
Les données affichées peuvent être enregistrées localement directement depuis le navigateur, ou enregistrées automatiquement à intervalles réguliers (par exemple une fois par jour), afin de conserver un historique.
31 mai 06:26:22 rs336 v4V4QL1K030027 :from=sender@yourcompany.com
31 mai 06:26:25 rs336 v4V4QL1K030027 :to=recipient@yourcustomer.com, dsn=2.0.0, stat=Envoyé (Message accepté pour livraison)
31 mai 08:58:04 rs336 v4V6w3jN001390 :from=sender@yourcompany.com
31 mai 08:58:05 rs336 v4V6w3jN001390 :to=recipient@yourcustomer.com, dsn=4.0.0, stat=Deferred: 421 recipient@yourcustomer.com Service indisponible - trop occupé
31 mai 09:02:03 rs336 v4V6w3jN001390:to=recipient@yourcustomer.com, dsn=4.0.0, stat=Deferred: 421 recipient@yourcustomer.com Service indisponible - trop occupé
31 mai 09:12:42 rs336 v4V6w3jN001390:to=recipient@yourcustomer.com, dsn=2.0.0, stat=Sent (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 : liste grise activée, 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 : liste grise activée, veuillez réessayer plus tard
31 mai 10:12:04 rs336 v4V80L9Z004176:to=recipient@yourcustomer.com, dsn=2.0.0, stat=Sent (Message accepté pour livraison)
31 mai 16:17:14 rs336 v4VEHCk6017038 :from=sender@yourcompany.com
31 mai 16:17:15 rs336 v4VEHCk6017038 :to=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 :from=sender@yourcompany.com
25 mai 12:43:38 rs336 v4PAhZw1019212 :to=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 :from=sender@yourcompany.com
25 mai 09:17:42 rs336 v4P7Hc6P011481 :to=recipient@yourcustomer.com, dsn=4.1.1, stat=Deferred: 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 :to=recipient@yourcustomer.com, dsn=4.1.1, stat=Deferred : 452 4.1.1 recipient@yourcustomer.com 4.2.2 boîte aux lettres pleine
25 mai 13:25:48 rs336 v4P7Hc6P011481 : v4PBPko0020848 : notification à l'expéditeur : Impossible d'envoyer le message pendant 4 heures*
* = voir la note à la fin du paragraphe suivant
Les e-mails rejetés (par exemple, en raison d'un destinataire inconnu) sont renvoyés à l'adresse e-mail de l'expéditeur ou à l'adresse de retour (si elle est indiquée).
En cas de retard dans la transmission des messages, vous recevrez un avertissement au bout de 30 minutes*, comme ceci :
Objet :
Avertissement : impossible d'envoyer un message depuis 30 minutes
Corps du message :
**********************************************
** IL S'AGIT UNIQUEMENT D'UN MESSAGE D'AVERTISSEMENT **
** VOUS N'AVEZ PAS BESOIN DE RENVOYER VOTRE MESSAGE **
**********************************************
[...] Le système effectuera automatiquement de nouvelles tentatives pendant quatre heures*. Si vous ne recevez plus de notifications, cela signifie que le message a bien été transmis. Vous pouvez consulter les détails dans les journaux (voir les exemples mentionnés ci-dessus).
Après quatre heures* de tentatives infructueuses, un message d'erreur définitif sera envoyé à l'adresse e-mail de l'expéditeur ou à l'adresse de retour (si elle a été indiquée), comme suit :
Subject:
Returned mail: see transcript for details
Body:
The original message was received at ...
----- The following addresses had permanent fatal errors -----
<recipient@yourcustomer.com>
----- Transcript of session follows -----
Deferred: Connection timed out with yourcustomer.com.
Message could not be delivered for 4 hours
Message will be deleted from queue
[...] * = lors de l'envoi de mailings en masse :
les notifications de statut de livraison différée sont désactivées,
l'intervalle entre les tentatives de livraison est allongé (de dix à trente minutes),
la durée maximale de maintien dans la file d'attente est prolongée (de quatre à vingt-quatre heures)
Sur demande, nous pouvons également activer la « notification de livraison » pour les e-mails remis avec succès. Ainsi, pour chaque message remis, 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 e-mail envoyé.
Subject:
Return receipt
Body:
The original message was received at ...
----- The following addresses had successful delivery notifications -----
<recipient@yourcustomer.com> (successfully delivered to mailbox)
----- Transcript of session follows -----
<recipient@yourcustomer.com>... Successfully delivered
[...]Dans de rares cas (moins de 1 % des e-mails envoyés), l'accusé de réception n'est pas transmis à l'expéditeur. Cela se produit lorsque le destinataire a activé une option spéciale « confidentialité / pas d'accusés de réception » sur son serveur de messagerie. Ce paramètre n'est généralement pas recommandé, car il empêche également l'envoi des notifications standard de non-remise.
Parfois, pour comprendre ce qui se passe, il faut examiner les e-mails qui ont été envoyés.
Sur demande, RealSender peut activer la copie automatique de tous les e-mails sortants vers une boîte de réception dédiée.
La boîte mail est configurée pour pouvoir recevoir un grand nombre d'e-mails en peu de temps, sans aucun problème.
Les e-mails sont automatiquement supprimés au bout de 7 jours.
Attention : si les messages sont envoyés depuis des comptes de messagerie personnels (même s'il s'agit de comptes d'entreprise),
vous devez informer l'expéditeur que les communications qu'il envoie peuvent être consultées à des fins de vérification technique.
Afin de vérifier le bon fonctionnement du service
,
nous avons mis en place un environnement de contrôle automatique.
Une application externe se connecte à chaque serveur SMTP toutes les dix minutes
et envoie un véritable message. La réussite de l'envoi de cet e-mail nous permet de garantir
la disponibilité et le bon fonctionnement du système.
Le résultat est publié sur la « page d'état » de votre serveur RealSender,
librement accessible à l'adresse Web suivante : rsXXX-realsender.com/status
Les données s'affichent en temps réel, comme le montrent les exemples ci-dessous.
Les informations affichées concernent les dernières vingt-quatre heures.
11/09/2024 06:25:26 UTC
rsXXX - Vérification de disponibilité toutes les dix minutes (un e-mail a été envoyé avec succès) - OK
11/09/2024 06:16:18 UTC
rsXXX - Vérification de disponibilité toutes les dix minutes (un e-mail a été envoyé avec succès) - OK
11/09/2024 06:05:56 UTC
rsXXX- VÉRIFICATION DE DISPONIBILITÉ toutes les dix minutes (un e-mail a été envoyé avec succès) - OK
11/09/2024 05:55:41 UTC
rsXXX- VÉRIFICATION DE DISPONIBILITÉ toutes les dix minutes (un e-mail a été envoyé avec succès) - OK
11/09/2024 05:45:57 UTC
rsXXX - VÉRIFICATION DE DISPONIBILITÉ toutes les dix minutes (un e-mail a été envoyé avec succès) - OK
11/09/2024 05:35:58 UTC
rsXXX - VÉRIFICATION DE DISPONIBILITÉ toutes les dix minutes (un e-mail a été envoyé avec succès) - OK
11/09/2024 05:25:27 UTC
rsXXX - VÉRIFICATION DE DISPONIBILITÉ toutes les dix minutes (un e-mail a été envoyé avec succès) - OK
11/09/2024 05:16:30 UTC
rsXXX - VÉRIFICATION DE DISPONIBILITÉ toutes les dix minutes (un e-mail a été envoyé avec succès) - OK
11/09/2024 05:05:57 UTC
rsXXX - VÉRIFICATION DE DISPONIBILITÉ toutes les dix minutes (un e-mail a été envoyé avec succès) - OK
11/09/2024 04:55:36 UTC
rsXXX - VÉRIFICATION DE DISPONIBILITÉ toutes les dix minutes (un e-mail a été envoyé avec succès) - OK