Ports SMTP en 2026 : choisir 587, 465… et éviter les pièges qui ruinent la délivrabilité

Sur un site web, on part souvent du principe que les emails vont “juste marcher” : soumissions de formulaires, réinitialisations de mot de passe, confirmations de commande, notifications admin, etc. Quand ces messages disparaissent (spam ou blocage silencieux), ce n’est pas un simple irritant : c’est une perte de leads, une expérience client dégradée et, au final, un vrai problème de confiance.

Dans la pratique, la cause est presque toujours la même : la configuration d’envoi d’emails par défaut du site – particulièrement sur WordPress – n’est pas faite pour une délivrabilité moderne face à Gmail, Outlook et consorts. Elle ressemble trop à un schéma d’envoi “non professionnel”, donc filtré comme du spam.

La voie la plus robuste consiste à court-circuiter ce système par défaut et à faire transiter les emails du site via un canal authentifié et réputé : SMTP (Simple Mail Transfer Protocol), le protocole standard d’acheminement des emails. Pour le mettre en place, il y a une question qui paraît anodine, mais qui conditionne tout : quel port SMTP utiliser en 2026 ?

À retenir (vraiment) avant de rentrer dans la technique

• Réponse rapide : utilise le port 587 avec un chiffrement STARTTLS. En 2026, c’est le standard moderne et recommandé pour l’envoi (submission) depuis un site ou un client mail.
• Alternative solide : le port 465 avec SMTPS (SSL/TLS implicite) est très courant et tout aussi sécurisé. Certains fournisseurs le préfèrent. Si 587 échoue, 465 est généralement le meilleur plan B.
• Port à éviter : n’utilise jamais le port 25 pour l’envoi (submission) depuis ton site. Il est non chiffré, historiquement prévu pour du serveur-à-serveur, et très souvent bloqué (FAI, hébergeurs, cloud) pour limiter le spam.
• Le vrai “pourquoi” : l’envoi par défaut côté WordPress (ex. wp_mail()) est non authentifié, et part d’un serveur web sans réputation email. Les filtres anti-spam le considèrent comme suspect.
• Le vrai “comment” : passe par un service SMTP transactionnel dédié (SendGrid, Brevo, Mailgun, etc.) pour relayer les emails via une infra authentifiée et réputée.
• Le bouton “facile” sur WordPress : un plugin “zéro configuration” comme Site Mailer by Elementor peut rerouter tes emails transactionnels via un fournisseur à forte délivrabilité sans gérer ports, clés API, SPF/DKIM, etc.
• Ne mélange pas tout : SMTP ici sert aux emails transactionnels (formulaires, commandes, mots de passe). Les newsletters / envois en masse doivent passer par une plateforme d’email marketing (ESP) dédiée pour protéger ta réputation d’envoi.

SMTP : ce que c’est et pourquoi ton site est concerné

SMTP (Simple Mail Transfer Protocol) est, en gros, le “bureau de poste” du web : le jeu de règles universel utilisé par les clients email (Outlook, Apple Mail…) et les serveurs mail pour expédier et relayer des messages.

Quand tu envoies un email, il ne va pas directement dans la boîte du destinataire. Le flux ressemble plutôt à ça :

1. Ton application (client mail ou site web) soumet le message à un serveur sortant (ex. smtp.gmail.com) : c’est l’étape de submission.
2. Ce serveur trouve ensuite le serveur du destinataire et relaye le message vers lui.
3. Le serveur du destinataire conserve le message jusqu’à la consultation de la boîte de réception.

SMTP couvre la submission et le relay. Et un port SMTP n’est rien d’autre que la “porte numérotée” sur laquelle ton application se connecte pour parler SMTP.

Le problème WordPress : wp_mail() (et pourquoi ça finit en spam)

Par défaut, WordPress n’utilise pas SMTP. Il s’appuie sur une fonction PHP (côté WordPress, wp_mail()) qui tente d’expédier les emails directement depuis le serveur web.

En termes de délivrabilité, c’est une recette à problèmes :

1. Ce n’est pas un serveur mail : un serveur web est optimisé pour servir du HTTP, pas pour gérer proprement l’envoi d’emails (files d’attente, politiques d’envoi, conformité, etc.).
2. Pas d’authentification : le serveur “prétend” envoyer au nom de ton domaine, sans mécanisme d’authentification robuste.
3. Aucune réputation : Gmail/Microsoft maintiennent des scores de réputation pour les serveurs d’envoi connus. Ton serveur web n’a pas de réputation email ou est vu comme expéditeur “inconnu”, donc suspect.
4. Mauvais voisinage IP : en mutualisé, tu partages souvent une IP avec des centaines de sites. Si un seul abuse (spam), l’IP peut être blacklistée et tes emails légitimes en pâtissent.

