Configurer l’e-mail pour ton domaine

L’e-mail sur ton domaine couvre deux besoins distincts. Server Manager propose un assistant pour chacun.

Tu peux utiliser l’un, l’autre, ou les deux. Ils ne dépendent pas l’un de l’autre. Les deux assistants se trouvent dans le menu **Configuration** de la barre supérieure — clique sur ce terme pour voir exactement où il se trouve.

Prérequis pour les deux : le DNS de ton domaine doit déjà être chez Cloudflare ou Porkbun. Si ce n’est pas le cas, lance d’abord Connecter un domaine — le parcours qui bascule vers Cloudflare dans cet assistant est aussi la voie standard ici.

Pourquoi ne pas simplement utiliser un service d’hébergement e-mail ?

Bonne question — et la réponse est : tu peux, et ces assistants restent utiles. Les services d’hébergement e-mail et les assistants e-mail de Server Manager résolvent des problèmes qui se recoupent, mais qui ne sont pas identiques. Petit récapitulatif :

Combinaisons courantes :

• Uniquement des e-mails transactionnels — ton app envoie des reçus de commande ; personne ne te répond par e-mail. Lance uniquement l’assistant Envoyer.
• Projet perso / solo — tu veux que you@yourdomain.com fasse professionnel, mais tu utilises déjà Gmail au quotidien. Lance Envoyer + Recevoir branche A (gratuit, transfert vers ton Gmail existant).
• Petite entreprise, sans Workspace — plusieurs personnes ont besoin de vraies boîtes mail sur le domaine. Choisis un fournisseur de boîtes mail payant, puis lance Envoyer + Recevoir branche B (collage DNS).
• Déjà sur Workspace / M365 — tu n’as pas du tout besoin de l’assistant Recevoir (Workspace gère les boîtes mail). Tu peux quand même vouloir l’assistant Envoyer pour que les apps n’aient pas à passer par le relais SMTP de Workspace, qui impose des limites strictes et n’est pas conçu pour les e-mails envoyés par des apps.

Partie 1 — Envoyer des e-mails depuis ton domaine (sortant)

C’est ce qu’il te faut quand une app ou un site web qui tourne sur ton serveur doit envoyer des e-mails. E-mails de réinitialisation de mot de passe, notifications « ta commande a été expédiée », envois de formulaires de contact, e-mails de bienvenue.

Server Manager utilise Resend comme fournisseur d’envoi. Resend propose une offre gratuite généreuse (100 e-mails/jour, 3000/mois) et une API simple. Ton app appelle l’endpoint /emails de Resend avec un en-tête from: noreply@yourdomain.com ; Resend s’occupe de l’envoi, du suivi des rebonds et de la signature SPF/DKIM qui évite à tes e-mails de finir en spam.

Barre supérieure → Actions → Envoyer des e-mails depuis ton domaine.

Resend est sélectionné par défaut — laisse-le. (Postmark / Mailgun / SES sont prévus ; pour l’instant, Resend est le seul adaptateur.)

Ouvre resend.com/api-keys (inscris-toi gratuitement si tu n’as pas encore de compte) et crée une nouvelle clé API. Copie-la.

Dans l’assistant, saisis le domaine depuis lequel tu veux envoyer les e-mails (par exemple yourdomain.com), colle la clé, puis clique sur Continuer.

Resend fournit trois enregistrements — un TXT SPF, un TXT DKIM et un TXT DMARC. L’assistant les écrit chez ton fournisseur DNS (Cloudflare ou Porkbun) avec le jeton obtenu lors de Connecter un domaine (ou t’en demande un s’il ne l’a pas encore).

Que sont SPF / DKIM / DMARC ? Trois enregistrements TXT qui prouvent aux serveurs de messagerie destinataires (Gmail, Outlook, …) que les e-mails prétendant venir de ton domaine ont bien été envoyés par Resend pour ton compte. Sans eux, tes e-mails finissent en spam — Gmail est particulièrement strict. Tu n’as pas besoin de comprendre ces protocoles ; Server Manager doit simplement les écrire là où Resend l’a demandé.

Le DNS se propage généralement en 1 à 5 minutes. Resend revérifie selon son propre rythme ; le bouton Vérifier maintenant l’incite à regarder tout de suite.

Tu peux fermer l’assistant et revenir plus tard — les enregistrements sont déjà en place ; la vérification continue en arrière-plan chez Resend. Quand tu rouvres l’assistant avec le même domaine + la même clé, il passe directement à Terminé si Resend a fini de vérifier.

L’écran de réussite te montre l’appel API exact à utiliser :

POST https://api.resend.com/emails
Authorization: Bearer <your-api-key>
Content-Type: application/json

{
  "from": "noreply@yourdomain.com",
  "to": "user@example.com",
  "subject": "...",
  "html": "..."
}

Ajoute cet appel au code de ton app (les SDK Node/Python/PHP de Resend l’encapsulent). Garde la clé API dans une variable d’environnement, pas dans le code source.

Partie 2 — Recevoir des e-mails sur ton domaine (entrant)

