SPF, DKIM et DMARC pour Front.
Front (front.com) est une plateforme de boîte de réception partagée et de communication client, et non un hébergeur de messagerie — « envoyer au nom de votre domaine » via Front a donc une signification bien précise. Lorsque vous connectez un canal SMTP personnalisé, Front relaie votre courrier sortant via SendGrid, son infrastructure de messagerie sous-jacente (les comptes plus anciens relayaient via Mandrill, ce qui explique la mention héritée « via mandrillapp.com » que vous avez pu voir). Tant que vous n'authentifiez pas ce chemin, les destinataires voient une mention « via sendgrid.net » sur votre adresse d'expéditeur, et votre courrier est bien plus susceptible d'atterrir dans les spams. Les paramètres de délivrabilité de Front vous fournissent trois enregistrements DNS — un MX, un SPF (sous forme de TXT) et un DKIM (sous forme de TXT) — que vous ajoutez à un sous-domaine d'envoi dédié, front-mail. Comme ces enregistrements résident sur le sous-domaine plutôt que sur votre domaine racine, ils autorisent SendGrid à envoyer en votre nom, suppriment la mention « via », alignent votre courrier sur votre domaine pour DMARC, et tout cela sans toucher à votre SPF existant ni changer l'endroit où votre courrier entrant est distribué.
Pourquoi authentifier Front ?
L'authentification de votre domaine d'envoi Front détermine si vos réponses atteindront la boîte de réception ou non. Depuis février 2024, Gmail et Yahoo exigent de chaque expéditeur en masse (environ 5 000 messages ou plus par jour) qu'il satisfasse SPF, DKIM et DMARC avec alignement, et Microsoft a commencé à appliquer les mêmes règles aux expéditeurs à fort volume en 2025 — or les équipes de support et de réussite client qui travaillent dans Front atteignent régulièrement ces volumes. Tant que vous n'ajoutez pas les enregistrements, Front envoie votre courrier sur l'infrastructure partagée de SendGrid : les destinataires voient la mention « via sendgrid.net », votre adresse d'expéditeur ne s'aligne pas sur votre domaine, DMARC ne peut pas passer via SPF, et votre réputation d'expéditeur est mutualisée avec celle de tous les autres locataires non authentifiés de cette plateforme. L'authentification corrige tout cela d'un coup — SendGrid signe avec une clé DKIM publiée sous votre sous-domaine front-mail (la signature s'aligne donc sur votre domaine), le Return-Path de l'enveloppe réside sur ce même sous-domaine (SPF s'aligne donc en mode relâché), la mention « via » disparaît, DMARC passe, et la réputation que vous construisez profite à votre propre domaine plutôt qu'au pool partagé.
La réalité SPF pour Front
Front repose sur une délégation de sous-domaine, et non sur un fournisseur de type « include » — il n'y a AUCUN include:sendgrid.net à coller sur votre domaine racine. Au contraire, l'ensemble du chemin authentifié réside sur un sous-domaine d'envoi dédié que Front nomme front-mail. Ce sous-domaine reçoit trois enregistrements directement depuis le panneau de délivrabilité de Front : un enregistrement MX pointant vers le serveur de messagerie de SendGrid (mx.sendgrid.net) pour que SendGrid puisse traiter les rebonds, un enregistrement SPF TXT (v=spf1 include:sendgrid.net ~all) limité au sous-domaine, et une clé publique DKIM TXT sur un sélecteur de ce même sous-domaine. L'enregistrement SPF de votre propre domaine organisationnel reste exactement tel quel — l'include de Front réside sur front-mail.yourdomain.com, il ne coûte donc rien sur le budget de 10 requêtes DNS de votre SPF racine. DMARC passe malgré tout, mais notez ce détail propre à Front : comme le Return-Path de l'enveloppe ET la clé DKIM résident TOUS DEUX sur le sous-domaine front-mail, SPF et DKIM s'alignent tous deux sur votre domaine organisationnel en mode relâché (le sous-domaine partage votre domaine enregistrable) — et aucun ne s'aligne en mode strict. Le mode relâché est celui par défaut de DMARC, Front passe donc dès le départ ; il suffit de ne pas forcer l'alignement strict (aspf=s ou adkim=s) pour ce domaine. Enfin, cela ne s'applique qu'aux canaux SMTP de Front ; si votre canal Front est une boîte de réception Gmail ou Microsoft 365 connectée, Front envoie via les propres serveurs de ce fournisseur et vous authentifiez chez Google/Microsoft à la place — aucun des enregistrements front-mail ne s'applique.
Deux façons de le configurer
Canal SMTP Front — ajoutez les enregistrements SendGrid (ce guide)
- S'applique lorsque votre canal est un canal SMTP personnalisé — Front relaie votre courrier sortant via SendGrid et vous devez l'authentifier.
- Ajoutez MX + SPF (TXT) + DKIM (TXT) à un sous-domaine d'envoi dédié front-mail, copiés depuis le panneau de délivrabilité de Front.
- Les trois enregistrements résident sur le sous-domaine, votre SPF de domaine racine reste donc intact — zéro de vos 10 requêtes SPF consommées.
- Tant que Front n'affiche pas les enregistrements comme Verified, le courrier part « via sendgrid.net » sur le pool partagé et risque le dossier spam.
Canal Gmail / Microsoft 365 connecté — authentifiez plutôt là-bas
- S'applique lorsque vous avez ajouté votre boîte de réception à Front via l'intégration Google ou Microsoft 365 — Front envoie via ce fournisseur, et non SendGrid.
- L'authentification est héritée du SPF, DKIM et DMARC de votre Google Workspace ou Microsoft 365 — configurez-les chez ce fournisseur.
- Il n'y a pas de sous-domaine front-mail, pas de MX vers mx.sendgrid.net, et aucun des enregistrements SPF/DKIM SendGrid ne s'applique.
- La mention « via sendgrid.net » n'apparaît jamais car SendGrid n'est pas dans le chemin d'envoi.
Étape par étape
- 1
Confirmez que le canal est un canal SMTP
Ces enregistrements ne s'appliquent qu'aux canaux SMTP de Front (courrier relayé via SendGrid). Si votre canal est une boîte de réception Gmail ou Microsoft 365 connectée, Front envoie via ce fournisseur — arrêtez-vous ici et authentifiez chez Google/Microsoft à la place. Vérifiez le type de canal sous Settings → Channels.
- 2
Ouvrez les paramètres de délivrabilité
Pour les canaux à l'échelle de l'entreprise, cliquez sur l'engrenage Settings → Company settings → Security dans la barre latérale → l'onglet Deliverability. Cette page n'apparaît aux administrateurs de l'entreprise qu'une fois qu'au moins un canal SMTP partagé existe. Pour le canal d'un coéquipier individuel, ouvrez Settings → le canal SMTP du coéquipier → l'onglet Settings → la section « Improve delivery rates - SPF / DKIM ».
- 3
Sélectionnez le domaine d'envoi
Sous Domains, choisissez le domaine depuis lequel vous envoyez. Tout domaine dépourvu de SPF/DKIM affiche une icône d'avertissement jaune. Front affiche alors le Name et la Value de trois enregistrements à ajouter : un MX, un SPF (TXT) et un DKIM (TXT). Gardez ce panneau ouvert pour y copier — le sélecteur, l'hôte et les valeurs de clé exacts sont propres à votre compte.
- 4
Ajoutez l'enregistrement MX sur le sous-domaine front-mail
Créez un enregistrement MX : Host/Name = le libellé de sous-domaine affiché par Front (par ex. front-mail), Value/Target = le serveur de messagerie de SendGrid (par ex. mx.sendgrid.net), Priority = comme indiqué (Front utilise couramment 10). Il s'agit d'un NOUVEAU MX sur le sous-domaine pour la gestion des rebonds de SendGrid — il ne change PAS votre MX principal (hôte @) ni l'endroit où votre courrier entrant est distribué.
- 5
Ajoutez l'enregistrement SPF (TXT)
Créez un enregistrement TXT : Host/Name = front-mail, Value = exactement ce que Front affiche (par ex. v=spf1 include:sendgrid.net ~all). Ce SPF est limité au seul sous-domaine d'envoi — n'ajoutez PAS include:sendgrid.net à l'enregistrement SPF de votre domaine racine.
- 6
Ajoutez l'enregistrement DKIM (TXT)
Créez un enregistrement TXT avec l'hôte du sélecteur affiché par Front (par ex. s1._domainkey.front-mail) et collez la longue valeur de clé publique de Front exactement, sans espaces ni sauts de ligne ajoutés. Front utilise le whitelabel classique de SendGrid, il s'agit donc d'une unique clé TXT statique, et non des CNAME à rotation automatique de l'authentification de domaine SendGrid moderne.
- 7
Saisissez les hôtes uniquement sous forme de libellés et ne touchez pas aux enregistrements existants
Saisissez uniquement le libellé (front-mail, s1._domainkey.front-mail) — la plupart des registraires ajoutent automatiquement votre domaine, et saisir le front-mail.yourdomain.com complet produit un nom doublé qui ne se résoudra pas. Ajoutez uniquement ces trois NOUVEAUX enregistrements ; ne modifiez ni ne supprimez aucun enregistrement DNS existant, ce qui pourrait casser la distribution.
- 8
Publiez votre politique DMARC (si vous n'en avez pas)
Sur votre domaine racine, ajoutez un enregistrement TXT sur _dmarc avec v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Conservez un seul et unique enregistrement _dmarc pour tout le domaine. Laissez l'alignement à sa valeur relâchée par défaut — le sous-domaine front-mail de Front porte à la fois SPF et DKIM en mode relâché, ne définissez donc pas aspf=s ni adkim=s, qui casseraient l'un comme l'autre l'authentification de Front.
- 9
Cliquez sur « Check DNS settings » dans Front
Retournez au panneau de délivrabilité de Front et cliquez sur « Check DNS settings » — cela déclenche une vérification via SendGrid. Lorsque les enregistrements se résolvent, chacun bascule sur Verified et l'icône d'avertissement jaune disparaît du canal. La propagation DNS prend généralement quelques minutes mais peut atteindre 24 à 48 heures.
- 10
Envoyez un vrai test et confirmez l'alignement
Envoyez-vous un message depuis le canal Front, ouvrez-le dans Gmail et utilisez ⋮ → Afficher l'original. Confirmez SPF: PASS, DKIM: PASS signed-by front-mail.yourdomain.com, DMARC: PASS, et que la mention « via sendgrid.net » a disparu de la ligne d'expéditeur.
Enregistrements à ajouter
Front génère les valeurs exactes dans son assistant de configuration — celles-ci illustrent la forme de ce que vous ajouterez chez votre hébergeur DNS.
| Type | Hôte | Valeur |
|---|---|---|
| MX | front-mail | mx.sendgrid.netReturn-Path du sous-domaine d'envoi — le serveur de rebonds de SendGrid, priorité telle qu'indiquée par Front (couramment 10). Le sous-domaine et l'hôte exacts proviennent du panneau de délivrabilité de Front. Ce n'est PAS votre MX principal et cela n'affecte pas le courrier entrant. |
| TXT | front-mail | v=spf1 include:sendgrid.net ~allSPF pour le sous-domaine d'envoi uniquement — jamais ajouté à votre domaine racine, il ne coûte donc 0 des 10 requêtes de votre SPF racine. Copiez la valeur exacte depuis Front. |
| TXT | s1._domainkey.front-mail | k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…Clé publique DKIM (unique TXT statique). Front/SendGrid fournit le sélecteur et la clé exacts — l'hôte et la valeur sont propres à votre compte ; ceci est illustratif. Comme la clé réside sous front-mail, le d= de la signature est le sous-domaine et s'aligne sur votre domaine en mode relâché. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVotre politique DMARC — une par domaine racine. Front s'authentifie entièrement via le sous-domaine front-mail, gardez donc l'alignement relâché (le mode par défaut) ; le mode strict (aspf=s ou adkim=s) casse Front. |
Conservez exactement un seul enregistrement SPF (v=spf1) TXT sur votre domaine racine — fusionnez-y tous vos expéditeurs. Avoir deux enregistrements SPF constitue en soi une erreur.
Le budget de 10 requêtes DNS
SPF est plafonné à une limite stricte de 10 requêtes DNS — dépassez-la et il renvoie une permerror et cesse de valider partout. Voici ce que coûte la configuration de Front sur ce budget.
La configuration recommandée de Front ajoute 0 requête — les 10 restent disponibles pour les expéditeurs qui, eux, ont besoin d'un include:.
DKIM
Le DKIM pour Front est un unique enregistrement TXT de clé publique statique que Front génère via SendGrid et vous affiche dans le panneau de délivrabilité. Vous le publiez sur le sélecteur du sous-domaine d'envoi (quelque chose comme s1._domainkey.front-mail.yourdomain.com) ; SendGrid détient la clé privée correspondante et signe chaque message que Front relaie. Comme la clé réside sous front-mail, la signature DKIM porte d=front-mail.yourdomain.com, qui s'aligne sur votre domaine organisationnel en mode relâché — le mode par défaut de DMARC — tout comme le Return-Path SPF. Elle ne s'aligne pas en mode strict, ne définissez donc pas adkim=s pour ce domaine. Deux éléments distinguent le DKIM de Front de l'authentification de domaine SendGrid moderne. Premièrement, c'est une clé TXT statique, et non un CNAME à rotation automatique — Front utilise le whitelabel classique de SendGrid, vous collez donc la clé une fois et elle ne tourne pas d'elle-même (rien n'est délégué à re-résoudre, mais rien ne fait tourner les clés à votre place non plus). Deuxièmement, comme il s'agit d'une clé publique complète dans une valeur TXT, elle peut dépasser la limite de 255 caractères d'une chaîne unique ; la plupart des panneaux DNS la stockent automatiquement en un enregistrement fragmenté, mais si un vérificateur signale plus tard la clé comme invalide, une valeur altérée ou tronquée en est la cause habituelle — recollez-la exactement telle que Front l'affiche. Le sélecteur attribué par SendGrid n'entrera pas en conflit avec vos sélecteurs DKIM Google (google) ou Microsoft (selector1/selector2), le DKIM de Front coexiste donc avec celui de votre fournisseur de boîtes de réception. DKIM reste le plus résistant au transfert de vos deux signaux — il survit au transfert de message là où SPF se casse — mais pour l'alignement DMARC il repose sur le même mode relâché que SPF, gardez donc l'alignement de votre politique en mode relâché.
DMARC
DMARC est un enregistrement de politique distinct que vous publiez sur votre domaine racine — Front ne le crée pas pour vous, même si sa documentation de délivrabilité vous guide dans cette interaction. Ajoutez un enregistrement TXT sur _dmarc.yourdomain.com commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance seule, il n'affectera donc pas la distribution pendant que vous confirmez que le courrier Front s'authentifie. Le piège propre à Front concerne l'alignement : comme SendGrid utilise le sous-domaine front-mail à la fois pour le Return-Path de l'enveloppe ET pour le domaine DKIM d=, le courrier Front s'aligne sur votre domaine organisationnel en mode RELÂCHÉ à la fois pour SPF et DKIM — et en mode STRICT pour aucun des deux. Le mode relâché est celui par défaut de DMARC, une politique standard fait donc passer Front dès le départ ; vous n'avez rien à ajouter. Les problèmes n'apparaissent que si votre DMARC existant force l'alignement strict : aspf=s casse l'alignement SPF de Front et adkim=s casse son alignement DKIM, et le strict sur les deux fait totalement échouer Front. Gardez l'alignement en mode relâché (vous pouvez le rendre explicite avec aspf=r; adkim=r). Conservez un seul et unique enregistrement _dmarc pour tout le domaine, quel que soit le nombre d'expéditeurs (Front, votre hébergeur de boîtes de réception, vos outils marketing) que vous utilisez — n'ajoutez jamais un second enregistrement DMARC pour Front. Une fois que les rapports agrégés confirment que Front/SendGrid s'authentifie proprement, resserrez de p=none vers p=quarantine puis, à terme, p=reject.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas au seul badge « Verified » de Front — confirmez-le sur un vrai message. Après que « Check DNS settings » affiche les enregistrements comme Verified, envoyez-vous un e-mail depuis le canal Front, ouvrez-le dans Gmail et choisissez ⋮ → Afficher l'original. Vous devez obtenir SPF: PASS (mailed-by front-mail.yourdomain.com), DKIM: PASS avec signed-by: front-mail.yourdomain.com, et DMARC: PASS — et la mention « via sendgrid.net » doit avoir disparu de la ligne d'expéditeur. Vous pouvez vérifier ponctuellement les enregistrements bruts avec dig MX front-mail.yourdomain.com (attendez mx.sendgrid.net), dig TXT front-mail.yourdomain.com (attendez la ligne v=spf1 include:sendgrid.net), dig TXT s1._domainkey.front-mail.yourdomain.com (attendez la clé DKIM) et dig TXT _dmarc.yourdomain.com. Passez ensuite votre domaine dans la vérification de l'état du domaine de Qualisend pour confirmer que chaque enregistrement se résout et que votre SPF racine reste sous la limite de 10 requêtes, et une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC — Front devrait apparaître comme une source alignée et conforme (infrastructure SendGrid signant au nom de votre domaine).
Pièges courants
- Couverture
L'enregistrement MX que Front demande n'est PAS votre MX principal. Il réside sur le sous-domaine front-mail et permet seulement à SendGrid de traiter les rebonds du courrier sortant de Front — il ne réachemine pas votre boîte de réception ni ne change l'endroit où le courrier entrant est distribué. Votre MX existant sur l'hôte @ reste intact.
- Couverture
Saisissez les hôtes uniquement sous forme de libellé — front-mail, s1._domainkey.front-mail — et non le front-mail.yourdomain.com complet. La plupart des registraires ajoutent automatiquement votre domaine, et le nom doublé (front-mail.yourdomain.com.yourdomain.com) ne se résoudra pas, faisant donc échouer « Check DNS settings ».
- Couverture
Ajoutez uniquement trois NOUVEAUX enregistrements. Front avertit explicitement de ne pas modifier ni supprimer les enregistrements DNS existants pendant ce processus — modifier votre SPF, MX ou DKIM actuel peut casser la distribution.
- Configuration DNS
N'ajoutez pas include:sendgrid.net à votre SPF RACINE. Front limite le SPF au sous-domaine front-mail, un include racine est donc redondant, consomme inutilement une de vos 10 requêtes SPF et n'est pas ce que SendGrid vérifie pour Front.
- Couverture
L'alignement DMARC strict casse Front. Le Return-Path de l'enveloppe et la clé DKIM résident tous deux sur le sous-domaine front-mail, SPF et DKIM ne s'alignent donc chacun sur votre domaine qu'en mode relâché. Définir aspf=s casse l'alignement SPF de Front et adkim=s casse son alignement DKIM — le strict sur les deux fait totalement échouer Front. Le mode relâché est celui par défaut, ne touchez donc pas à l'alignement.
- Couverture
Les canaux Gmail / Microsoft 365 connectés n'utilisent pas du tout ces enregistrements. Si Front envoie via votre boîte de réception Google ou Microsoft plutôt que par un canal SMTP, il n'y a pas de sous-domaine front-mail ni de mention via — authentifiez chez ce fournisseur à la place.
- Configuration DNS
Les enregistrements MX et TXT ne peuvent pas être proxifiés, il n'y a donc pas d'étape nuage orange/nuage gris ici sur Cloudflare (contrairement à l'authentification de domaine SendGrid basée sur CNAME). Assurez-vous simplement de les avoir créés en tant que MX et TXT, et non sous un autre type.
- Couverture
Chaque domaine et canal d'envoi SMTP est authentifié séparément. Configurer un domaine ne couvre pas les autres — le panneau de délivrabilité signale par une icône d'avertissement jaune tout domaine auquel il manque encore des enregistrements.
Construisez votre enregistrement SPF
Front n'a pas besoin d'un include: SPF sur votre domaine racine — utilisez le générateur pour assembler un enregistrement propre et unique pour vos autres expéditeurs, en le limitant à une seule ligne.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF Front — FAQ
Lectures complémentaires
Une fois publié, confirmez que tout se résout correctement avec la vérification de l'état du domaine, puis identifiez qui envoie en votre nom grâce à l'analyseur de rapports DMARC. Parcourez toutes les sources d'envoi dans le générateur. L'authentification ne représente toutefois que la moitié de la délivrabilité — une IP ou un domaine d'envoi inscrit sur une liste vous fait toujours atterrir dans les spams, quelle que soit la propreté de votre SPF ; il vaut donc la peine de surveiller les listes noires avec la surveillance des listes noires.
Authentifié — maintenant, gardez votre liste propre
Réussir SPF, DKIM et DMARC vous mène jusqu'à la boîte de réception ; une liste propre vous y maintient. Vérifiez la vôtre — commencez gratuitement avec 100 crédits, sans carte bancaire.