Configurer SendGrid avec un domaine sur Cloudflare

SendGrid te fait créer trois CNAME et un TXT dans ta zone Cloudflare : un CNAME qui sert de chemin de retour, deux CNAME de signature, et un TXT DMARC. Les valeurs sont générées pour ton compte — tu les copies depuis l'écran Sender Authentication de SendGrid et tu les colles dans DNS > Records chez Cloudflare. Compte 15 minutes, une propagation Cloudflare généralement bouclée en 5 à 15 minutes, et un seul vrai piège : le nuage orange doit être gris.

Authentifier ton domaine, ça veut dire prouver aux serveurs qui reçoivent tes emails que SendGrid a le droit d'envoyer en ton nom. Ça ne garantit pas l'arrivée en boîte de réception — ton contenu et ta réputation d'expéditeur comptent au moins autant — mais sans ça tes emails partent avec la mention via sendgrid.net et un handicap sérieux.

Ce qu'on ne fait pas : on ne touche jamais à ta zone DNS. Ce guide t'explique quoi taper et où ; c'est toi qui valides, dans ton tableau de bord, avec tes accès.

Avant tout : est-ce que ta zone est vraiment chez Cloudflare ?

C'est la vraie première question, et elle sauve une heure de dépannage. Cloudflare n'est ton DNS que si les serveurs de noms de ton domaine pointent vers Cloudflare. Si tu as acheté ton domaine ailleurs et que tu n'as jamais changé les serveurs de noms, tu peux très bien avoir un compte Cloudflare avec une belle zone dedans — que personne ne consulte.

Le symptôme : tu ajoutes les enregistrements, SendGrid ne les voit jamais, et tu recommences trois fois en pensant t'être trompé de valeur. Vérifie d'abord où ton domaine délègue son DNS ; ensuite seulement, ajoute les enregistrements.

Les valeurs à copier-coller

SendGrid propose deux modes, et ils ne produisent pas les mêmes enregistrements. Le mode par défaut s'appelle Automated Security ; SendGrid précise qu'il « est activé par défaut » (« defaults to On ») et que dans ce mode « Twilio SendGrid peut créer et mettre à jour tes enregistrements SPF et DKIM à ta place » — via des CNAME qui pointent chez lui.

Bonne nouvelle pour toi : Cloudflare accepte les tirets bas dans les noms de CNAME, donc tu peux rester en mode par défaut. SendGrid ne te demande de le désactiver que si « ton fournisseur DNS n'accepte pas les tirets bas dans les enregistrements CNAME ».

Mode par défaut (Automated Security activé) — 4 enregistrements

Ce que tu dois remplacer :

• em1234 → le numéro affiché sur ton écran SendGrid. Il est propre à ton compte, il ne se devine pas.
• u00000000.wl000 → ton identifiant d'utilisateur et ton numéro de cluster, affichés sur le même écran. Les trois cibles reprennent les mêmes.
• TON-ADRESSE@TON-DOMAINE.fr → une adresse que tu relèves vraiment, c'est là qu'arriveront les rapports DMARC.

Seuls les noms s1._domainkey et s2._domainkey sont stables — sauf si tu as choisi un sélecteur DKIM personnalisé dans les réglages avancés (SendGrid parle de « trois lettres ou chiffres qui créent un sous-domaine personnalisé »).

⚠️ Compte SendGrid hébergé sur la région européenne ? Les cibles ne sont pas les mêmes : SendGrid documente que « la valeur du CNAME d'un domaine rattaché à l'UE contient eu ». Le gabarit exact n'est pas publié — recopie ce que ton écran affiche, comme toujours. Et si tu utilises à la fois la région globale et la région UE, il faut authentifier le domaine deux fois : SendGrid précise qu'« on ne peut ni exporter ni importer les données d'authentification d'expéditeur » d'une région à l'autre.

⚠️ Le DMARC que SendGrid te propose est incomplet. Sa valeur d'exemple est v=DMARC1; p=none; — sans adresse de rapport. Un DMARC sans rua=, c'est une consigne que personne ne te raconte : tu ne verras jamais un seul rapport. Ajoute ton rua=mailto: comme dans le tableau ci-dessus.

Et si tu as déjà un enregistrement _dmarc, tu le modifies, tu n'en crées pas un second. Un domaine ne doit avoir qu'un seul DMARC.

Mode Automated Security désactivé — 4 enregistrements, mais différents

Tu n'en as normalement pas besoin sur Cloudflare. On te les donne pour que tu reconnaisses ton écran si tu as désactivé l'option par le passé :