Résultat : les emails envoyés “en brut” depuis un serveur web sont facilement classés en spam, voire bloqués sans notification. La solution consiste à forcer WordPress à passer par un fournisseur SMTP transactionnel (via SMTP ou API) – et ça implique de choisir un port correct.

Petit historique des ports SMTP (et pourquoi plusieurs existent)

Comprendre quel port choisir, c’est aussi comprendre pourquoi les autres ont existé. L’histoire des ports SMTP, c’est surtout l’histoire d’Internet qui apprend à se défendre contre le spam.

Port 25 : l’original… et l’autoroute à spam

Au départ (1982), il y avait essentiellement le port 25. Sa vocation : permettre le relay entre serveurs mail (MTA, Mail Transfer Agents). C’était ouvert, simple, sans authentification. Dans l’Internet académique de l’époque, ça passait.

Le problème, c’est que ce modèle “ouvert” a été massivement exploité : n’importe qui pouvait se connecter à un serveur sur 25 et lui remettre des volumes énormes de spam, sans chiffrement ni contrôle sérieux.

Conséquence : aujourd’hui, la majorité des FAI, fournisseurs cloud et réseaux résidentiels bloquent les connexions sortantes sur le port 25, notamment pour empêcher des machines compromises (bots) et des serveurs détournés d’émettre du spam.

Port 465 : la première réponse chiffrée (SMTPS)

Fin des années 1990 : besoin de chiffrement. Le port 465 arrive avec SMTPS (SMTP over SSL), c’est-à-dire une connexion chiffrée dès le départ. On parle de TLS implicite (ou SSL/TLS implicite) : la négociation TLS démarre immédiatement, avant toute commande SMTP.

Le port 465 a été très adopté, même s’il n’a pas été, pendant un temps, le “standard officiel” IETF (l’organisme de standardisation). Il a même été brièvement considéré comme “déprécié” au profit d’une approche STARTTLS.

En pratique, il est revenu très fort : en 2026, 465 est une option sécurisée, acceptée et extrêmement courante. De gros acteurs (dont Gmail) le recommandent encore. Pour un site web, c’est un choix tout à fait valide.

Port 587 : le standard moderne (STARTTLS)

Pour clarifier et standardiser la submission (client/site → serveur mail), l’IETF a officiellement désigné le port 587 comme port de référence.

Le port 587 s’appuie généralement sur STARTTLS : on démarre en clair, puis on “upgrade” la connexion vers TLS. On appelle ça TLS explicite (Explicit TLS). Le déroulé ressemble à ceci :

1. Le site se connecte au serveur mail sur 587 en clair.
2. Il envoie une commande EHLO.
3. Le serveur répond avec les capacités disponibles, dont STARTTLS.
4. Le site envoie la commande STARTTLS pour basculer en TLS.
5. Le tunnel TLS est établi, et seulement ensuite on envoie identifiants et contenu du mail.

En 2026, un serveur qui n’impose pas le chiffrement sur 587 est considéré comme une configuration faible. Mais dans la grande majorité des cas, 587 + STARTTLS est le couple le plus universel et le plus attendu côté fournisseurs SMTP.

Port 2525 : le port de secours (non standard)

Tu verras parfois 2525. Ce n’est pas un port SMTP “officiel”. C’est un port alternatif mis à disposition par certains hébergeurs et fournisseurs SMTP pour contourner des restrictions réseau.

À utiliser quand 587 et 465 sont bloqués par l’environnement d’hébergement (c’est rare, mais ça existe). Souvent, 2525 fonctionne aussi avec STARTTLS, comme 587.

Verdict 2026 : quel port SMTP utiliser (et dans quel ordre)

1) Choix principal : port 587 (STARTTLS)

C’est le standard moderne pour la submission : largement supporté, pensé pour cet usage, et recommandé. Si tu configures un plugin SMTP WordPress, commence par 587 + STARTTLS (TLS).

2) Alternative recommandée : port 465 (SMTPS)

Si 587 ne passe pas (politique réseau, particularités du fournisseur, etc.) ou si ton provider le recommande explicitement (cas fréquent côté Gmail/Google Workspace), 465 + SMTPS (SSL/TLS implicite) est un excellent choix, très sécurisé et très répandu.

