Configurer Google Workspace (SPF, DKIM, DMARC) chez IONOS
Trois enregistrements TXT à créer dans ta zone DNS IONOS : le SPF, le DKIM et le DMARC. Le SPF et le DMARC sont des valeurs fixes que tu peux recopier d'ici ; le DKIM, lui, se génère d'abord dans la console d'administration Google, se colle ensuite chez IONOS, puis s'active en revenant chez Google — dans cet ordre. Compte 20 minutes devant l'écran, moins d'une heure de propagation chez IONOS et jusqu'à 48 h avant que Google confirme. Vérifié sur la documentation officielle le 05/09/2026.
Concrètement, ces trois lignes disent aux serveurs qui reçoivent tes emails que Google a le droit d'envoyer en ton nom, et leur donnent une consigne quand quelqu'un d'autre essaie. Ça ne garantit pas l'arrivée en boîte de réception — le contenu de tes emails et ta réputation d'expéditeur comptent au moins autant — mais sans ça, tu pars avec un handicap sérieux.
Le point qui rend cette page utile : IONOS revend lui-même Google Workspace. Si tu l'as souscrit chez eux, IONOS a connecté ton domaine à Gmail — mais aucune de ses pages consacrées à Google Workspace ne mentionne DKIM ni DMARC. Ces deux enregistrements restent à ta charge, à 100 %. Et dans tous les cas, IONOS active son propre SPF par défaut sur les domaines qu'il héberge : la première cause de panne ici, c'est le doublon, pas l'oubli.
Ce qu'on ne fait pas : on ne touche jamais à ta zone DNS. On lit, on prescrit, tu colles — dans ton compte IONOS, avec tes accès.
Les valeurs à copier-coller
1. SPF — dire que Google a le droit d'envoyer
| Champ IONOS | Valeur |
|---|---|
| Type | TXT |
| Nom d'hôte | @ |
| Valeur | v=spf1 include:_spf.google.com ~all |
Ce que tu dois remplacer : rien, si Google est ton seul outil d'envoi. Si tu envoies aussi des campagnes depuis un autre service, ajoute son include: dans la même ligne :
v=spf1 include:_spf.google.com include:spf.brevo.com ~all
Et si tu gardes des boîtes IONOS actives à côté de Gmail — cas rare, puisque les MX ne peuvent pointer que vers l'un des deux, mais possible pour des envois techniques —, la ligne fusionnée devient v=spf1 include:_spf.google.com include:_spf-eu.ionos.com ~all. _spf-eu.ionos.com est la valeur que la documentation française d'IONOS publie pour ses serveurs.
Sur le ~all de la fin : c'est la valeur que Google recommande. Il signifie « si ça vient d'ailleurs, marque-le comme suspect » plutôt que « jette-le ». C'est le bon réglage pour commencer, parce qu'un outil oublié dans ta liste ne fera pas disparaître tes emails du jour au lendemain.
⚠️ Un domaine ne doit avoir qu'une seule ligne SPF. Chez IONOS, c'est le piège n°1 : IONOS écrit que « IONOS SPF est activé par défaut pour tous les domaines hébergés par IONOS ». Regarde ta zone avant d'ajouter : s'il y a déjà une ligne
v=spf1, tu la modifies pour y mettreinclude:_spf.google.com, tu n'en crées pas une deuxième.
2. DKIM — la signature de tes emails
| Champ IONOS | Valeur |
|---|---|
| Type | TXT |
| Nom d'hôte | google._domainkey |
| Valeur | v=DKIM1; k=rsa; p=LA-LONGUE-CLE-GENEREE-DANS-TA-CONSOLE |
Ce que tu dois remplacer : toute la partie après p=. C'est une clé publique générée pour ton domaine dans ta console d'administration Google — une valeur trouvée dans un tutoriel ne signera jamais tes emails.
Le préfixe google est celui que la console propose par défaut, et Google le qualifie d'« option recommandée ». Tu n'en changes que si ton domaine utilise déjà une clé DKIM avec ce préfixe — Google demande alors d'en « saisir un autre » —, et le nom d'hôte à créer chez IONOS devient tonprefixe._domainkey.
Le choix qui compte au moment de générer : Google propose 2 048 bits — « sélectionnez cette option si votre fournisseur de domaine accepte les clés de 2 048 bits » — ou 1 024 bits en repli. Une clé 2 048 bits produit une valeur de plus de 400 caractères, alors que le protocole DNS limite chaque chaîne d'un TXT à 255 caractères. La solution documentée par Google : « Divisez les caractères de la clé en plusieurs chaînes de texte », chacune entre guillemets, dans le même enregistrement. Ce n'est pas une bizarrerie d'IONOS, c'est le protocole ; le serveur qui vérifie recolle les morceaux tout seul.
3. DMARC — la consigne donnée aux boîtes de réception
| Champ IONOS | Valeur |
|---|---|
| Type | TXT |
| Nom d'hôte | _dmarc |
| Valeur | v=DMARC1; p=none; rua=mailto:TON-ADRESSE@TON-DOMAINE.fr |
Ce que tu dois remplacer : TON-ADRESSE@TON-DOMAINE.fr par une adresse que tu relèves vraiment. C'est là que tu recevras les rapports. Google conseille d'ailleurs « une boîte aux lettres ou un groupe dédié » pour ça — utile dès que les rapports arrivent tous les jours.
Pourquoi p=none pour commencer : ça veut dire « observe et raconte-moi ». Personne n'est bloqué, et tu reçois les rapports. Google le dit lui-même : « Lorsque vous commencez à utiliser DMARC, nous vous recommandons de définir l'option de règle (p) sur none. » Tu regardes pendant 2 à 4 semaines, tu vérifies que tous tes outils légitimes — Gmail, mais aussi ton site, ton logiciel de facturation, ton outil de campagnes — sont bien reconnus, et seulement après tu durcis d'un cran vers p=quarantine, puis p=reject.
Deux mauvais exemples à ne pas recopier, tous deux tirés de documentations officielles. La page IONOS montre p=reject d'emblée, et même des valeurs traduites — p=rejet, p=quarantaine — qui ne sont pas des valeurs DMARC valides : les mots-clés s'écrivent en anglais, toujours. La page Google, elle, ajoute pct=100 à son exemple : on ne le met pas. Ce paramètre a été retiré de la norme par la RFC 9989, publiée en mai 2026, et à 100 il ne faisait de toute façon rien de plus que le comportement par défaut.
Si tu envoies plus de 5 000 messages par jour vers des adresses Gmail, ce n'est pas facultatif. Depuis le 1er février 2024, Google exige de ces expéditeurs le SPF et le DKIM (les deux, pas l'un ou l'autre) plus un enregistrement DMARC publié. Bonne nouvelle : Google précise que « votre règle d'application DMARC peut être définie sur none ». C'est la présence de l'enregistrement qui compte, pas sa sévérité. En dessous de ce seuil, SPF ou DKIM suffit — mais poser les trois reste le bon réflexe.
⚠️ Un domaine ne doit avoir qu'un seul enregistrement DMARC. Si tu en avais déjà un, tu le modifies, tu n'en ajoutes pas un second.
Et les MX, au passage
Si tu configures Google Workspace de zéro sur ce domaine, Google recommande aujourd'hui un seul enregistrement MX :
| Champ IONOS | Valeur |
|---|---|
| Type | MX |
| Nom d'hôte | @ |
| Pointe vers | smtp.google.com |
| Priorité | 1 |
Ce que tu dois remplacer : rien — c'est la seule valeur de cette page identique pour tout le monde. Si ton domaine tourne déjà avec les cinq anciens enregistrements en aspmx.l.google.com et compagnie, ne touche à rien : Google indique que les anciennes valeurs restent acceptées tant que ta messagerie fonctionne.
⚠️ Les MX, c'est la réception, et il ne peut y en avoir qu'un jeu. Un domaine IONOS neuf pointe par défaut vers
mx00.1and1.fretmx01.1and1.fr, les serveurs des boîtes IONOS. Basculer vers Google fait cesser la réception sur ces boîtes — IONOS le résume à sa façon : « Si un enregistrement MX appartient à un service, il doit être désactivé », et sa page Google Workspace précise que le domaine « ne peut pas être utilisé en même temps que d'autres produits de messagerie tels que Microsoft Exchange ou IONOS Mail Basic ». Vide et sauvegarde tes anciennes boîtes avant, pas après. Si tu as acheté Google Workspace via IONOS, cette bascule a normalement été faite pour toi : vérifie-la, ne la refais pas.
Le chemin de clics
Côté Google — générer la clé DKIM
- Connecte-toi à la console d'administration Google avec un compte administrateur. (Google Workspace acheté via IONOS : le premier compte est créé chez IONOS, mais l'administration se fait bien dans la console Google.)
- Menu → Applications → Google Workspace → Gmail.
- Ouvre Authentifier les e-mails.
- Sélectionne ton domaine, choisis la longueur de clé et le préfixe, puis clique sur Générer un nouvel enregistrement.
- Google affiche deux champs : Nom d'hôte DNS (nom de l'enregistrement TXT) et Valeur de l'enregistrement TXT. Ne clique pas encore sur « Lancer l'authentification » — Google l'écrit noir sur blanc à cette étape : « Vous le ferez plus tard. »
- Copie la valeur, va la créer chez IONOS (section suivante), puis reviens ici et clique sur Lancer l'authentification.
Avant activation, l'état affiché dit « Vous devez mettre à jour les enregistrements DNS pour ce domaine ». Quand c'est bon, il passe à Authentification des e-mails avec DKIM.
Sur un compte Google Workspace tout neuf, le bouton de génération peut ne rien donner pendant un moment : Google indique qu'il faut « attendre entre 24 et 72 heures » après l'activation de Gmail avant d'obtenir sa clé DKIM dans la console. Ce n'est pas un bug, c'est le délai annoncé. Pose le SPF et le DMARC en attendant.
Côté IONOS — créer les entrées
- Connecte-toi à ton compte IONOS et va dans la section Domaines et SSL.
- Sur la ligne de ton domaine, clique sur l'icône de roue dentée dans la colonne Actions, puis sur DNS.
- Regarde d'abord le tableau. Y a-t-il déjà une ligne TXT commençant par
v=spf1? Un_dmarc? Si oui, tu vas modifier, pas ajouter. - Clique sur Ajouter un enregistrement, puis choisis le type TXT.
- Remplis le champ Nom d'hôte (
@,google._domainkeyou_dmarc), puis le champ de la valeur — libellé Valeur ou Pointe vers selon l'écran, c'est le même champ. Laisse le TTL proposé. - Clique sur Enregistrer.
Le champ « Nom d'hôte » attend la partie gauche uniquement. IONOS ajoute automatiquement ton nom de domaine à la fin — sa documentation le confirme : en saisissant
_dmarc, « le sous-domaine_dmarc.votre-domaine.frest automatiquement créé ». Doncgoogle._domainkey, pasgoogle._domainkey.tondomaine.fr, sinon tu créesgoogle._domainkey.tondomaine.fr.tondomaine.fr. Le@désigne le domaine lui-même, sans rien devant.
Pour modifier une entrée existante : dans le tableau de la zone, clique sur la roue dentée de la ligne concernée, puis Modifier un enregistrement, corrige la valeur, Enregistrer.
L'entrée toute prête « IONOS SPF (TXT) », un mot dessus. Dans le sélecteur de type, IONOS propose ce préréglage qui écrit le SPF de ses serveurs. Il n'est pas fait pour Google : ne l'utilise que si tu envoies vraiment depuis des boîtes IONOS. IONOS précise que, si une ligne SPF existe déjà « pour un autre service de messagerie, elle est automatiquement complétée par les informations du serveur de messagerie IONOS » — donc si tu cliques dessus après avoir posé la ligne Google, tu te retrouves avec include:_spf-eu.ionos.com en plus dans ta ligne. Pas cassé, mais pas voulu non plus.
Retour côté Google — activer
Une fois le TXT DKIM visible dans ta zone IONOS, reviens dans Applications → Google Workspace → Gmail → Authentifier les e-mails et clique sur Lancer l'authentification. Si Google affiche encore un message d'attente, ce n'est pas forcément raté : IONOS annonce moins d'une heure de propagation, Google jusqu'à 48 h pour que la signature soit reconnue. Attends une heure et réessaie avant de tout défaire — et surtout, ne régénère pas la clé.
Les 3 erreurs qu'on voit le plus souvent sur cette configuration
1. Deux lignes SPF, parce qu'IONOS en avait déjà une
C'est l'erreur reine sur cette combinaison. IONOS active son SPF par défaut sur les domaines qu'il héberge ; tu ajoutes celui de Google en suivant la doc Google ; tu te retrouves avec deux lignes v=spf1 sur le même domaine. Résultat : le SPF ne fonctionne plus du tout, ni pour Google, ni pour personne.
Un détail qui brouille les pistes : la documentation IONOS se contredit. Sa page SPF affirme que « IONOS SPF est activé par défaut pour tous les domaines hébergés par IONOS », sa page sur les paramètres par défaut affirme que « par défaut, aucun enregistrement TXT, CNAME et SRV n'est configuré ». Ne fais confiance ni à l'une ni à l'autre : regarde ta zone, et scanne ton domaine pour voir ce que le monde extérieur reçoit vraiment.
Comment tu le reconnais : ton scan affiche « plusieurs SPF détectés », ou tes rapports DMARC montrent un SPF en erreur (permerror) alors que chaque ligne prise séparément a l'air correcte. Certains destinataires t'acceptent, d'autres non.
Le correctif : une seule ligne, tous les include: dedans. Tu modifies l'existante via la roue dentée → Modifier un enregistrement, et tu supprimes l'autre. Si tu n'envoies plus rien depuis IONOS, include:_spf-eu.ionos.com peut disparaître de la ligne.
2. Le nom de domaine tapé en entier dans « Nom d'hôte »
La console Google affiche le nom d'hôte DKIM sous la forme google._domainkey, mais beaucoup de tutoriels — et certains autres hébergeurs — attendent le nom complet google._domainkey.tondomaine.fr. Chez IONOS, non : le champ attend la partie gauche seule, et le domaine est ajouté derrière.
Comment tu le reconnais : Google refuse d'activer DKIM alors que la clé est bien collée. Dans le tableau de la zone IONOS, la colonne du nom d'hôte affiche ton domaine deux fois — google._domainkey.tondomaine.fr.tondomaine.fr. Même symptôme pour un DMARC posé sur _dmarc.tondomaine.fr : le scan dit « aucun DMARC trouvé » alors que la ligne existe.
Le correctif : modifie l'entrée et ne garde que google._domainkey (ou _dmarc) dans le champ Nom d'hôte. Tu n'as pas besoin de régénérer la clé.
3. Cliquer sur « Lancer l'authentification » trop tôt, puis régénérer la clé
Google impose un ordre : on génère la clé, on la publie dans le DNS, et seulement ensuite on clique sur le bouton d'activation. Fait dans le désordre, ça échoue — et beaucoup de gens en concluent que leur clé est mauvaise et cliquent sur Générer un nouvel enregistrement, ce qui invalide celle qu'ils venaient de coller chez IONOS. Boucle infernale.
Comment tu le reconnais : la console reste sur « Vous devez mettre à jour les enregistrements DNS pour ce domaine », et tu as régénéré la clé au moins une fois « pour voir ». La valeur dans ta zone IONOS ne correspond plus à celle affichée par Google.
Le correctif : arrête de régénérer. Compare caractère par caractère la valeur présente chez IONOS avec la dernière clé affichée dans la console, corrige si besoin, attends une heure, puis clique une seule fois. Nuance utile : Google n'impose pas de durée d'attente entre la publication et le clic — les 48 h annoncées sont un délai maximal de prise d'effet, pas une consigne d'attente.
Combien de temps avant que ça prenne effet
- Chez IONOS : la modification est prise en compte immédiatement dans ton compte.
- Sur Internet : IONOS applique un TTL d'une heure à tous ses enregistrements, donc « maximum une heure » pour que le changement soit visible partout — avec un cas exceptionnel annoncé jusqu'à 72 h quand un fournisseur d'accès ignore le TTL.
- Côté Google : jusqu'à 48 h pour que l'authentification SPF fonctionne, et « un délai maximal de 48 heures » pour DKIM après l'ajout de la clé. La console peut afficher un message d'attente pendant ce temps.
- Avant DMARC : Google demande d'attendre 48 h après la mise en place de SPF et DKIM avant de publier DMARC. En
p=none, poser les trois le même jour ne casse rien — mais si tu veux suivre Google à la lettre, pose le DMARC le surlendemain. - Pour les rapports DMARC : les premiers arrivent 24 à 72 h après la publication de l'enregistrement, puis environ une fois par jour.
Résumé utile : compte une heure chez IONOS, puis jusqu'à 48 h côté Google. Crée tout d'un coup, va faire autre chose, reviens cliquer le lendemain.
Pour aller plus loin
- Configurer SPF, DKIM et DMARC chez IONOS
- Configurer Microsoft 365 (SPF, DKIM, DMARC) chez IONOS
- Configurer Google Workspace (SPF, DKIM, DMARC) chez OVH
- Passer son DMARC en p=reject sans casser ses emails