Tout pour vos emails OVHcloud

Authentifier votre domaine à l’envoi

Pour que vos e-mails envoyés via OVH soient acceptés par les destinataires, authentifiez votre domaine avec SPF, DKIM et DMARC.

Configuration SPF (Sender Policy Framework)

SPF permet d’authentifier vos e-mails en déclarant les serveurs autorisés à envoyer pour votre domaine.

Lorsque c’est possible, SPF est configuré automatiquement à la création du service e-mail. En cas de configuration incorrecte, rendez-vous dans le Manager OVHcloud, sur la page de votre service e-mail, pour relancer la configuration automatique ; vous pouvez aussi configurer SPF vous-même dans la zone DNS de votre domaine.

Exemple d’enregistrement SPF pour OVH :

v=spf1 include:mx.ovh.net ~all

Recommandation : Utilisez ~all (softfail) pendant la phase de test, puis passez à -all (hardfail) une fois votre configuration validée.

Configuration DKIM (DomainKeys Identified Mail)

DKIM ajoute une signature cryptographique à vos e-mails pour prouver leur authenticité.

Lorsque c’est possible, DKIM est configuré automatiquement à la création du service e-mail. En cas de configuration incorrecte, rendez-vous dans le Manager OVHcloud, sur la page de votre service e-mail, pour relancer la configuration automatique : OVHcloud génère les clés et publie l’enregistrement DNS correspondant.

Configuration DMARC

DMARC combine SPF et DKIM pour fournir une politique de traitement des e-mails non authentifiés.

🚧 En cours. Une configuration DMARC standard recommandée est en cours d’élaboration. Elle n’est pas encore proposée, car les redirections et les listes de diffusion peuvent casser l’alignement DMARC : une politique trop stricte risquerait de faire rejeter des messages légitimes réacheminés.

ARC (Authenticated Received Chain)

ARC préserve les résultats d’authentification (SPF, DKIM, DMARC) lorsqu’un message transite par un intermédiaire qui le réachemine — typiquement une redirection (forward) ou une liste de diffusion. Ces intermédiaires modifient souvent le message ou l’enveloppe, ce qui casse SPF et l’alignement DMARC ; ARC permet au serveur final de constater que l’authentification était valide avant ce transit.

Vous n’avez rien à configurer. OVHcloud ajoute automatiquement la signature ARC sur les flux de réacheminement (forward) et de liste de diffusion qu’il traite.

Recommandations générales

• Les services e-mail d’OVH sont destinés à un usage de messagerie individuel. Les usages transactionnels et de communication sont tolérés mais limités en volumétrie.
• Maintenez un ratio faible de plaintes spam
• Implémentez une procédure de désinscription claire
• N’envoyez qu’à des destinataires ayant explicitement consenti — pas de listes achetées ni collectées
• Segmentez vos envois selon l’engagement des destinataires
• Surveillez votre réputation via les feedback loops
• Fractionnez vos envois en masse

Limites d’envoi

Vue d’ensemble

Note : Les limites horaire et journalière sont évaluées selon plusieurs critères : l’expéditeur, le destinataire, le couple expéditeur/destinataire et l’adresse IP d’envoi.

Important : Le dépassement des limites d’envoi peut entraîner un blocage temporaire de votre compte. En cas de besoin d’augmentation des limites, contactez notre équipe support.

Liste des adresses IP sortantes

🚧 En cours. Un travail de rationalisation des adresses IP d’envoi est en cours. La liste des plages IP n’est donc pas publiée pour le moment.

Si vous avez besoin d’autoriser (whitelist) les serveurs d’envoi OVHcloud, appuyez-vous sur des critères stables plutôt que sur des adresses IP figées :

• SPF — autorisez l’enregistrement SPF d’OVHcloud (include:mx.ovh.net).
• Reverse DNS (PTR) — les serveurs d’envoi ont un reverse se terminant par :
  • mail-out.ovh.net pour l’Europe ;
  • mail-out.ovh.ca pour le Canada.

Codes d’erreur SMTP

Voici les principaux codes de réponse SMTP que nos serveurs peuvent renvoyer, et la marche à suivre pour chacun :

Tout ce qui ne figure pas dans ce tableau provient de l’infrastructure mail située derrière le proxy et est transmis tel quel.

Délivrabilité des e-mails sortants

Chaque e-mail sortant fait l’objet d’une analyse anti-spam. Si un message est détecté comme SPAM, il n’est pas distribué.

En fonction de cette analyse anti-spam des e-mails sortants, le compte peut être bloqué.