3) À éviter pour ton site : port 25

Le port 25 reste destiné au relay entre serveurs mail. Pour l’envoi depuis un site web, il est souvent bloqué et non chiffré : à ne pas utiliser.

Comparatif rapide des ports SMTP

Résumé sous forme de tableau pour garder une vue claire :

Port | Protocole | Sécurité | Usage courant | Recommandé pour un site ?
---- | --------- | -------- | ------------ | ------------------------
25   | SMTP      | Aucune   | Relay serveur-à-serveur | NON (souvent bloqué)
465  | SMTPS     | SSL/TLS implicite | Submission client/site → serveur | Oui (sécurisé & courant)
587  | SMTP      | STARTTLS (TLS explicite) | Submission client/site → serveur | OUI (standard recommandé)
2525 | SMTP      | STARTTLS (TLS explicite) | Submission (secours) | Uniquement si 587/465 bloqués

Port | Protocole | Sécurité | Usage courant | Recommandé pour un site ?
---- | --------- | -------- | ------------ | ------------------------
25   | SMTP      | Aucune   | Relay serveur-à-serveur | NON (souvent bloqué)
465  | SMTPS     | SSL/TLS implicite | Submission client/site → serveur | Oui (sécurisé & courant)
587  | SMTP      | STARTTLS (TLS explicite) | Submission client/site → serveur | OUI (standard recommandé)
2525 | SMTP      | STARTTLS (TLS explicite) | Submission (secours) | Uniquement si 587/465 bloqués

Corriger l’email WordPress : guide pas à pas

Maintenant que le choix du port est clair, reste à rendre l’envoi réellement fiable. Voici une procédure “standard” en 4 étapes qui marche dans la majorité des projets WordPress.

Étape 1 : choisir un fournisseur SMTP transactionnel dédié

Première décision : arrêter d’envoyer depuis le serveur web. Il faut un fournisseur d’email transactionnel (leur métier, c’est la délivrabilité).

Ce qu’ils fournissent : une infrastructure d’envoi réputée, utilisable via SMTP ou API, pour expédier les emails générés par ton site.

• SendGrid (très populaire, offre gratuite solide)
• Brevo (ex-Sendinblue)
• Mailgun
• Postmark (réputé pour une très haute délivrabilité)
• Amazon SES (puissant, mais plus complexe)
• Google Workspace / Gmail (possible pour de très faibles volumes, mais déconseillé en contexte business à cause de limites d’envoi)

Dans beaucoup de cas, les paliers gratuits suffisent largement pour les emails transactionnels d’un site vitrine ou d’un e-commerce de taille petite à moyenne.

Étape 2 : configurer le DNS du domaine (SPF & DKIM)

C’est l’étape technique la plus critique : tu dois prouver que ton fournisseur est autorisé à envoyer pour ton domaine. Cette autorisation se fait via des enregistrements DNS que ton provider te donne à copier-coller chez ton registrar (ou là où ton DNS est hébergé).

• SPF (Sender Policy Framework) : un enregistrement TXT qui agit comme une liste d’invités. Il indique quels serveurs/IP sont autorisés à envoyer des emails pour ton-domaine.tld. Objectif : empêcher l’usurpation (spoofing).
• DKIM (DomainKeys Identified Mail) : un ou plusieurs enregistrements TXT qui publient une clé publique. Le fournisseur signe chaque email avec une clé privée ; les serveurs de réception valident la signature avec la clé publique pour vérifier que le message n’a pas été altéré.

Étape 3 : installer et configurer un plugin SMTP sur WordPress

Il faut ensuite dire à WordPress d’utiliser ce nouveau canal. La méthode la plus simple passe par un plugin qui intercepte wp_mail() et reroute l’envoi vers ton fournisseur.

Plugins courants :

• WP Mail SMTP
• FluentSMTP
• Post SMTP

Le principe de configuration est similaire d’un plugin à l’autre. Voici les étapes générales :

