SendGrid : configurer le domaine authentifié (SPF/DKIM)

em1234.exemple.fr.         CNAME  u1234567.wl123.sendgrid.net.
s1._domainkey.exemple.fr.  CNAME  s1.domainkey.u1234567.wl123.sendgrid.net.
s2._domainkey.exemple.fr.  CNAME  s2.domainkey.u1234567.wl123.sendgrid.net.

L'alignement DMARC : le scénario favorable

DMARC ne valide un message que si SPF ou DKIM passe et s'aligne avec le domaine du From. C'est sur ce point que la domain authentication de SendGrid se distingue.

Côté DKIM, la signature porte d=exemple.fr — le domaine lui-même, pas un domaine de la plateforme. L'alignement est acquis, y compris en mode strict. Côté SPF, l'enveloppe des messages devient bounce@em1234.exemple.fr : un sous-domaine du domaine organisationnel. En mode relâché — le défaut de DMARC —, ce sous-domaine s'aligne avec exemple.fr ; sous DMARCbis, le domaine organisationnel se détermine d'ailleurs par le DNS Tree Walk, et le résultat est le même. Deux mécanismes passent donc alignés, et cette redondance a une valeur opérationnelle : si une redirection casse SPF en changeant l'IP émettrice, DKIM survit ; si une passerelle altère le corps du message et invalide la signature, SPF reste.

La comparaison avec d'autres ESP éclaire ce que ce montage a de favorable. Chez Mailchimp, l'alignement repose sur DKIM seul : l'enveloppe reste sur les domaines de la plateforme, SPF passe mais ne s'aligne jamais — un fonctionnement conforme et suffisant, mais sans filet. La configuration SPF et DKIM chez Mailjet suit un modèle intermédiaire, avec des enregistrements à copier dans la zone plutôt qu'une délégation complète. SendGrid, en déléguant à la fois les sélecteurs DKIM et le sous-domaine d'enveloppe, obtient le double alignement sans qu'une seule valeur soit recopiée à la main — c'est le montage le plus robuste qu'un ESP puisse proposer aujourd'hui.

Le link branding : la cohérence de domaine jusque dans les liens

La même mécanique de CNAME s'applique à une seconde fonction, distincte mais complémentaire : le « link branding ». Par défaut, le suivi de clics de SendGrid réécrit chaque lien d'un message vers un domaine de la plateforme. Avec le link branding, la réécriture se fait vers un sous-domaine du domaine expéditeur — url1234.exemple.fr ou un préfixe choisi — délégué lui aussi par CNAME.

DMARC n'évalue pas les liens : cette brique ne change rien à l'alignement. Elle change en revanche la cohérence perçue du message. Un e-mail signé exemple.fr dont tous les liens pointent vers un domaine de tracking tiers envoie un signal discordant, aux filtres antispam comme aux destinataires attentifs qui survolent un lien avant de cliquer. La cohérence de domaine — From, enveloppe, liens, le tout sous la même bannière — participe de la réputation globale ; des liens de suivi hors domaine figurent parmi les facteurs examinés dans pourquoi des e-mails partent en spam. Tant qu'à poser des CNAME dans la zone, autant compléter le lot.

Les erreurs courantes qui font échouer la validation

La configuration tient en trois enregistrements, mais quelques pièges reviennent constamment.

• Les CNAME proxifiés derrière un CDN. C'est l'erreur numéro un sur les zones gérées chez Cloudflare : le proxy (l'icône orange) intercepte la résolution et substitue ses propres adresses à la cible du CNAME. La validation SendGrid échoue — ou pire, réussit puis casse silencieusement. Les trois enregistrements doivent être en mode « DNS only », sans proxy : ce sont des enregistrements de messagerie, pas du trafic web à accélérer.
• Le sous-domaine em déjà pris. Reliquat d'une intégration passée, second compte SendGrid, wildcard existant dans la zone : si le nom proposé entre en collision, la validation ne passera pas proprement. La bonne réponse est de choisir un autre préfixe via l'option de Return-Path personnalisé (em2, m1…), jamais d'écraser un enregistrement existant dont un autre flux dépend peut-être.
• La duplication du domaine. Beaucoup d'interfaces DNS ajoutent automatiquement le domaine à la fin du nom saisi : coller em1234.exemple.fr dans le champ « nom » produit em1234.exemple.fr.exemple.fr. Une interrogation dig sur le nom exact attendu lève le doute en dix secondes.
• La validation testée trop tôt — ou jamais relancée. La propagation DNS prend de quelques minutes à quelques heures selon les TTL. Un échec immédiat ne prouve rien ; il faut relancer la vérification une fois la propagation faite, car la plateforme ne signe au nom du domaine qu'après validation.
• Les CNAME supprimés après coup. La validation n'est pas un examen que l'on passe une fois : les enregistrements servent à chaque message, pour chaque vérification DKIM et SPF des destinataires. Un « nettoyage » de zone qui les retire casse l'authentification du jour au lendemain.

Vérifier le résultat dans les rapports RUA

Le bandeau « verified » de l'interface SendGrid confirme que les CNAME répondent — pas que le courrier réel sort aligné. La preuve se lit dans les rapports agrégés DMARC, quelques jours après l'activation.

Dans les rapports RUA, les lignes attribuées aux adresses d'envoi de SendGrid doivent présenter deux résultats : DKIM pass avec d=exemple.fr (sélecteur s1 ou s2) et l'alignement acquis ; SPF pass avec em1234.exemple.fr comme domaine d'enveloppe, aligné en mode relâché. Les écarts se diagnostiquent vite : un DKIM qui passe avec d=sendgrid.net signale un flux qui n'utilise pas le domaine authentifié — sous-utilisateur non rattaché, second compte oublié, intégration qui pointe ailleurs ; un SPF qui passe sans s'aligner, avec un domaine d'enveloppe de la plateforme, trahit le même symptôme. Ces lignes-là redeviendraient des rejets sous p=reject.

Une fois les deux mécanismes au vert sur plusieurs semaines de rapports, et sur l'ensemble des flux SendGrid (transactionnel et marketing, tous sous-utilisateurs confondus), le durcissement de la politique peut suivre son cours — mode test t=y de DMARCbis, puis p=quarantine, puis p=reject — sans risque pour ce canal.

En résumé

La domain authentication de SendGrid repose sur trois CNAME : un sous-domaine d'enveloppe (em1234) et deux sélecteurs DKIM (s1._domainkey, s2._domainkey), qui délèguent à la plateforme la publication des clés et de l'enregistrement SPF. L'« automated security » rend la rotation des clés invisible ; le double alignement — DKIM sur le domaine, SPF sur un sous-domaine délégué — en fait l'un des montages les plus solides du marché des ESP. Les pièges classiques tiennent au DNS : proxy CDN à désactiver sur ces enregistrements, collision sur le sous-domaine em, duplication du domaine, validation à relancer après propagation. Et le verdict final ne se lit ni dans l'interface ni dans un test isolé, mais dans les rapports agrégés.

Pour situer le point de départ, une analyse DMARC gratuite du domaine révèle en quelques secondes si le flux SendGrid signe déjà au bon nom et si l'enveloppe s'aligne. Et pour suivre l'effet des trois CNAME dans la durée, la création d'un compte donne accès aux rapports RUA décodés, source par source — la contre-épreuve qui transforme une case verte en certitude.