Le relais SMTP CritSend : configuration et délivrabilité

Serveur data center avec câbles réseau et écran affichant une configuration SMTP

Sommaire

Chargement du sommaire…

Checklist configuration relais SMTP CritSend

Cochez chaque étape pour garantir une délivrabilité optimale.

Temps de lecture estimé : 12 minutes

Points clés à retenir

  • Utilisez le port 587 avec STARTTLS pour toutes vos connexions CritSend.
  • SPF + DKIM + DMARC sont obligatoires : sans eux, -30 % de délivrabilité.
  • Testez avec openssl avant tout envoi réel pour valider la connexion.
  • Gérez les bounces via webhooks et maintenez un taux inférieur à 3 %.
  • Attendez 48 h après un changement DNS avant de lancer une grosse campagne.

Qu’est‑ce qu’un relais SMTP CritSend et pourquoi l’utiliser

Définition précise du relais SMTP

Un relais SMTP CritSend est un serveur intermédiaire qui prend en charge l’acheminement de vos e-mails depuis votre application ou serveur vers les boîtes de destination finales. Plutôt que de gérer vous-même la réputation IP, les files d’attente et les réessais, vous déléguez ce travail à CritSend.

Regardons cela de plus près : sans relais dédié, un serveur mail auto-hébergé se retrouve souvent blacklisté en quelques semaines. La délivrabilité chute de 30 % en moyenne dès que SPF et DKIM manquent à l’appel, selon les benchmarks du secteur. Un relais professionnel corrige ça structurellement.

Cas d’usage typiques

Les newsletters et les e-mails transactionnels (confirmations de commande, réinitialisations de mot de passe, alertes système) sont les deux grands usages. Dans mon expérience, c’est surtout sur le transactionnel que le gain est immédiat : un e-mail de validation qui arrive en spam, c’est un utilisateur perdu.

Les équipes DevOps l’utilisent aussi pour les notifications de monitoring, où la fiabilité prévaut sur le volume. CritSend absorbe les pics sans que vous ayez à dimensionner votre propre infrastructure mail.

Différences entre relais SMTP et API d’envoi

Le relais SMTP s’intègre via le protocole standard : votre application configure un hôte, un port, des identifiants, et envoie comme elle le ferait vers n’importe quel serveur. L’API d’envoi, elle, passe par des requêtes HTTP avec un SDK ou des appels REST.

Le relais convient aux stacks existantes (Postfix, PHPMailer, applications legacy) sans modifier le code métier. L’API est préférable pour des pipelines modernes qui veulent des webhooks de tracking granulaires dès le départ.

Checklist config relais SMTP CritSend : 1. Compte et identifiants, 2. Configuration SMTP, 3. SPF, DKIM, DMARC, 4. Test de connexion, 5. Monitoring actif

Prérequis avant la configuration chez CritSend

Compte, clés et limites de quota

Avant de toucher à la moindre configuration, créez votre compte CritSend et récupérez vos identifiants SMTP (username et mot de passe ou token). Notez votre quota mensuel : un plan pro peut inclure 25 000 e-mails par mois à titre d’exemple. Vérifiez votre contrat, car dépasser ce seuil entraîne soit un blocage, soit une facturation supplémentaire.

Prévoyez aussi de valider votre domaine d’envoi dans l’interface CritSend avant de passer à la DNS. Sans cette étape, les vérifications suivantes échoueront.

Informations DNS nécessaires

Vous aurez besoin d’accès à votre gestionnaire DNS (OVH, Cloudflare, Gandi…) pour ajouter des enregistrements TXT et CNAME. Identifiez à l’avance le domaine d’envoi exact (ex. : notifications.votresite.fr) et le domaine racine associé.

Rassemblez aussi les valeurs SPF et DKIM que CritSend vous fournit dans son dashboard. Ces chaînes seront collées telles quelles dans vos enregistrements DNS.

Formats d’authentification acceptés

CritSend accepte les mécanismes LOGIN et PLAIN sur TLS/STARTTLS. En pratique, utilisez toujours STARTTLS sur le port 587. Le port 465 (SSL direct) fonctionne également, mais le port 25 est réservé aux échanges serveur-à-serveur et souvent bloqué par les FAI sur les hébergements mutualisés.

Configuration pas à pas du relais SMTP CritSend

