couche de contrôle email transactionnel · une API · sans lock-in provider

Ne dépends plus
d’un seul provider
email.

Une seule API pour SES, Postmark, Mailgun, SendGrid et SMTP. Garde les mêmes templates, logs et intégration pendant que tu changes, sépares ou prépares des providers de secours sans reconstruire ton stack email.

Pense Stripe pour l’infra email transactionnelle : portabilité provider, simulation dev/staging safe, diagnostics de délivrabilité et dashboard lisible.

changer de provider sans code dev/staging sans vrais envois diagnostics SPF/DKIM/DMARC logs et templates unifiés
~/projects/saas-app · mail-reacher mailcheck run v1.0
$ mail-reacher mailcheck run --from contact@mail-reacher.com
→ sending probe via aws-ses... delivered (412ms)
→ analyzing headers, dns, content... done
0.0
Excellent/10 — déliverable
SPF 2/10DKIM 10/10DMARC 10/10blacklists 20/20tls v1.3
!SPFaucun enregistrement TXT trouvé
DKIMsignature DomainKeys validée
DMARCpolicy=none, ruf configuré
rDNSa246-5.smtp-out.eu-west-3.amazonses.com
blacklists0/20 listes nommées
contentaucun pattern spam détecté
TLSTLSv1.3 — connexion sécurisée
$
↳ live mail-check
──── une intégration, des providers remplaçables ────
AWS SES
Postmark
Mailgun
SendGrid
SMTP
+ ton SMTP
01 / Pilier #01 — multi-provider

Pourquoi ne pas utiliser SES ou Postmark en direct ? Parce que changer plus tard coûte cher.

Les providers directs sont très bien jusqu’au jour où tu dois migrer, séparer ton trafic, tester la staging sans risque ou garder un dashboard commun. Mail-Reacher stabilise ton code produit pendant que les providers restent remplaçables.

// routing.config.ts
AWS SEStransactionnel
Postmarknewsletter
Mailgunfallback
SendGridbroadcast
SMTPdev / staging
mail-reacher
POST /api/emails/send
1 endpoint
1 SDK · 1 dashboard
// envs4 actifs
env::production
→ AWS SES
env::marketing
→ Postmark
env::staging
→ Mailgun
env::dev
→ SMTP
tip bascule SES → Postmark sans toucher à ton code. La règle vit dans Mail-Reacher, pas dans ton app.
Configurer un provider
settings · senders · new
STEP 2/3
Driver
aws-sesregion: eu-west-3
Access key
AKIA••••••••QXKRencrypted
Domaine
mail-reacher.comverified
Default for
production · transactionnel
// dns auto-check
SPF✓ valid
DKIM✓ valid
DMARC✓ valid
MX✓ valid
03 / Pilier #03 — mail-check

Le Mail-Check. Audite chaque envoi comme un pro.

SPF, DKIM, DMARC, blacklists, reverse DNS, headers, contenu, TLS — un rapport complet pour chaque adresse, à la demande ou en continu.

app.mail-reacher.com / project / mail-check / run #4012 live
8.9
Excellent.
de contact@mail-reacher.com · reçu 09/04/2026 16:31:23 · via aws-ses
SPF
2/10 !
Aucun TXT trouvé pour mail-reacher.com
DKIM
10/10 ✓
Signature DomainKeys validée
DMARC
10/10 ✓
v=DMARC1; p=none;
Reverse DNS
10/10 ✓
a246-5.smtp-out.eu-west-3.amazonses.com
Blacklists
20/20 ✓
0 listes nommées · IP : 23.251.246.5
Headers
10/10 ✓
From · Reply-To · List-Unsub · Date · Message-ID
Contenu
10/10 ✓
Aucun pattern spam détecté
🔒TLS
10/10 ✓
TLSv1.3 — connexion sécurisée
5+
providers derrière une API
SES · Postmark · Mailgun · SendGrid · SMTP — remplaçables sans toucher au code
1
intégration à maintenir
Templates, logs, tracking, environnements et clés API restent dans Mail-Reacher
/10
score normalisé
lisible par un humain, comparable dans le temps
0
vendor lock-in
fonctionne avec n'importe quel provider, même un SMTP custom
04 / Pilier #04 — API & SDK

Une API REST stable. Documentée. Versionnée.

Un seul endpoint POST /api/emails/send, des clés API scopées par environnement, et un SDK Laravel pour brancher tes envois en une ligne. Le reste — routing provider, queue, retries, webhooks — vit dans Mail-Reacher.

Endpoint unique

Un appel HTTP, un payload JSON, une clé API Bearer. Mail-Reacher route vers le bon provider selon ton environnement, applique le template, gère les variables et persiste le log.

Clés scopées

Chaque clé porte un environnement (test / prod) et des scopes granulaires (emails:send, templates:read, contacts:write). Rotation à tout moment.

SDK Laravel

Façade MailReacher::send() côté PHP, configuration via .env, intégration native avec la queue Laravel. Le SDK gère retries, idempotence et logs structurés.

Templates MJML

Éditeur visuel MJML avec preview en temps réel et variables dynamiques {{ variable }}. Le rendu reste lisible sur l'ensemble des clients email, et chaque template peut être réutilisé entre tes environnements de test et de production.

  • rendu responsive sur les clients majeurs (Outlook, Gmail, Apple Mail, Yahoo…)
  • variables injectées à l'envoi via l'API
  • tagging pour le système de désabonnement (CAN-SPAM, RGPD)