1. Installer et activer le plugin SMTP choisi.
2. Ouvrir sa page de réglages dans l’admin WordPress.
3. Choisir le “Mailer” : sélectionner ton fournisseur (ex. SendGrid).
4. Renseigner les identifiants : – Option recommandée (API) : beaucoup de plugins préfèrent une clé API, plus fiable et plus sûre. – Option SMTP (identifiants) : via “Other SMTP”, en saisissant host/login/password.
5. Si tu es en mode SMTP (sans API), paramétrer : – SMTP Host : fourni par le provider (ex. smtp.sendgrid.net). – Encryption : choisir TLS (qui correspond à STARTTLS). Sinon, tu verras parfois SMTPS (qui correspond à SSL). – SMTP Port : 587 avec TLS/STARTTLS ou 465 avec SMTPS/SSL. – Authentication : activer. – SMTP Username : fourni par le provider. – SMTP Password : fourni par le provider.
6. Définir les informations “From” : – From Email : une adresse du domaine authentifié. – From Name : le nom du site/marque.

Étape 4 : tester, puis diagnostiquer avec méthode

Les bons plugins proposent un onglet “Test Email”. Envoie un message de test vers une adresse Gmail ou Outlook :

• Si ça arrive en boîte de réception : l’envoi est désormais authentifié et bien routé.
• Si ça arrive en spam : revérifie SPF/DKIM (et attends la propagation DNS, qui peut prendre quelques heures).
• Si l’envoi échoue : c’est souvent un problème de port ou d’identifiants. Revalide host/port/login/password. Si 587 échoue avec TLS, tente 465 avec SSL (ou l’inverse).

La solution “simple” : quand la plateforme prend en charge la délivrabilité

En tant que dev, le process en 4 étapes est simple sur le papier. Mais pour beaucoup de propriétaires de sites, il implique de jongler entre registrar DNS, provider SMTP et configuration WordPress. C’est précisément pour réduire cette friction que des solutions intégrées se sont popularisées.

Option 1 : email transactionnel intégré (le mode “zéro configuration”)

Le cœur du problème WordPress, c’est l’absence d’authentification et de réputation d’envoi. Une approche consiste à bypasser wp_mail() sans demander de configuration complexe à l’utilisateur final.

C’est l’objectif de Site Mailer by Elementor, présenté comme un plugin “zéro configuration” :

• Tu l’installes et tu l’actives, point.
• Il reroute automatiquement les emails transactionnels (formulaires, WooCommerce, resets de mot de passe, etc.) via un service à forte délivrabilité et authentifié.
• Tu n’as pas à créer un compte SendGrid, ni à gérer des clés API, ni à configurer SPF/DKIM, ni même à choisir un port : l’idée est que ça fonctionne immédiatement.

Option 2 : hébergement managé qui ne te bloque pas côté ports SMTP

L’autre source de friction, c’est l’environnement d’hébergement : certains stacks verrouillent des ports sortants pour limiter l’abus. Un hébergeur managé WordPress sérieux sait que wp_mail() est un problème et prépare une base saine pour travailler avec des services mail.

Des offres premium comme Elementor Hosting sont décrites comme construites sur une infrastructure cloud orientée performance, avec l’idée de faciliter ces bonnes pratiques (par exemple, s’assurer que des ports comme 587 sont disponibles pour un plugin SMTP).

Au-delà du SMTP : distinguer transactionnel et marketing (sinon tu vas te tirer une balle dans le pied)

Une fois l’envoi WordPress fiabilisé, il reste une règle essentielle : n’envoie pas tes newsletters via ton canal transactionnel.

Ton compte SendGrid / Brevo / Mailgun (ou une solution type Site Mailer) doit rester dédié aux emails transactionnels :

• Réinitialisations de mot de passe
• Confirmations de commande
• Messages liés aux formulaires (contact, devis, etc.)
• Inscriptions / création de compte
• Emails attendus et à forte priorité : ils doivent arriver en inbox

À l’inverse, les emails marketing sont des envois en masse (one-to-many) : newsletters, promos, annonces produit. Même si c’est opt-in, c’est statistiquement plus sujet aux désabonnements et plaintes spam.

Si tu pousses une newsletter à 10 000 personnes via ton canal transactionnel, tu vas mécaniquement augmenter les signaux négatifs (plaintes, taux de rejet), et dégrader la réputation d’envoi de ton domaine. Et quand la réputation tombe, ce sont tes emails critiques (ex. reset mot de passe) qui finissent en spam.

Conclusion opérationnelle : utilise une plateforme d’email marketing (ESP) dédiée pour les campagnes de masse, du type Mailchimp ou ConvertKit, qui gère séparément la réputation, les désinscriptions et les analytics.

Recommandation de stratégie email (version 2026)

Une stratégie email saine pour un site WordPress moderne tient en trois piliers :

