SMTP proxy multi-provider · multi-env · open au feedback

Vos emails.
Vos providers.
Vos règles.

Tes mails de dev n'atteignent jamais tes vrais users. Ta prod livre via ton provider habituel (SES, Postmark, Mailgun, SendGrid ou ton SMTP). Une seule API, multi-environnement, anti vendor-lock-in.

Comme Mailtrap pour la simulation, mais qui livre vraiment en prod — et qui te donne un Mail-Check pour auditer SPF / DKIM / DMARC / blacklists à chaque envoi.

aucun vendor lock-in mails simulés en dev Mail-Check inclus accompagnement direct
~/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
──── un seul code, n'importe quel provider ────
AWS SES
Postmark
Mailgun
SendGrid
SMTP
+ ton SMTP
01 / Pilier #01 — multi-provider

Une API. Cinq providers. On s'occupe du reste.

Un transport unifié pour les 5 grands providers du marché. Le code ne change pas, le provider si — bascule en un clic, ou répartis selon le projet.

// 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
10
vérifications par envoi
SPF · DKIM · DMARC · rDNS · blacklists · headers · TLS · contenu · MX · IPs
20+
blacklists scannées
Spamhaus · SORBS · Barracuda · UCEProtect · …
/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