Tracking maison

Mail-Reacher injecte son propre pixel de tracking et réécrit les liens dans les emails envoyés. Tu lis les opens et clics depuis le dashboard et l'API sans dépendre du format de webhook de chaque provider — et le suivi reste cohérent quand tu bascules de l'un à l'autre.

  • opens et clics tracés indépendamment du provider
  • logs unifiés dans le dashboard, recherchables
  • ! tracker en cours de validation sur de la charge réelle
05 / pourquoi mail-reacher

Le problème de l'email transactionnel moderne.

Le lock-in provider

Resend, Postmark, Mailgun, SendGrid sont d'excellents providers — mais une fois ton code couplé à leur SDK, changer coûte cher. Mail-Reacher abstrait l'envoi : tu codes contre une API stable, tu choisis le provider à la configuration, et tu peux basculer SES → Postmark sans ouvrir un seul fichier de code.

La délivrabilité opaque

Un email qui part avec succès n'est pas un email qui arrive. SPF, DKIM, DMARC, blacklists, reverse DNS, headers, contenu — chaque détail compte et chaque provider expose ces signaux différemment, voire pas du tout. Le Mail-Check de Mail-Reacher consolide tout en un score lisible sur 10, suivi dans le temps.

Le test/prod fragile

Combien d'apps envoient encore du vrai mail en staging par accident ? Avec Mail-Reacher, la clé API porte l'environnement. mr_test_… simule l'envoi dans une inbox interne, mr_live_… envoie pour de vrai. Le code est identique. Plus de variable d'environnement à oublier.

Le rendu email instable

Un email qui rend bien sur Gmail peut casser sur Outlook, et un changement de template à la va-vite peut tout déstabiliser. Mail-Reacher utilise MJML pour générer du HTML qui tient sur les clients majeurs, avec un éditeur visuel et une preview en temps réel — tu vois ce que tes destinataires verront.

07 / domaine multi-provider

Un même domaine peut utiliser plusieurs providers.

Utiliser SES, Postmark, Mailgun, SendGrid, Brevo ou un SMTP custom sur un même domaine est possible. Ça peut aider à séparer les flux, limiter le lock-in et prévoir des routes de secours — mais ça demande un DNS propre, une authentification cohérente et un vrai monitoring.

avantages

De la flexibilité sans réécrire l'app

  • • Router différemment les emails produit, facturation, marketing ou staging.
  • • Tester un nouveau provider avant de migrer tout le trafic.
  • • Garder une route de secours si un provider a un incident.
  • • Éviter de lier tous les emails transactionnels à un seul vendor.
inconvénients

Plus de providers, plus de risques de dérive

  • • SPF peut atteindre les limites DNS si chaque service est ajouté sans tri.
  • • DKIM, return-path et alignement DMARC doivent rester cohérents.
  • • La réputation devient plus difficile à lire quand le trafic est réparti.
  • • Logs, bounces et webhooks changent selon chaque provider.
conseils

Le faire volontairement, pas par accident

  • • Utiliser des sous-domaines dédiés quand les flux sont différents.
  • • Garder SPF simple et privilégier DKIM pour chaque provider.
  • • Partir d'un provider principal, puis ajouter fallback ou migration.
  • • Monitorer la délivrabilité par provider, pas juste un compteur “sent”.

Mail-Reacher est pensé pour ce setup : une seule intégration dans l'app, choix du provider en configuration, séparation par environnement, logs unifiés et scans Mail-Check pour voir quand un changement DNS, contenu ou provider commence à dégrader la délivrabilité.

08 / faq

Quelques questions. Réponses honnêtes.

Quelle différence avec Resend, Postmark ou Mailgun ?+
Resend, Postmark et Mailgun sont des providers — ils envoient les emails. Mail-Reacher est une couche au-dessus : tu codes contre une API unique, tu choisis le provider à la configuration, et tu peux en changer sans toucher à ton code.
Comment fonctionne la séparation test / production ?+
Les clés API portent l'environnement. mr_test_… simule l'envoi (visible dans une inbox interne, pas de mail réel). mr_live_… envoie via le provider configuré sur l'environnement. Même endpoint, même template, même code — seule la clé change.
Que vérifie le Mail-Check exactement ?+
Dix vérifications consolidées en un score /10 : SPF, DKIM, DMARC, reverse DNS, 20+ blacklists (Spamhaus, SORBS, Barracuda…), headers, contenu, TLS, MX et IPs.
Quels providers sont disponibles aujourd'hui ?+
Les drivers AWS SES, Postmark, Mailgun, SendGrid et SMTP custom sont implémentés. L'accompagnement se fait au cas par cas pour cadrer le driver le mieux adapté à ton usage si besoin.
Comment marche le tracking des opens et clics ?+
Mail-Reacher injecte son propre pixel de tracking et réécrit les liens dans les emails envoyés, pour exposer les opens et clics dans le dashboard et l'API sans dépendre du format de chaque provider.
L'app évolue régulièrement — comment remonter un retour ou une demande ?+
Mail-Reacher est en évolution constante : nouvelles features, ajustements UX, support de nouveaux drivers. Le canal officiel pour bugs, suggestions ou demandes d'accompagnement passe par le ticketing in-app — chaque ticket est traité personnellement.
─── ready ───

Tes emails méritent
mieux qu'un copy-paste.

Crée un projet. Branche un provider. Envoie un mail-check.
Décide après.

sur invitation · pas de carte requise · accompagnement direct