L'envoi géré est le choix par défaut approprié, et le SMTP personnalisé constitue l'alternative. Avec l'envoi géré, un autre opérateur entretient la réputation IP, surveille les listes de blocage, traite les boucles de rétroaction et intervient si une IP partagée est répertoriée en pleine nuit. Pour la plupart des expéditeurs, cette formule est généralement préférable à une gestion autonome.
Le SMTP personnalisé achemine plutôt les messages sortants par votre propre compte Amazon SES, SendGrid, Mailgun ou Postmark. Il apporte un réel avantage dans trois situations précises, mais il est aussi souvent choisi pour deux raisons qui résistent mal à l'analyse.
Voici comment reconnaître votre situation et comment fonctionne le routage SMTP par domaine.
Ce que change réellement un SMTP personnalisé
Seul le trajet sortant change. Les messages entrants arrivent toujours sur nos serveurs grâce aux enregistrements MX, sont filtrés et rejoignent la même boîte. La différence concerne le dernier saut : au lieu de remettre le message à notre infrastructure d'envoi, nous nous authentifions auprès de votre fournisseur et le lui transmettons.
Tout ce qui suit dépend alors de lui : adresses IP, réputation, limites de débit, traitement des rejets et liste de suppression. Vous remplacez un opérateur par un autre et prenez en charge cette nouvelle relation.
Concrètement, les éléments suivants passent de votre côté :
| Sujet | Envoi géré | Votre SMTP |
|---|---|---|
| Réputation IP | Nous l'entretenons | Elle appartient à votre fournisseur et dépend de votre usage |
| Limites de débit | Plafonds quotidiens et horaires selon l'offre | Ce que votre fournisseur autorise |
| Rejets et plaintes | Traités et affichés dans le tableau de bord | Console et webhooks du fournisseur |
| Retrait des listes de blocage | Nous nous en chargeons | Vous le gérez avec votre fournisseur |
| Coût par message | Inclus | Facturé par votre fournisseur |
Trois bonnes raisons d'utiliser un SMTP personnalisé
1. Un volume supérieur à la vocation de l'offre. Les limites atteignent quelques milliers de messages par boîte et par jour. Pour plusieurs centaines de milliers de messages transactionnels par mois, un fournisseur spécialisé peut être moins cher et mieux adapté. Une plateforme de boîtes aux lettres n'est pas conçue pour les envois massifs.
2. Vous avez déjà cette relation. Si votre application envoie déjà reçus et réinitialisations de mot de passe par SES avec une IP dédiée préparée, y acheminer aussi la messagerie du personnel consolide la réputation. Cela réduit le nombre de composants et fournit une seule console pour analyser les incidents.
3. Vous utilisez Nano. Nano n'inclut pas l'envoi géré. Le SMTP personnalisé est donc la voie prévue pour envoyer des messages, et non un contournement.
Deux raisons peu convaincantes
« J'obtiendrai un meilleur acheminement. » Généralement non, et souvent l'inverse au début. Le pool partagé d'un fournisseur établi possède une réputation construite par des milliers d'expéditeurs. Un nouveau sous-compte SES n'en a aucune. Sans volume suffisant pour préparer et conserver une IP dédiée, vous échangez une bonne réputation existante contre une réputation à construire.
« Je veux contourner les limites d'envoi. » Ces limites existent parce qu'un volume élevé provenant d'un jeune domaine peut évoquer un compte compromis. Changer de route ne modifie pas la façon dont Gmail évalue un domaine qui envoie soudain dix mille messages. Le fournisseur appliquera sa propre montée en charge et pourra suspendre le compte si vous la dépassez, une situation plus difficile à corriger qu'une limitation de débit. Consultez les limites d'envoi et la préparation du domaine.
SMTP personnalisé par domaine et profils réutilisables
Le SMTP personnalisé se configure par domaine, ce qui est plus utile qu'il n'y paraît.
Chaque domaine possède sa propre route sortante. L'un peut relayer par SES, un autre utiliser l'envoi géré et un troisième choisir un autre fournisseur. Une agence peut ainsi respecter l'infrastructure exigée par un client sans modifier celle des autres.
Les identifiants sont enregistrés comme profils du compte plutôt que saisis par domaine. Ajoutez SES une fois, puis associez le profil à autant de domaines que nécessaire. Lors de la rotation, modifiez l'identifiant à un seul endroit. Le saisir six fois conduit souvent à cinq copies obsolètes.
Pour configurer le service, ouvrez l'onglet SMTP du domaine, choisissez un profil enregistré ou créez-en un avec le serveur, le port, l'utilisateur et le mot de passe, puis testez avant d'enregistrer. Le test ouvre une vraie session SMTP et s'authentifie. Ne l'omettez pas : un identifiant non testé risque d'échouer lors d'un envoi important.
La partie DNS rarement évoquée
Le SMTP personnalisé change les serveurs qui envoient pour votre domaine, et le DNS doit l'indiquer. Sinon, l'authentification des messages échoue.
SPF doit inclure le nouvel expéditeur. Votre fournisseur publie un mécanisme tel que include:amazonses.com, include:sendgrid.net ou un équivalent. Ajoutez-le à l'enregistrement existant, sans en publier un second. Deux enregistrements SPF sur un domaine constituent une configuration invalide.
Surveillez le budget de requêtes. SPF autorise dix requêtes DNS. Chaque inclusion en consomme au moins une, et celles des fournisseurs sont souvent imbriquées. L'ajout d'un troisième expéditeur peut faire dépasser la limite et produire une erreur permanente. Consultez la limite des requêtes SPF.
DKIM provient maintenant du fournisseur. Celui-ci signe les messages avec sa propre clé. Son enregistrement DKIM doit donc coexister avec le nôtre. La plupart fournissent deux ou trois CNAME à publier. Un message envoyé par eux mais signé uniquement par nous échoue à la vérification DKIM.
L'alignement DMARC doit toujours fonctionner. DMARC exige que SPF ou DKIM s'aligne sur le domaine From visible. Une configuration qui signe avec le domaine du fournisseur peut réussir DKIM mais échouer à l'alignement, puis à DMARC. C'est une cause fréquente d'échec lors d'une migration vers un SMTP propre, parfois invisible avant l'arrivée des rapports. Consultez l'alignement DMARC.
Les clients de bureau demandent une décision distincte
Le routage SMTP personnalisé s'applique aux messages rédigés dans le webmail ou envoyés par notre API. Un client de bureau transmet directement au serveur SMTP configuré.
Deux organisations sont raisonnables. Orientez les clients vers nous et laissez la route du domaine s'appliquer, afin de conserver un seul point de modification. Ou orientez-les directement vers le fournisseur pour supprimer un saut et réduire légèrement la latence.
Évitez de configurer certains clients d'une façon et les autres différemment. Deux trajets sortants produisent deux ensembles de résultats d'authentification et deux endroits où rechercher un message perdu.
Ce qui relève désormais de votre responsabilité
Traitement des rejets. Les rejets permanents doivent être supprimés chez votre fournisseur. Le tableau de bord montre ce que notre infrastructure observe, mais ne voit pas sa file d'attente.
La boucle de plaintes. Les plaintes pour spam vont au propriétaire de l'IP d'envoi. Configurez votre fournisseur pour les transmettre ou les conserver, puis consultez-les : un taux en hausse peut signaler tôt une dégradation de l'acheminement.
Rotation des identifiants. Un mot de passe SMTP expiré échoue au prochain envoi. Modifiez-le dans le profil et confirmez-le avec le bouton de test avant que les utilisateurs ne soient touchés.
Les propres règles du fournisseur. SES commence dans un bac à sable qui n'envoie qu'aux adresses vérifiées. Pour en sortir, il faut demander au support un accès en décrivant le cas d'usage. Mieux vaut le faire avant la migration.
Questions fréquentes
Le SMTP personnalisé change-t-il la réception des messages ?
Non. Seul le trajet sortant change. Les messages entrants arrivent toujours par MX sur nos serveurs et dans la même boîte, avec le même filtrage.
Différents domaines peuvent-ils utiliser différents fournisseurs SMTP ?
Oui. La configuration s'effectue par domaine : l'un peut utiliser SES et l'autre l'envoi géré. Les identifiants sont conservés dans des profils de compte réutilisables.
Le SMTP personnalisé améliorera-t-il l'acheminement ?
Pas à lui seul, et souvent l'inverse au début. Un nouveau sous-compte ne possède aucune réputation. Il peut aider si votre volume permet de préparer et conserver une IP dédiée, ou si vous consolidez une relation d'envoi déjà établie.
Ai-je encore besoin d'enregistrements SPF et DKIM ?
Plus qu'avant. L'inclusion SPF du fournisseur doit être fusionnée avec votre enregistrement et ses enregistrements DKIM publiés. Un message envoyé par lui et signé seulement par nous échoue à DKIM, tandis qu'une signature non alignée échoue à DMARC.
Le SMTP personnalisé supprime-t-il les limites d'envoi ?
Les limites du fournisseur remplacent les nôtres. Ses exigences de montée en charge sont souvent plus strictes, et leur dépassement peut suspendre le compte.
Que se passe-t-il si mon fournisseur est indisponible ?
Le courrier sortant des domaines utilisant cette route échoue jusqu'au rétablissement du service. L'envoi géré n'est pas un secours automatique : le domaine suit la route configurée.
Le SMTP personnalisé est-il obligatoire avec Nano ?
Oui. Nano n'inclut pas l'envoi géré. Le SMTP personnalisé est donc le moyen d'envoyer des messages avec cette offre.
Puis-je configurer le SMTP personnalisé par API ?
Oui. Les profils SMTP personnalisés et le routage par domaine sont disponibles dans l'API REST et via MCP, y compris le test de connexion.