1. Une base d’hébergement stable qui ne t’empêche pas d’appliquer les bonnes pratiques (et ne bloque pas arbitrairement tes besoins SMTP). Exemple cité : Elementor Hosting.
2. Une voix transactionnelle fiable : soit un plugin “zéro config” comme Site Mailer by Elementor, soit une config manuelle (WP Mail SMTP + fournisseur dédié) en priorité sur 587 + STARTTLS, avec 465 en alternative.
3. Un canal marketing professionnel via un ESP dédié (newsletters, promos), pour protéger la réputation d’envoi nécessaire aux emails transactionnels.

Conclusion : arrêter les emails fantômes, restaurer la confiance

La question “quel port SMTP choisir ?” est souvent le premier domino. En 2026, la réponse est simple : 587 en STARTTLS (et 465 en alternative très correcte). Mais l’enjeu réel est plus large : sortir WordPress de wp_mail() et basculer sur un envoi authentifié, réputé et suivi.

En mettant en place un fournisseur transactionnel, en configurant correctement le DNS (SPF/DKIM) et en branchant WordPress proprement (plugin SMTP ou solution intégrée), tu fais plus que “choisir un port” : tu sécurises un canal de communication critique, indispensable au fonctionnement normal d’un site.

FAQ

1) Réponse simple : quel port SMTP dois-je utiliser ?

Utilise le port 587 avec un chiffrement STARTTLS. Si ça ne fonctionne pas, essaie le port 465 avec SMTPS (SSL/TLS).

2) Pourquoi ne faut-il pas utiliser le port 25 ?

Le port 25 est le port historique (1982), non chiffré, massivement utilisé pour le spam. Il est aujourd’hui bloqué par la plupart des FAI résidentiels et par beaucoup d’acteurs du cloud hosting, donc il ne convient pas à l’envoi depuis un site.

3) Différence entre 587 (STARTTLS) et 465 (SMTPS) ?

Les deux sont sécurisés. 465 utilise du TLS implicite (connexion chiffrée dès l’ouverture). 587 utilise du TLS explicite (commande STARTTLS pour upgrader une connexion initialement en clair). En 2026, 587 est le standard recommandé, mais 465 est très courant et fiable.

4) C’est quoi un “email transactionnel” ?

C’est un email one-to-one déclenché par une action utilisateur sur ton site : soumission de formulaire, demande de reset mot de passe, inscription, confirmation de commande e-commerce, etc. Ce sont des emails attendus et prioritaires, à envoyer via un service SMTP transactionnel dédié.

5) Différence entre transactionnel et marketing ?

Le marketing est du one-to-many (newsletter, promos, annonces). Il doit passer par une plateforme dédiée (ESP) pour ne pas détériorer la réputation d’envoi qui garantit la réception des emails transactionnels.

6) SPF et DKIM : c’est indispensable ?

Oui. Ce sont des enregistrements DNS qui prouvent la légitimité de l’envoi. SPF liste les serveurs autorisés à envoyer pour ton domaine. DKIM ajoute une signature vérifiable qui prouve que le message n’a pas été altéré. Sans eux, tes emails auront un profil “spam”.

7) Mon plugin SMTP me demande un “Host”. C’est quoi ?

Le “Host” est l’adresse du serveur SMTP de ton fournisseur. Exemples : smtp.sendgrid.net pour SendGrid, smtp.gmail.com pour Google. Ton provider te donne la valeur exacte.

8) Puis-je utiliser mon compte Gmail perso pour envoyer les emails du site ?

Techniquement oui, mais ce n’est pas une bonne idée : tu risques d’exposer des identifiants dans l’admin WordPress (risque sécurité) et Google impose des limites d’envoi. En cas de pic de trafic, l’envoi peut être temporairement bloqué. Un fournisseur transactionnel dédié est plus adapté.

9) Méthode la plus simple pour régler les problèmes email WordPress ?

Utiliser un plugin “zéro configuration” comme Site Mailer by Elementor : installation en un clic et reroutage automatique des emails transactionnels sans config de ports, d’API keys ou de DNS.

10) Comment tester si ma config SMTP fonctionne ?

La plupart des plugins SMTP sérieux (ex. WP Mail SMTP) ont un onglet “Test Email”. Envoie un message de test depuis le dashboard vers une adresse personnelle (Gmail/Outlook). Si ça arrive en inbox, c’est OK. Si ça échoue : vérifie ports/identifiants. Si ça arrive en spam : revérifie SPF/DKIM et la propagation DNS.