IONOS : SPF, DKIM et DMARC pour la messagerie et la zone DNS

exemple.fr.  TXT  "v=spf1 include:_spf-eu.ionos.com ~all"

DMARC : le TXT _dmarc

L'enregistrement DMARC est un TXT publié sous le sous-domaine _dmarc :

_dmarc.exemple.fr.  TXT  "v=DMARC1; p=none; rua=mailto:rapports@exemple.fr"

On commence toujours en p=none : la politique n'impose rien, mais l'adresse rua= déclenche l'envoi des rapports agrégés qui serviront à tout vérifier avant de durcir. Dans l'interface DNS d'IONOS, le champ de nom attend le sous-domaine relatif _dmarc — la plateforme complète le domaine. Les exemples commentés, balise par balise détaillent les balises à retenir. Sous DMARCbis, le rattachement des sous-domaines se détermine par le DNS Tree Walk, sans changer la façon de publier l'enregistrement chez IONOS.

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 champ From. La messagerie IONOS se place dans le cas favorable, à l'image d'un hébergement de courrier classique. Côté DKIM, la signature porte le domaine lui-même — l'alignement est direct. Côté SPF, l'enveloppe des messages est également au domaine, puisque c'est IONOS qui héberge le courrier de ce domaine : SPF s'aligne donc naturellement.

Deux mécanismes passent alignés, et cette redondance protège : si une redirection casse SPF, DKIM survit, et réciproquement. C'est l'assise qui autorise à viser sereinement une politique stricte — une fois la couverture confirmée par les rapports. La souveraineté des données joue ici en complément : l'ensemble du traitement du courrier et des journaux associés reste dans l'Union européenne, un point qui compte pour les organisations soumises à des exigences de localisation, même s'il ne change rien à la mécanique d'alignement.

DNS chez IONOS ou délégué ailleurs

Comme pour tout hébergeur, un contrôle préalable évite l'erreur la plus frustrante : s'assurer que la zone DNS du domaine est réellement gérée par IONOS. Un domaine peut être enregistré chez IONOS mais avoir ses serveurs de noms délégués à un autre fournisseur ; dans ce cas, l'interface DNS d'IONOS affiche une zone qui ne fait plus autorité, et les enregistrements qu'on y ajoute ne sont jamais servis.

Ce contrôle est d'autant plus important chez IONOS que l'activation automatique de DKIM en dépend : elle ne publie l'enregistrement toute seule que si la zone est chez IONOS. Zone déléguée ailleurs ⇒ DKIM activé dans l'espace mail mais enregistrement à publier à la main dans l'autre interface. Oublier cette étape laisse un DKIM « activé » côté IONOS mais absent du DNS effectif — un décalage qui explique bien des signatures manquantes dans les rapports.

Boîte IONOS ou Microsoft 365 revendu

IONOS ne vend pas qu'une seule messagerie. À côté de ses boîtes mail maison, il revend Microsoft 365 — et l'include SPF n'est pas le même. Une boîte IONOS classique passe par _spf-eu.ionos.com ; un Microsoft 365 souscrit via IONOS émet, lui, par l'infrastructure de Microsoft, et son include est include:spf.protection.outlook.com. Confondre les deux est une variante du piège de l'héritage : le domaine porte un include qui ne correspond pas au service réellement émetteur, et SPF échoue.

Le réflexe est le même que pour tout hébergeur revendant plusieurs produits : identifier lequel est effectivement actif — la boîte maison ou le Microsoft 365 revendu — avant de figer l'include. Un domaine migré de l'un à l'autre sans reprendre son SPF traîne un include périmé, source d'échecs sans cause apparente. Ce cas est d'autant plus fréquent qu'IONOS met en avant les deux offres dans le même parcours d'achat.

La rotation de la clé DKIM

Quand la zone est chez IONOS, l'activation automatique de DKIM simplifie aussi la rotation : IONOS gère le renouvellement de la clé de son côté, sans intervention manuelle sur la zone. Cette prise en charge est un atout — la rotation, souvent négligée quand elle exige une édition manuelle, devient un non-événement, et une clé ancienne ne s'éternise pas.

Quand la zone est déléguée ailleurs, en revanche, la rotation redevient manuelle : chaque nouvelle clé publiée par IONOS doit être reportée dans l'interface DNS externe, en suivant le principe de recouvrement — publier la nouvelle avant de retirer l'ancienne, pour ne pas ouvrir de fenêtre sans signature valide. C'est la même logique que toute remplacement périodique du matériel de signature, simplement à faire à la main plutôt qu'automatiquement.

Les erreurs de configuration courantes

Plusieurs pièges reviennent dans le corpus de rapports que l'analyseur DMARC gratuit traite au quotidien.

Garder les include 1&1 hérités. _spf.perfora.net / _spf.kundenserver.de empilés avec l'include actuel alourdissent l'enregistrement et rapprochent du permerror.

Activer DKIM sans publier la clé (zone déléguée). DKIM coché dans l'espace mail, mais la zone étant ailleurs, l'enregistrement n'a jamais été posé : aucune signature valide.

Publier deux enregistrements SPF. Deux v=spf1 invalident SPF entièrement ; il faut fusionner les include dans un seul.

Confondre boîte IONOS et Microsoft 365 revendu. Publier _spf-eu.ionos.com pour un domaine qui émet en réalité via le M365 revendu (ou l'inverse) : l'include ne couvre pas les serveurs réels, et SPF échoue.

Durcir la politique trop tôt. Passer à p=reject avant d'avoir confirmé par les rapports que tout le trafic légitime s'aligne revient à rejeter ses propres messages — d'autant plus pénalisant quand la messagerie IONOS porte le courrier métier quotidien.

La contre-épreuve : les rapports RUA

La seule preuve qu'une configuration tient n'est pas l'espace IONOS, mais ce que rapportent les destinataires. Une fois l'enregistrement _dmarc publié avec une adresse rua=, les rapports agrégés arrivent sous quelques jours et détaillent, source par source, ce qui s'aligne et ce qui échoue. La lecture des rapports DMARC agrégés confirme que le trafic IONOS est bien rattaché au domaine : DKIM aligné, SPF aligné, et aucune source qui échouerait sur les deux.

Une cadence simple suffit : une première lecture quelques jours après la configuration, une fois que plusieurs destinataires ont rapporté, puis un coup d'œil hebdomadaire tant que la politique reste en p=none. On vérifie en particulier que l'include SPF retenu couvre bien toutes les sources IONOS et qu'aucun héritage 1&1 ne fausse le tableau. Une fois cette couverture confirmée sur plusieurs jours, la montée vers p=reject se fait sans risque. L'analyseur en ligne recompose cet état à partir des enregistrements publiés et des rapports reçus, et situe le domaine sur le chemin qui mène à p=reject.