Pour comprendre un blocage et le résoudre, consultez le guide OVHcloud : Compte verrouillé pour cause de spam.

Limites de réception

* Soumise à la limitation de débit anti-flood (voir ci-dessous).

Conditions d’acceptation :

• Reverse DNS obligatoire — seules les adresses IP disposant d’un enregistrement reverse (PTR) sont acceptées.
• Blocage manuel possible — un blocage manuel (IP, domaine ou expéditeur) peut être appliqué en cas d’abus.

Note : La réception n’est pas plafonnée en volume, mais reste soumise aux quotas de stockage de la boîte. Une boîte pleine refuse les nouveaux messages (voir codes SMTP 4xx/5xx). Une limitation de débit anti-flood s’applique néanmoins au trafic entrant (voir ci-dessous) : il s’agit d’une protection contre les arrivées massives, distincte de tout plafond de volume.

Limitation de débit à l’entrée (anti-flood)

Pour protéger ses serveurs et ses utilisateurs, OVHcloud applique une limitation de débit adaptative sur le trafic entrant. Le rythme d’arrivée des messages est suivi sur des fenêtres glissantes horaire et journalière, et la marge autorisée s’ajuste automatiquement au comportement de chaque source : un expéditeur régulier et conforme voit sa marge évoluer dans le temps, tandis qu’une arrivée massive et inhabituelle est ralentie.

Cette limitation est évaluée selon plusieurs critères, indépendamment les uns des autres : l’adresse de l’expéditeur, l’adresse du destinataire, le couple expéditeur/destinataire et l’adresse IP d’envoi.

Lorsque cette limite est momentanément atteinte, le message n’est pas rejeté définitivement : OVH répond par un code SMTP temporaire 4xx du type :

450 4.7.1 Rate limit due to high number of emails sent, retry later

Un serveur d’envoi conforme réessaie automatiquement un peu plus tard, et la distribution aboutit d’elle-même.

Côté expéditeur, pour éviter d’être ralenti :

• Respectez les codes temporaires 4xx et réessayez avec une temporisation progressive (ne traitez pas un 4xx comme un échec définitif).
• Lissez vos envois dans le temps plutôt que d’expédier de gros volumes d’un coup.
• Maintenez une réputation saine : authentification SPF/DKIM/DMARC, listes propres, faible taux de plaintes et de rebonds.

Politique de sécurité à la réception

À la réception d’un message, OVHcloud applique une série de contrôles de sécurité et d’authentification, portant à la fois sur la connexion entrante et sur le message lui-même.

Ce qu’OVH vérifie

• SPF (RFC 7208) — l’adresse IP émettrice est autorisée à envoyer pour le domaine de l’expéditeur.
• DKIM (RFC 6376) — la signature cryptographique du message est valide.
• DMARC (RFC 7489) — l’alignement SPF/DKIM est conforme à la politique publiée par le domaine.
• ARC (RFC 8617) — la chaîne d’authentification est préservée lorsque le message a transité par un intermédiaire (forwarder, liste de diffusion).
• Reverse DNS (PTR) (RFC 1912) — l’adresse IP de connexion dispose d’un enregistrement inverse.
• Chiffrement (RFC 3207) — la connexion SMTP entrante est établie en SSL/TLS.

Comment ces contrôles sont appliqués

• Reverse DNS — rejet strict. Une connexion provenant d’une IP sans reverse DNS est systématiquement rejetée. Un enregistrement PTR valide est un prérequis absolu pour livrer vers OVH.
• Autres contrôles — pas de rejet automatique. Un échec isolé sur SPF, DKIM, DMARC, ARC ou l’absence de chiffrement n’entraîne pas, à lui seul, un rejet systématique. Ces signaux sont intégrés à un ensemble de règles plus global (réputation de l’IP et du domaine, contenu du message, historique, blacklists…) qui détermine l’acceptation, la mise en quarantaine ou le rejet.

À retenir : soignez tous ces critères. Même sans rejet immédiat, des résultats d’authentification dégradés pèsent sur votre réputation et augmentent le risque de classement en spam ou de rejet ultérieur.

⚠️ Susceptible d’évoluer. Ces règles font partie d’un dispositif de sécurité qui évolue en permanence pour s’adapter aux menaces. Les comportements décrits ici peuvent être ajustés sans préavis.

Améliorer la délivrabilité vers OVH

Pour maximiser vos chances d’être accepté par le filtre anti-spam d’OVHcloud, suivez ces recommandations :