Ce que tu dois remplacer : em1234 (ton numéro), et toute la partie après p= dans la clé DKIM. Là encore, une clé trouvée dans un tutoriel ne fonctionnera jamais — elle est générée pour ton domaine.

Regarde bien la deuxième ligne du tableau : même en mode manuel, le SPF (v=spf1 include:sendgrid.net ~all) se pose sur le sous-domaine em1234, pas sur ton domaine racine.

Le point qui surprend tout le monde : ton SPF racine ne contiendra pas SendGrid

Dans les deux modes, SendGrid ne te fait ajouter aucun include:sendgrid.net sur ton domaine racine. Le SPF vit sur le sous-domaine em1234.tondomaine.fr, qui sert de chemin de retour (SendGrid explique qu'il « crée un sous-domaine pour ton domaine, chargé des notifications de rebond et de désabonnement »). En mode Automated Security, ce sous-domaine est un CNAME géré par SendGrid ; en mode manuel, c'est toi qui poses le TXT SPF dessus — mais jamais sur la racine.

Conséquence concrète : si tu scannes ton domaine racine, tu ne verras aucune trace de SendGrid dans ton SPF, et ce n'est pas une erreur. C'est même le comportement voulu — l'alignement DMARC est assuré côté SPF par le sous-domaine, et côté DKIM par la signature s1/s2.

Ne « corrige » donc pas ce non-problème en ajoutant include:sendgrid.net à ton SPF racine : tu consommerais une des 10 recherches DNS autorisées pour rien.

Au passage : si ton SPF racine contient déjà include:_spf.mx.cloudflare.net sans que tu saches pourquoi, c'est le service Email Routing de Cloudflare (aujourd'hui sous Compute > Email Service) qui l'a posé en s'activant. Rien à voir avec SendGrid — mais vérifie que tu n'as pas deux lignes v=spf1 sur la racine.

Le chemin de clics

Côté SendGrid — récupérer les valeurs

1. Connecte-toi à SendGrid.
2. Settings → Sender Authentication.
3. Dans la section Domain Authentication, clique sur Get Started.
4. Sur la page Authenticate Your Domain, choisis ton hébergeur DNS dans la liste, saisis ton nom de domaine, et passe les Advanced Settings en revue (voir plus bas). Puis Next.
5. SendGrid affiche la page Install DNS Records : c'est le tableau des valeurs. Laisse cet onglet ouvert, tu vas faire des allers-retours.

Les quatre réglages avancés proposés par SendGrid, dans ses termes : Use automated security, Use a custom return path, Use a custom link subdomain, Use a custom DKIM selector. Si tu ne sais pas quoi en faire, laisse tout par défaut — c'est le bon choix dans 95 % des cas.

Côté Cloudflare — créer les enregistrements

1. Connecte-toi au tableau de bord Cloudflare, sélectionne ton compte puis ton domaine.
2. Va dans DNS → Records.
3. Bouton Add record.
4. Choisis le Type (CNAME pour les trois premiers, TXT pour le DMARC).
5. Remplis le champ Name, puis le champ de valeur — il s'appelle Target pour un CNAME et Content pour un TXT.
6. Vérifie que le Proxy status est sur « DNS only » (le nuage doit être gris, pas orange). C'est le point critique, voir juste en dessous.
7. Laisse le TTL sur Auto, puis Save.
8. Répète pour les quatre enregistrements.

Le champ « Name » attend le nom relatif. Tape em1234, s1._domainkey, _dmarc — jamais em1234.tondomaine.fr. Cloudflare ajoute ton domaine tout seul. Les tirets bas en début de nom sont parfaitement valides en DNS — Cloudflare l'écrit lui-même (« Underscores are valid in DNS and commonly used for service records »).

Retour côté SendGrid — vérifier

Reviens sur la page Install DNS Records et clique sur Verify. Cloudflare propage généralement en 5 à 15 minutes, donc c'est rapide. Si ça échoue après 15 minutes, relis le nuage orange avant tout le reste — puis va lire les erreurs ci-dessous.

Les 3 erreurs qu'on voit le plus souvent sur cette configuration

1. Un nuage orange laissé sur un CNAME

C'est l'erreur numéro un de la combinaison SendGrid × Cloudflare, et elle a même son code d'erreur chez SendGrid : 1004. Le proxy Cloudflare — le nuage orange — fait passer le trafic par ses serveurs, et SendGrid explique pourquoi ça bloque : « les enregistrements CNAME proxifiés ne sont pas disponibles publiquement, tu dois donc modifier ce statut pour utiliser l'enregistrement avec SendGrid ».