C’est ce qu’il te faut quand **quelqu’un envoie un e-mail à you@yourdomain.com et que tu veux le recevoir dans une boîte lisible**. Il existe deux vraies façons de faire ; choisis au début.

Barre supérieure → Actions → Recevoir des e-mails sur ton domaine.

Après avoir saisi le domaine, l’assistant propose deux cartes :

Transférer vers ma boîte de réception existante (gratuit, automatisé) — les e-mails envoyés à me@yourdomain.com arrivent dans ton Gmail/Outlook/Yahoo/iCloud/etc. existant. Fonctionne avec Cloudflare Email Routing. Automatisé de bout en bout ; l’assistant fait tout sauf cliquer sur un lien de vérification.

Vraie boîte mail sur mon domaine (payant, tu choisis le fournisseur) — un compte e-mail complet à me@yourdomain.com. Webmail, synchronisation mobile, calendrier, envoi natif depuis le domaine. Tu t’inscris + tu paies chez un fournisseur d’hébergement e-mail (€1–6/mois/boîte mail) ; Server Manager t’aide à coller les enregistrements MX.

Comparaison rapide

Si tu veux surtout que les e-mails envoyés à ton domaine soient lisibles, le transfert est le bon choix. Si tu veux que tes clients voient naturellement des réponses venant de ton domaine (et que payer ne te dérange pas), choisis la boîte mail.

Branche A — Transférer vers ma boîte de réception existante

A1. Activation unique chez Cloudflare

Avant de coller le jeton, l’assistant te demande d’activer une fois Email Routing dans le tableau de bord Cloudflare :

1. Ouvre dash.cloudflare.com → choisis ta zone → Email → Email Routing dans la barre latérale gauche.
2. Si tu vois un bouton Get Started / Set Up, clique et suis les étapes. Cloudflare demandera à remplacer les enregistrements MX existants — confirme.
3. Attends qu’Email Routing affiche le statut Active dans le tableau de bord.

Cette configuration initiale doit se faire dans l’interface de CF ; leur API refuse l’appel d’activation tant que ce n’est pas fait.

A2. Crée un jeton API Cloudflare

L’assistant te montre la configuration exacte du jeton, mais voici l’essentiel :

• Ouvre dash.cloudflare.com/profile/api-tokens → Create Token → Create Custom Token.
• Ajoute quatre autorisations : Zone:Read, Zone:DNS:Edit, Zone:Email Routing Rules:Edit, Account:Email Routing Addresses:Edit.
• Sous Zone Resources, limite l’accès à ton domaine.
• Crée le jeton ; copie-le avant de quitter la page (CF ne l’affiche qu’une seule fois).

Colle-le dans l’assistant.

A3. Configure le transfert

L’assistant charge tes zones Cloudflare et te demande deux choses :

• Transférer cette adresse — saisis un nom comme me, hello ou info. Utilise * pour intercepter toutes les adresses de ton domaine (les e-mails envoyés à anything@yourdomain.com sont transférés).
• Transférer vers cette boîte de réception — n’importe quelle adresse e-mail que tu peux lire : Gmail, Outlook, Yahoo, iCloud, ProtonMail, Fastmail, une adresse professionnelle. Pas besoin que ce soit Gmail. N’utilise pas une adresse sur le même domaine — ça crée une boucle.

A4. Vérifie la boîte de destination

Cloudflare envoie un e-mail de vérification à la destination. Ouvre cette boîte, trouve le message de Cloudflare (« Verify your email address »), clique sur le lien, reviens, puis clique sur Vérifier maintenant.

Si la destination est la même adresse que l’e-mail du compte Cloudflare, elle est vérifiée automatiquement et cette étape est ignorée.

Tu peux fermer l’assistant au milieu de la vérification et revenir plus tard — Cloudflare garde le lien de vérification valide quelque temps ; la règle est créée automatiquement quand tu cliques sur Vérifier maintenant après avoir vérifié.

A5. Terminé

Envoie un e-mail de test depuis n’importe quelle autre boîte vers me@yourdomain.com — il devrait arriver dans ta boîte de destination en environ 1 minute. (Vérifie les spams — les premiers envois depuis un nouveau domaine y atterrissent parfois jusqu’à ce que le fournisseur destinataire observe un comportement propre.)

Et si l’API Cloudflare refuse le jeton avec “Authentication error” ? Leur API Email Routing échoue parfois lors de l’activation / création de règle même quand le jeton est correct — il y a trois pièges connus. L’assistant affiche une section Bloqué ? avec des étapes de secours manuelles à suivre dans le tableau de bord Cloudflare. Le résultat final est le même.

Branche B — Vraie boîte mail sur mon domaine

B1. Inscris-toi chez un fournisseur

Choisis un fournisseur d’hébergement e-mail adapté à tes besoins et à ton budget. Cherche « hébergement e-mail » — il en existe beaucoup. Les choix courants proposent généralement webmail, synchronisation mobile, IMAP/SMTP et une bonne délivrabilité. Server Manager n’en recommande pas un en particulier, car le bon choix dépend de ton pays, de ta langue, de tes besoins d’assistance et de tes intégrations.