• Authentifiez vos e-mails — configurez SPF, DKIM, DMARC et ARC pour votre domaine.
• Limitez au maximum les destinataires inconnus — nettoyez régulièrement vos listes d’abonnés et tenez compte des erreurs précédentes (rebonds, plaintes, adresses invalides) pour ne plus réémettre vers des adresses qui échouent.
• Évitez les erreurs de transaction SMTP — respectez la séquence du protocole et traitez correctement les codes de réponse (voir la fiche « Codes SMTP »).
• Testez votre campagne avant d’envoyer des milliers d’e-mails — validez le rendu, les liens et l’authentification sur un petit échantillon.
• Soyez clair sur le contenu de l’e-mail — objet explicite, expéditeur identifiable, lien de désinscription visible ; évitez les pratiques trompeuses qui déclenchent les filtres.

Codes SMTP renvoyés lors d’un envoi vers OVH

Les réponses ci-dessous sont celles que les MX entrants d’OVHcloud renvoient réellement. Elles arrivent à deux moments distincts de la transaction SMTP :

• au RCPT TO, avant la transmission du corps du message — vous savez que le message est refusé avant de consommer de la bande passante sur DATA. C’est là que se produisent presque tous les rejets ;
• à l’END-OF-MESSAGE, une fois le corps déjà transmis — c’est là que s’applique la limitation de débit, la bande passante est donc consommée avant qu’on vous demande de revenir plus tard.

⚠️ Un 4xx d’OVH ne signifie pas toujours « réessayez et ça passera ». Par convention, un 4xx est temporaire et un 5xx permanent, mais les rejets les plus fréquents ici (reverse DNS absent, domaine expéditeur non résolvable, réputation de l’IP) sont renvoyés en 4xx pour une cause qui ne disparaîtra pas d’elle-même. Votre serveur réessaiera jusqu’à l’expiration de sa file d’attente, puis renverra le message en erreur à votre utilisateur. Corrigez la cause ; ne vous contentez pas de réessayer.

Rejets au RCPT TO

Un message accepté pour distribution reçoit un simple 250 2.0.0. Tout ce qui suit est un refus, classé du plus au moins fréquent. <expéditeur> et <destinataire> représentent l’adresse concernée par le rejet.

L’étape n’est pas la cause. Le serveur évalue les règles de connexion, de HELO et d’expéditeur, mais n’en restitue le verdict qu’au RCPT TO. Un rejet reçu sur RCPT TO peut donc concerner votre adresse IP ou votre expéditeur d’enveloppe, et pas du tout le destinataire. Lisez le texte de la réponse, pas la commande à laquelle elle répond.

Limites de protocole et autres refus

Au-delà des rejets ci-dessus, la configuration du serveur produit les réponses suivantes. Elles sont rares en trafic normal, mais chacune désigne une erreur précise côté client.

⚠️ Ne faites jamais de pipelining vers ces serveurs. La réponse à EHLO omet délibérément PIPELINING — ainsi que DSN et ETRN — et le serveur applique cette omission : un client qui envoie ses commandes en lot sans attendre chaque réponse est rejeté en 503 5.5.0. Attendez chaque réponse. ETRN est refusé et les demandes DSN ne sont pas honorées.

Rejet après le corps du message — limitation de débit

450 4.7.1 Rate limit due to high number of emails sent, retry later

Celui-ci est appliqué à l’END-OF-MESSAGE, après que votre serveur a transmis tout le message. Contrairement aux réponses 4xx ci-dessus, il est réellement temporaire : le débit d’arrivée pour votre adresse d’expéditeur, le destinataire, le couple expéditeur/destinataire ou votre IP est momentanément trop élevé, et réessayer plus tard avec un délai progressif finit par passer. Étalez vos envois dans le temps plutôt que de tout expédier d’un coup — voir la fiche « Limites de réception ».

Une transaction propre n’est pas une authentification propre

Un échec SPF, DKIM, DMARC ou ARC ne produit pas à lui seul une réponse de rejet : comme le décrit la politique de sécurité en réception, ces signaux alimentent votre réputation, et donc la décision ultérieure d’accepter, de mettre en quarantaine ou de rejeter. Une transaction qui se termine sur un 250 2.0.0 ne prouve donc pas que votre authentification est en ordre — vérifiez-la sur la fiche « Politique de sécurité » et avec l’outil de diagnostic de ce site.

Se connecter à une boîte OVHcloud

Pour configurer votre client de messagerie et vous connecter à votre boîte OVHcloud (webmail, IMAP / POP / SMTP, logiciels de messagerie), suivez le guide officiel OVHcloud :

👉 Documentation OVHcloud — Se connecter à sa messagerie