Autrement dit : quand le nuage est orange, le reste du monde ne voit plus ta cible u00000000.wl000.sendgrid.net, il voit une adresse IP de Cloudflare. SendGrid ne se reconnaît pas, et refuse de valider.

Et voilà pourquoi cette erreur est si fréquente : Cloudflare proxifie les CNAME par défaut (« Proxying is on by default »), et le tiret bas au début de s1._domainkey n'y change rien — seul le type compte, et un CNAME est proxifiable, quel que soit son nom. Tes trois CNAME SendGrid naissent donc avec un nuage orange si tu ne le décoches pas à la création. Vérifie les trois, pas seulement em1234.

Comment tu le reconnais : SendGrid affiche l'erreur 1004 ou refuse obstinément de valider un enregistrement que tu as pourtant recopié caractère par caractère. Dans DNS > Records, l'enregistrement affiche un nuage orange.

Le correctif : la consigne officielle de SendGrid, mot pour mot — « clique sur le bouton flèche-nuage à côté de l'enregistrement, pour qu'il affiche DNS only ». Le nuage passe au gris. Puis reclique sur Verify.

2. Le CNAME flattening qui écrase la signature

Cloudflare propose une option de « CNAME flattening » : elle transforme un CNAME en enregistrement A au moment de la réponse. Pratique pour la racine d'un domaine, catastrophique pour une clé DKIM — le service email cherche un CNAME, trouve une adresse IP, et ne retrouve jamais sa clé.

Comment tu le reconnais : ton CNAME em1234 valide, mais s1._domainkey et s2._domainkey restent en échec. Ou l'inverse selon le réglage. Une interrogation DNS depuis l'extérieur renvoie une IP là où tu attendais un nom.

Le correctif : vérifie le réglage de flattening de ta zone et assure-toi qu'il ne s'applique qu'à la racine (Flatten CNAME at root), pas à tous les CNAME.

3. Le nom saisi en entier dans le champ « Name »

Tu copies s1._domainkey.tondomaine.fr depuis l'écran SendGrid — c'est bien ce qu'il affiche — et tu le colles tel quel chez Cloudflare. Cloudflare ajoute ton domaine à la fin, et tu obtiens s1._domainkey.tondomaine.fr.tondomaine.fr, qui n'existe pour personne.

Comment tu le reconnais : dans la liste DNS > Records, le nom de ton domaine apparaît deux fois dans la colonne de gauche.

Le correctif : modifie l'enregistrement et ne garde que la partie gauche : s1._domainkey.

⚠️ Ne confonds pas ce piège avec son voisin. Chez certains hébergeurs (OVH, Gandi), l'erreur symétrique existe sur la cible d'un CNAME : il faut au contraire y ajouter un point final. Chez Cloudflare, le champ Target accepte la cible telle quelle, sans point final. Les deux correctifs sont exactement inverses — c'est pour ça qu'on s'y perd.

Combien de temps avant que ça prenne effet

• Chez Cloudflare : la formulation officielle est prudente — la propagation « peut prendre jusqu'à 24 h à l'échelle mondiale, mais se termine généralement en 5 à 15 minutes ». Rapide, mais pas instantané.
• Mais l'ancienne valeur peut rester en cache aussi longtemps que le TTL fixé avant ta modification. Ce n'est pas une contradiction, c'est du cache.
• Côté SendGrid : la documentation annonce que « la vérification DNS peut prendre jusqu'à 48 heures après l'ajout », et conseille de « recliquer sur Verify dans 48 heures » en cas d'échec. Sur Cloudflare, c'est en pratique une affaire de minutes — si ça échoue après 15 minutes, c'est une erreur de configuration, pas de la propagation.
• Pour les rapports DMARC : les premiers arrivent 24 à 72 h après la publication de l'enregistrement, puis environ une fois par jour.

Ton service d'envoi n'est pas SendGrid ?

Le reste du guide — le chemin de clics Cloudflare, le nuage orange, le champ Name — ne change pas. Seuls les enregistrements changent.

Pour aller plus loin

• Configurer SPF, DKIM et DMARC sur Cloudflare
• Configurer Mailjet avec un domaine hébergé chez OVH
• Configurer Brevo avec un domaine hébergé chez OVH
• Passer son DMARC en p=reject sans casser ses emails
• Mes emails partent en spam alors que SPF, DKIM et DMARC sont bons