Une fois le compte créé, l’onboarding du fournisseur te demandera d’ajouter ton domaine. Après ça, il te montrera 1 à 3 enregistrements MX à ajouter à ton DNS. Copie-les.

B2. Colle les enregistrements MX

Dans l’assistant, colle la priorité de chaque enregistrement MX (généralement 10, 20) et le nom d’hôte du serveur (par exemple mx.provider.com). La plupart des fournisseurs en listent 1 ou 2 ; certains en listent 3. Utilise + Ajouter un autre enregistrement MX pour ajouter des lignes.

Sous les lignes, l’assistant détecte automatiquement ton fournisseur DNS (Cloudflare ou Porkbun) et demande le jeton API correspondant. Le flux jeton + clé est identique à Connecter un domaine — même fournisseur, même type de jeton.

Clique sur Écrire les enregistrements MX. Chaque ligne affiche ✓ ou ✗ quand elle est écrite.

B3. Vérifie chez le fournisseur

Le travail de l’assistant est terminé — les enregistrements MX sont actifs. La dernière étape se passe chez ton fournisseur : il peut mettre quelques minutes à détecter le changement MX et à marquer ton domaine comme vérifié. Connecte-toi à son tableau de bord et vérifie le statut de vérification du domaine. Une fois vérifié, crée les boîtes mail (comme me@yourdomain.com) chez le fournisseur et commence à recevoir des e-mails.

Les fournisseurs de boîtes mail n’exposent généralement pas d’API d’envoi pour tes apps. Si tu veux aussi que les apps sur ce serveur envoient des e-mails depuis ce domaine, lance séparément la partie 1 (Envoyer des e-mails depuis ton domaine) — les deux cohabitent sans problème. Le serveur mail (fournisseur) gère l’entrant ; Resend gère le sortant de tes apps.

Questions fréquentes

Puis-je utiliser Gmail Workspace / Microsoft 365 à la place ? Oui — ce sont des fournisseurs de boîtes mail standards. Inscris-toi chez eux, récupère les enregistrements MX qu’ils te donnent, puis colle-les dans la branche B. Server Manager n’a pas d’intégration spéciale pour l’un ou l’autre, mais le flux générique de boîte mail fonctionne.

Puis-je garder mon ancienne configuration e-mail et simplement envoyer depuis le domaine ? Oui — la partie 1 (sortant) et la partie 2 (entrant) sont indépendantes. Configure seulement le sortant ; laisse les enregistrements MX entrants pointer là où ils pointent déjà.

Qu’arrive-t-il aux enregistrements MX existants si je lance la branche A ? Cloudflare Email Routing les remplace (l’onboarding dans le tableau de bord te demande de confirmer). Si tu reçois actuellement tes e-mails ailleurs et que tu veux conserver cette configuration, choisis la branche B et ajoute les enregistrements MX du fournisseur existant.

Les e-mails vont-ils finir en spam ? Les premiers e-mails envoyés depuis un domaine neuf finissent souvent en spam, surtout si le fournisseur destinataire est Gmail. Les enregistrements SPF/DKIM/DMARC écrits par la partie 1 sont exactement ce qu’il faut pour sortir du spam — après l’envoi d’un petit volume d’e-mails réalistes (pas des e-mails transactionnels qui ressemblent à de l’envoi en masse), Gmail commence à faire confiance au domaine.

Puis-je révoquer un jeton après la configuration ? Oui. Les jetons Cloudflare/Porkbun/Resend ne sont nécessaires que pendant l’assistant ; une fois les enregistrements écrits et ton domaine vérifié, tu peux supprimer les jetons dans le tableau de bord du fournisseur. Server Manager ne les a jamais stockés.

Référence

Enregistrements DNS écrits par chaque assistant :

• Envoyer des e-mails (partie 1) — 3 enregistrements TXT : SPF, DKIM, DMARC (fournis par le fournisseur)
• Recevoir — Transfert (branche A) — 3 enregistrements MX (ceux de Cloudflare Email Routing), plus la règle de routage (dans CF, pas dans le DNS)
• Recevoir — Boîte mail (branche B) — 1 à 3 enregistrements MX (fournis par le fournisseur)

Jetons / clés utilisés (aucun n’est conservé par Server Manager) :

• Clé API Resend (re_…) — pour l’assistant Envoyer
• Jeton API Cloudflare — pour Envoyer (écriture DNS) et Recevoir branche A (Email Routing)
• Clé API Porkbun + secret (pk1_… / sk1_…) — pour l’écriture DNS quand le domaine est chez Porkbun

Le statut est par hôte, dans ton navigateur. Le fait qu’un e-mail soit « configuré » pour un domaine est suivi par des marqueurs que chaque assistant écrit dans le localStorage du navigateur en cas de réussite — c’est une indication d’interface, pas la source de vérité. Resend / ton fournisseur DNS font autorité.