Paramètres SMTP essentiels

Voici les 3 ports SMTP usuels et leurs usages :

Port Chiffrement Usage recommandé
25 Aucun / STARTTLS Relais serveur-à-serveur (souvent bloqué)
465 SSL/TLS direct Clients légacy qui imposent SSL immédiat
587 STARTTLS Recommandé pour applications et scripts

L’hôte SMTP CritSend est généralement du type smtp.critsend.com — consultez votre dashboard pour l’adresse exacte de votre compte.

Exemple de configuration dans Postfix

Dans /etc/postfix/main.cf, ajoutez ou modifiez ces lignes :

relayhost = [smtp.critsend.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
smtp_tls_security_level = encrypt

Créez ensuite /etc/postfix/sasl_passwd :

[smtp.critsend.com]:587   votre_username:votre_mot_de_passe

Puis hashez le fichier et rechargez Postfix :

postmap /etc/postfix/sasl_passwd
systemctl reload postfix

Exemple de configuration en PHPMailer

Pour une intégration PHP, PHPMailer reste la référence. Voici un extrait fonctionnel :

$mail = new PHPMailer\PHPMailer\PHPMailer(true);
$mail->isSMTP();
$mail->Host       = 'smtp.critsend.com';
$mail->SMTPAuth   = true;
$mail->Username   = 'votre_username';
$mail->Password   = 'votre_mot_de_passe';
$mail->SMTPSecure = PHPMailer\PHPMailer\PHPMailer::ENCRYPTION_STARTTLS;
$mail->Port       = 587;

Pour ma part, je conseille de stocker les identifiants dans des variables d’environnement plutôt que de les écrire en dur dans le code — une habitude qui évite les fuites dans les dépôts Git.

Vérifications DNS et authentification (SPF, DKIM, DMARC)

Enregistrement SPF à écrire pour CritSend

Le SPF autorise CritSend à envoyer au nom de votre domaine. L’enregistrement TXT à placer sur votre domaine ressemble à :

v=spf1 include:spf.critsend.com ~all

Si vous avez déjà un enregistrement SPF, ne créez pas un second enregistrement : fusionnez les include: dans une seule ligne. Un domaine avec deux enregistrements SPF est invalide selon la RFC 7208.

La propagation DNS prend 10 à 30 minutes pour des petits TTL, jusqu’à 48 heures sur des zones mal configurées. Attendez avant de lancer vos campagnes.

Mise en place DKIM : clé publique et enregistrement TXT

CritSend génère une paire de clés DKIM depuis son interface. La clé privée reste sur leurs serveurs ; vous publiez la clé publique en 2048 bits (longueur recommandée pour la sécurité) dans un enregistrement TXT de type :

selector._domainkey.votredomaine.fr   TXT   "v=DKIM1; k=rsa; p=MIIBIjAN..."

Remplacez selector par celui fourni par CritSend. Vérifiez la présence de la clé avec :

dig TXT selector._domainkey.votredomaine.fr

Planifiez une rotation de clé tous les 6 à 12 mois : publiez le nouveau sélecteur, attendez 48 heures, puis retirez l’ancien.

DMARC : politique recommandée

Sans DMARC, SPF et DKIM existent mais personne ne sait quoi faire en cas d’échec. Commencez par une politique permissive :

_dmarc.votredomaine.fr   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

Après 2 à 4 semaines d’analyse des rapports, passez à p=quarantine puis p=reject. C’est la progression classique pour ne pas casser les envois légitimes pendant la phase de rodage.

Tests d’envoi et suivi

Tester la connexion SMTP depuis le serveur

Avant tout envoi réel, testez la connexion avec OpenSSL (préférable à telnet pour STARTTLS) :

openssl s_client -connect smtp.critsend.com:587 -starttls smtp

Si la connexion s’établit, vous verrez la bannière du serveur et pourrez échanger des commandes SMTP manuelles (EHLO, AUTH LOGIN…). Un timeout ou un Connection refused indique un blocage firewall côté hébergeur.

Lire les logs Postfix pour diagnostiquer

Les erreurs SMTP apparaissent dans /var/log/mail.log ou /var/log/maillog selon la distribution. Filtrez sur votre domaine :

grep critsend /var/log/mail.log | tail -50

Les codes 4xx sont des erreurs temporaires (quota, throttle) — Postfix réessaiera. Les 5xx sont des refus définitifs qui exigent votre intervention.

Outils de scoring et boîtes de test

Envoyez un e-mail test vers une adresse Mail-Tester (mail-tester.com) pour obtenir un score sur 10 couvrant SPF, DKIM, DMARC, contenu et réputation. Ciblez au minimum 80 % d’acceptation en inbox sur Gmail et Outlook avant de lancer une campagne en volume.

Résolution des problèmes fréquents

Rejets 550 / 554 : causes et corrections

Un rejet 550 signifie que le serveur destinataire refuse le message. Souvent parce que votre IP ou domaine est blacklisté, ou que SPF échoue. Vérifiez votre statut sur MXToolbox Blacklist Check. Un 554 (« transaction failed ») traduit en général un filtre antispam déclenché côté destinataire.

En résumé : consultez d’abord le texte exact du rejet dans vos logs avant de chercher la cause — le message d’erreur cite presque toujours la raison précise.

Erreurs d’authentification et certificats TLS

Si Postfix remonte SASL authentication failed, vérifiez en premier que le fichier sasl_passwd a bien été hashé avec postmap après modification. Un mot de passe contenant des caractères spéciaux peut nécessiter des guillemets dans le fichier.

Pour les erreurs TLS (certificate verify failed), assurez-vous que votre OS dispose des CA racines à jour (ca-certificates sur Debian/Ubuntu). CritSend utilise des certificats signés par des autorités publiques reconnues.

Quotas et limitations : que faire en cas de blocage

Quand votre quota mensuel est atteint, CritSend retourne généralement un 452 ou 550 spécifique. Ne multipliez pas les tentatives : mettez vos envois en pause, contactez le support CritSend pour augmenter le quota ou passez à un plan supérieur.

Les réessais répétés après blocage quota peuvent aggraver votre réputation IP. Postfix gère ça nativement si vous ne forcez pas les renvois manuellement.

Bonnes pratiques d’envoi avec CritSend

Gestion des listes : bounces et suppressions

Un taux de bounces entre 1 et 3 % est acceptable sur une liste de qualité. Au-delà, les FAI interprètent ça comme du spam sur liste achetée. Configurez les webhooks CritSend pour récupérer les bounces en temps réel et les supprimer automatiquement de vos listes.

Pour aller plus loin, maintenez une liste de suppression globale (unsubscribes + bounces durs) que vous synchronisez à chaque envoi. Cette hygiène de liste est souvent négligée, alors qu’elle impacte directement la délivrabilité long terme.

Cadence d’envoi et gestion des retours

Sur un nouveau domaine ou une nouvelle IP, montez en volume progressivement : 500 e-mails le premier jour, 2 000 le deuxième, etc. Ce warm-up établit une réputation positive avant les gros volumes.

Implémentez un backoff exponentiel dans votre code pour les erreurs temporaires : si CritSend répond 421 (service temporairement indisponible), attendez 5 minutes, puis 15, puis 30 avant de réessayer.

Monitoring et alerting

Les 5 métriques clés à surveiller sont : taux de délivrabilité, taux d’ouverture, taux de bounce dur, taux de plaintes spam et latence d’envoi. Configurez des alertes quand le taux de délivrabilité descend sous 95 % ou que les plaintes dépassent 0,1 %.

Pour valider votre configuration avant chaque campagne importante, adoptez cette checklist en 5 étapes : vérification SPF, DKIM et DMARC actifs → test d’envoi Mail-Tester → lecture des logs → contrôle quota disponible → mise en place du monitoring.

Coûts, SLA et alternatives

Modalités tarifaires et SLA

CritSend propose généralement plusieurs plans selon le volume mensuel. La disponibilité cible d’un service mail professionnel est de 99,9 % — vérifiez que votre contrat inclut un SLA écrit avec compensation en cas d’indisponibilité, pas seulement un engagement marketing.

Consultez la page tarifaire officielle CritSend pour les prix à jour : les grilles évoluent régulièrement et toute donnée ici serait périmée rapidement.

Quand préférer l’API au relais SMTP

Si votre application est en Node.js, Python ou Go et que vous construisez un pipeline d’envoi moderne, l’API HTTP offre des avantages concrets : webhooks de tracking natifs, gestion des templates côté plateforme, intégration plus propre dans des architectures microservices.

Le relais SMTP reste préférable pour les applications legacy, les scripts shell, les CMS comme WordPress (via plugins SMTP), ou n’importe quel système où modifier le transport mail est coûteux en développement.

Alternatives courantes

Service Point fort Limit principale
Mailgun API très complète, logs détaillés Tarif élève sur gros volumes
SendGrid Écosystème large, délivrabilité solide Interface complexe à prendre en main
Amazon SES Coût très bas à volume élevé Configuration technique plus exigeante
Brevo (ex-Sendinblue) Plan gratuit généreux, RGPD EU Délivrabilité variable sur les niveaux bas

Le choix entre ces alternatives dépend avant tout de votre volume, de votre stack technique et de la granularité de reporting dont vous avez besoin. Sur les projets que j’ai suivis, le relais SMTP CritSend tire son épingle du jeu sur les intégrations rapides où modifier le transport existant coûte moins cher que de réécrire les appels d’envoi.

Questions fréquentes

Comment configurer le DNS SPF pour CritSend ?

Ajoutez un enregistrement TXT sur votre domaine avec la valeur v=spf1 include:spf.critsend.com ~all. Si vous avez déjà un SPF, intégrez include:spf.critsend.com dans votre enregistrement existant sans en créer un second. Vérifiez avec dig TXT votredomaine.fr après 10 à 30 minutes de propagation.

Comment générer et installer une clé DKIM pour CritSend ?

Depuis le dashboard CritSend, activez DKIM pour votre domaine d’envoi. La plateforme génère un sélecteur et une clé publique. Copiez l’enregistrement TXT fourni (de la forme selector._domainkey.votredomaine.fr) et collez-le dans votre gestionnaire DNS. Utilisez une clé de 2048 bits minimum. Vérifiez avec dig TXT selector._domainkey.votredomaine.fr.

Quel port SMTP dois‑je utiliser avec CritSend pour TLS ?

Utilisez le port 587 avec STARTTLS — c’est le standard recommandé pour les applications et scripts. Le port 465 (SSL direct) fonctionne pour les clients qui l’exigent. Évitez le port 25, souvent bloqué par les hébergeurs mutualisés et les FAI.

Comment tester la connexion SMTP vers CritSend depuis mon serveur ?

Lancez openssl s_client -connect smtp.critsend.com:587 -starttls smtp depuis votre serveur. Une connexion réussie affiche la bannière SMTP. En cas d’échec, vérifiez les règles firewall sortantes sur le port 587 et que votre hébergeur n’impose pas de restrictions SMTP.

Que faire en cas de rejet 550 de la part des boîtes cibles ?

Lisez le texte exact du rejet dans vos logs : il cite généralement la raison (blacklist, SPF fail, réputation IP). Vérifiez votre présence sur les blacklists via MXToolbox, contrôlez votre enregistrement SPF et demandez une délistage si nécessaire. Ne relancez pas les envois en boucle avant d’avoir résolu la cause.

Comment gérer les bounces et listes de suppression avec CritSend ?

Activez les webhooks CritSend pour recevoir les événements de bounce en temps réel. Supprimez immédiatement les bounces durs de vos listes d’envoi. Maintenez une liste de suppression globale regroupant bounces durs et désabonnements, et appliquez-la à chaque campagne. Un taux de bounces supérieur à 3 % déclenche en général des filtres supplémentaires chez les FAI.

CritSend impose‑t‑il des limites de quota et comment les augmenter ?

Oui, chaque plan CritSend inclut un quota mensuel — 25 000 e-mails sur certains plans pro à titre d’exemple. En cas de dépassement, les envois sont bloqués jusqu’en fin de mois ou jusqu’à upgrade de plan. Contactez le support CritSend pour augmenter votre quota ponctuellement ou passez à un plan supérieur via l’interface.

Faut‑il préférer l’API ou le relais SMTP pour les envois transactionnels ?

Pour les applications modernes avec accès à un SDK HTTP, l’API offre plus de granularité (webhooks, templates, statistiques temps réel). Le relais SMTP convient mieux aux intégrations sur des systèmes existants (Postfix, PHPMailer, CMS) où changer le transport est plus simple que réécrire les appels. Pour un transactionnel haute fréquence sur une stack moderne, l’API primera.

Ces articles pourraient aussi vous intéresser