# SMTP relay ou API : brancher WordPress à SendGrid, Mailgun ou Brevo

> Un site envoie trop d'emails transactionnels pour se reposer sur le serveur d'hébergement. Comparatif des deux façons de brancher WordPress à un service d'envoi tiers.

- Auteur : Clément Hadrot
- Publié le : 2021-05-08
- Mis à jour le : 2021-05-08
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/smtp-relay-ou-api-wordpress-sendgrid-mailgun-brevo/

## L’essentiel

- Le SMTP passe par un port souvent filtré ou lent
- L'API contourne le port SMTP mais dépend d'une librairie côté extension
- Le volume d'envoi oriente naturellement le choix

La boutique WooCommerce envoyait désormais plusieurs centaines d'emails transactionnels par jour : confirmations de commande, factures, relances de panier abandonné, notifications de stock. Compter sur le serveur mutualisé pour acheminer ce volume, avec une IP partagée entre dizaines de sites, n'était plus tenable en termes de délivrabilité. La décision de brancher WordPress à un service d'envoi tiers était prise ; restait à choisir la méthode de connexion : relais SMTP classique, ou intégration via l'API du fournisseur.

Ce choix se pose à chaque fois qu'un site bascule vers SendGrid, Mailgun, Brevo ou un service équivalent. Les deux méthodes atteignent le même objectif — sortir l'envoi transactionnel de l'infrastructure mutualisée — mais avec des contraintes techniques différentes qui méritent d'être connues avant de trancher.

## La voie SMTP : la plus universelle, pas la plus rapide

Le relais SMTP consiste à remplacer la fonction `mail()` de PHP, utilisée par défaut par `wp_mail()`, par une connexion authentifiée vers le serveur SMTP du fournisseur choisi, généralement via une extension comme WP Mail SMTP. La configuration se limite à quelques champs : hôte SMTP, port (587 ou 465 selon le chiffrement), identifiant et mot de passe ou clé API utilisée comme mot de passe.

```
define('WPMS_SMTP_HOST', 'smtp.sendgrid.net');
define('WPMS_SMTP_PORT', 587);
define('WPMS_SMTP_AUTH', true);
define('WPMS_SMTP_USER', 'apikey');
define('WPMS_SMTP_PASS', 'SG.xxxxxxxxxxxxxxxxxxxx');
```

Cette méthode a l'avantage d'être universelle : elle fonctionne avec n'importe quel fournisseur proposant un accès SMTP, sans dépendre d'une extension spécifique à ce fournisseur. Son principal inconvénient tient à l'infrastructure réseau elle-même : de nombreux hébergeurs mutualisés bloquent par défaut les connexions sortantes sur le port 587 ou 465, par mesure anti-spam préventive, ce qui oblige à une demande de déblocage auprès du support, pas toujours possible sur les offres d'entrée de gamme.

## La voie API : contourner le port, dépendre de la librairie

> L'essentiel à retenir : Le SMTP passe par un port souvent filtré ou lent ; L'API contourne le port SMTP mais dépend d'une librairie côté extension ; Le volume d'envoi oriente naturellement le choix

L'intégration par API repose sur un principe différent : au lieu d'ouvrir une connexion SMTP, l'extension envoie une requête HTTPS classique (port 443, quasiment jamais bloqué) vers l'API REST du fournisseur, qui se charge ensuite de l'envoi effectif de l'email. Cette méthode contourne entièrement la question du blocage de port SMTP, puisqu'elle utilise le même canal que n'importe quelle requête web sortante.

```
// Exemple de configuration API avec l'extension WP Mail SMTP
define('WPMS_SENDGRID_API_KEY', 'SG.xxxxxxxxxxxxxxxxxxxx');
define('WPMS_MAILER', 'sendgrid');
```

La contrepartie est une dépendance plus étroite à l'extension utilisée : le support de l'API d'un fournisseur donné n'est disponible que si l'extension l'a explicitement implémenté. Un changement de fournisseur d'envoi impose alors de vérifier que la nouvelle extension ou la nouvelle configuration prend bien en charge l'API du nouveau prestataire, alors qu'un simple relais SMTP se reconfigure en changeant seulement l'hôte, le port et les identifiants, quel que soit le fournisseur derrière.

## Comparer les deux approches sur les critères concrets

| Critère | SMTP relay | API |
| --- | --- | --- |
| Port réseau utilisé | 587 ou 465, souvent filtré | 443, rarement bloqué |
| Portabilité entre fournisseurs | Élevée, standard universel | Dépend du support de l'extension |
| Fonctionnalités avancées (statistiques, webhooks) | Limitées | Généralement plus riches via l'API native |
| Simplicité de configuration | Quelques champs standards | Clé API dédiée, configuration par fournisseur |

## Ce que le volume d'envoi doit trancher

Pour un site avec un volume d'emails transactionnels modeste, quelques dizaines par jour, le relais SMTP reste largement suffisant et présente l'avantage de rester interchangeable sans dépendance à une extension propriétaire. Dès que le volume grimpe significativement, comme sur cette boutique WooCommerce à plusieurs centaines d'envois quotidiens, l'API devient préférable : elle offre généralement un accès plus direct aux statistiques de délivrabilité (taux d'ouverture, rebonds, plaintes) exposées par le fournisseur, des informations précieuses pour surveiller la santé de la réputation d'envoi sur la durée.

- Volume faible, besoin de portabilité entre fournisseurs : privilégier le relais SMTP.
- Volume élevé, besoin de statistiques fines et de webhooks (accusés de réception, plaintes) : privilégier l'API.
- Hébergement mutualisé avec ports SMTP bloqués et impossibilité d'obtenir un déblocage : l'API s'impose de fait, indépendamment du volume.

> Notre choix par défaut sur les nouveaux projets reste l'API quand l'extension utilisée la supporte proprement : elle évite la dépendance à un port réseau capricieux d'un hébergeur à l'autre, ce qui simplifie sensiblement la maintenance sur le long terme.

## Pour aller plus loin

Ce comparatif ne couvre volontairement pas le diagnostic des enregistrements SPF, DKIM et DMARC, déjà traité séparément : que l'acheminement se fasse par SMTP ou par API, ces enregistrements DNS restent indispensables pour que les emails envoyés via le fournisseur choisi soient reconnus comme légitimes par les serveurs de messagerie destinataires.