Skip to content
Commencez avec 100 crédits de vérification gratuits
Qualisend
Guide de configuration SPF

SPF, DKIM et DMARC pour Titan.

Titan est un fournisseur de messagerie hébergée : il vous fournit de véritables boîtes aux lettres (envoi et réception) sur votre propre domaine, et il est proposé en marque blanche et revendu par de nombreux hébergeurs et bureaux d'enregistrement (Hostinger, hosting.com, Bluehost, A2 Hosting, Crazy Domains et d'autres). Votre tableau de bord peut donc porter la marque de l'entité auprès de laquelle vous l'avez acheté. Parce que chaque message quitte les serveurs de Titan au nom de votre domaine, les destinataires chez Gmail, Yahoo, Outlook et Apple évalueront ces messages au regard des enregistrements SPF, DKIM et DMARC publiés dans le DNS de VOTRE domaine. Titan simplifie l'opération : il publie un include SPF partagé, génère une clé DKIM par compte dans son Control Panel et vous laisse ajouter DMARC. Ce guide vous accompagne de bout en bout sur les trois volets, avec les formats d'enregistrement exacts de Titan, le chemin du Control Panel pour DKIM et la manière de vérifier chacun d'eux.

Include SPF
Your DNSAdd the CNAME / TXT records
TitanSigns & sends as your domain
The inboxSPF · DKIM · DMARC pass

Pourquoi authentifier Titan ?

Depuis février 2024, Gmail et Yahoo exigent que chaque expéditeur dispose d'un enregistrement SPF ou DKIM valide, et les expéditeurs en masse doivent avoir DMARC avec alignement de domaine — les messages qui échouent sont placés dans le dossier spam ou rejetés purement et simplement. Même pour une petite entreprise exploitant une poignée de boîtes Titan, l'absence d'authentification est la cause la plus fréquente pour laquelle un courrier légitime atterrit dans les spams ou est renvoyé. SPF indique aux destinataires que les serveurs de Titan sont autorisés à envoyer en votre nom ; DKIM signe chaque message de façon cryptographique afin qu'il ne puisse être ni falsifié ni altéré ; DMARC relie les deux, indique aux destinataires quoi faire des messages qui échouent et vous envoie des rapports pour voir qui envoie au nom de votre domaine. Publier les trois, c'est ce qui transforme « un e-mail depuis Titan » en « un e-mail authentifié et digne de confiance provenant de votre marque ».

La réalité SPF pour Titan

Titan publie un véritable include SPF partagé, et c'est BIEN la voie recommandée : ajoutez `include:spf.titan.email` à l'unique enregistrement SPF TXT racine de votre domaine. Derrière cet include unique, `spf.titan.email` se déploie en trois includes imbriqués (`_spf1.titan.email`, `_spf2.titan.email`, `_spf3.titan.email`) plus un bloc de plages `ip4:` en ligne — de sorte que le seul mécanisme `include:spf.titan.email` consomme en réalité environ 4 des 10 requêtes DNS autorisées par SPF. Parce que Titan est votre hébergeur de boîtes aux lettres (et non un canal secondaire comme un outil marketing) et qu'il envoie avec votre propre domaine comme expéditeur d'enveloppe, cet include a sa place dans l'enregistrement SPF de votre domaine principal, et non sur un sous-domaine — et c'est ce qui permet à SPF de s'aligner sur votre domaine pour DMARC. Publiez exactement un seul enregistrement SPF par domaine : si vous avez déjà un SPF pour un autre expéditeur, fusionnez l'include de Titan dans cet enregistrement existant plutôt que de créer une deuxième ligne `v=spf1`, ce qui casserait entièrement SPF.

Étape par étape

Titan Control Panel (peut porter la marque Hostinger, Bluehost, hosting.com, etc.)
  1. 1

    Confirmez que Titan est actif sur votre domaine

    Connectez-vous à votre Titan Control Panel (via le tableau de bord de votre hébergeur/bureau d'enregistrement — souvent un bouton « Admin login » ou « Manage » à côté de votre produit de messagerie). Si votre domaine apparaît encore comme non vérifié, vous ajouterez d'abord les enregistrements MX de Titan pour que Titan puisse recevoir le courrier. L'authentification (SPF/DKIM/DMARC) est distincte des MX, mais Titan doit être actif avant de pouvoir générer DKIM.

Votre hébergeur DNS (bureau d'enregistrement ou fournisseur DNS), éditeur DNS/de zone
  1. 2

    Ajoutez les enregistrements MX de Titan (prérequis à la réception)

    Dans la zone DNS de votre domaine, créez deux enregistrements MX sur l'hôte racine (@) : mx1.titan.email avec la priorité 10 et mx2.titan.email avec la priorité 20, TTL 1 heure. Ils acheminent le courrier entrant vers Titan et sont indispensables au fonctionnement de la boîte aux lettres — ils n'authentifient pas le courrier sortant, mais vous les définissez dans la même zone DNS que les enregistrements ci-dessous.

Votre hébergeur DNS, éditeur DNS/de zone (enregistrement TXT, hôte @)
  1. 3

    Publiez l'enregistrement SPF

    Ajoutez un unique enregistrement TXT sur l'hôte racine (@) avec la valeur v=spf1 include:spf.titan.email ~all, TTL 1 heure. Utilisez le type d'enregistrement TXT (et non le type SPF obsolète). Si un enregistrement v=spf1 existe déjà pour un autre service, n'en ajoutez PAS un second — insérez include:spf.titan.email dans l'enregistrement existant, avant le ~all/-all, de sorte qu'il n'y ait qu'un seul enregistrement SPF.

Titan Control Panel → Email Reputation → DKIM
  1. 4

    Générez la clé DKIM dans Titan

    Dans le Titan Control Panel, ouvrez Email Reputation (via la connexion Manage / Admin du compte), repérez DKIM et cliquez pour ajouter/générer la clé. Titan crée une paire de clés publique/privée, conserve la clé privée pour signer votre courrier sortant et vous affiche un Host Name (généralement titan1._domainkey) ainsi qu'une longue valeur TXT commençant par v=DKIM1; k=rsa; p=… . Copiez les deux exactement — la valeur est propre à votre compte et ne peut être devinée.

Votre hébergeur DNS, éditeur DNS/de zone (enregistrement TXT, hôte titan1._domainkey)
  1. 5

    Publiez l'enregistrement TXT DKIM chez votre hébergeur DNS

    Créez un enregistrement TXT avec l'hôte fourni par Titan (par ex. titan1._domainkey) et collez la valeur v=DKIM1; k=rsa; p=… complète. Saisissez l'hôte exactement tel qu'affiché : la plupart des bureaux d'enregistrement n'attendent que titan1._domainkey et ajoutent votre domaine automatiquement, alors évitez de saisir le domaine complet en double. Si la clé publique est très longue, collez-la telle quelle — certains panneaux la découpent automatiquement en fragments de 255 caractères.

Titan Control Panel → Email Reputation → DKIM → Verify changes
  1. 6

    Vérifiez DKIM de retour dans le Control Panel

    Revenez à l'écran Email Reputation / DKIM de Titan, cochez « I've added TXT records in my DNS control panel » et cliquez sur Verify changes. Titan ne commencera pas à signer avec la clé tant que cette revérification n'aura pas abouti, même si l'enregistrement DNS est déjà correct. Le statut doit passer à VERIFIED ; prévoyez d'abord jusqu'à la durée de votre TTL (et jusqu'à quelques heures) pour la propagation du DNS.

Votre hébergeur DNS, éditeur DNS/de zone (enregistrement TXT, hôte _dmarc)
  1. 7

    Ajoutez un enregistrement DMARC (commencez à p=none)

    Créez un enregistrement TXT sur l'hôte _dmarc avec v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none surveille sans affecter la délivrabilité pendant que vous confirmez que SPF et DKIM réussissent et s'alignent tous deux sur votre domaine. L'adresse rua collecte les rapports XML agrégés qui montrent chaque source envoyant au nom de votre domaine — pointez-la vers une boîte que vous consultez réellement. L'alignement relâché par défaut réussit déjà pour Titan, vous n'avez donc pas besoin d'ajouter adkim=s/aspf=s.

Test dans n'importe quelle boîte de réception + outils Qualisend / de recherche DNS
  1. 8

    Vérifiez, puis renforcez l'application de DMARC

    Confirmez que tous les enregistrements se résolvent (voir Vérifier ci-dessous) et envoyez un message de test vers un compte Gmail, en vérifiant « Afficher l'original » pour SPF=PASS, DKIM=PASS et DMARC=PASS. Une fois que vos rapports affichent un alignement propre pendant une semaine ou deux, faites passer DMARC à p=quarantine, puis finalement à p=reject pour bloquer activement l'usurpation.

Enregistrements à ajouter

Titan 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.

TypeHôteValeur
MX@mx1.titan.emailPriorité 10. Réception uniquement — requis pour la boîte aux lettres, pas pour l'authentification du courrier sortant.
MX@mx2.titan.emailPriorité 20. Serveur de messagerie secondaire.
TXT@v=spf1 include:spf.titan.email ~allUn enregistrement SPF par domaine. Si vous envoyez aussi via d'autres services, fusionnez leurs mécanismes dans cet unique enregistrement avant le ~all.
TXTtitan1._domainkeyv=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC… (unique key from your Control Panel)À titre indicatif — l'hôte du sélecteur et la clé publique sont générés par compte dans le panneau Email Reputation de Titan. Copiez l'hôte et la valeur exacts que Titan vous affiche.
TXT_dmarcv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comCommencez à p=none pour surveiller, puis passez à quarantine et reject. Pointez rua vers une boîte que vous consultez réellement. Un enregistrement _dmarc par domaine — l'alignement relâché (par défaut) réussit déjà pour Titan.

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 Titan sur ce budget.

SPF 10-lookup budget4 used · 6 free

Titan utilise 4 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.

DKIM

Titan utilise des clés DKIM par compte que vous générez dans le Control Panel — il n'y a pas de délégation CNAME et rien n'est signé tant que vous n'avez pas à la fois publié la clé et procédé à sa revérification dans Titan. Ouvrez Email Reputation (accessible via la connexion Manage / Admin de votre compte Titan), repérez DKIM et générez la paire de clés. Titan conserve la clé privée et signe le courrier sortant ; il vous affiche un Host Name — généralement titan1._domainkey — et une valeur TXT commençant par v=DKIM1; k=rsa; p=… . Publiez-la sous forme d'enregistrement TXT chez votre hébergeur DNS en utilisant exactement l'hôte fourni, puis revenez dans Titan, confirmez que vous l'avez ajoutée et cliquez sur Verify changes pour que le statut passe à VERIFIED. La clé est propre à votre compte, vous ne pouvez donc pas en copier une depuis un autre domaine ou depuis la documentation. Si le DNS de votre domaine est hébergé chez Cloudflare, laissez l'enregistrement TXT en DNS-only (le proxy ne s'applique pas aux TXT, mais assurez-vous d'éditer la zone faisant autorité que les serveurs de noms de Titan résolvent, et non une zone obsolète).

DMARC

Titan ne crée pas DMARC à votre place — vous l'ajoutez manuellement sous forme d'enregistrement TXT sur l'hôte _dmarc. Commencez par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com afin de surveiller sans risquer la délivrabilité, et pointez rua vers une boîte que vous consultez (ou un analyseur de rapports). DMARC réussit lorsque SPF ou DKIM réussit ET s'aligne avec votre domaine From, et Titan vous offre les deux : son chemin include:spf.titan.email utilise votre propre domaine comme expéditeur d'enveloppe (SPF s'aligne donc), et sa signature DKIM porte d=yourdomain.com (DKIM s'aligne donc) une fois la clé générée et vérifiée — vous verrez généralement les deux réussir. Parce que Titan envoie depuis votre domaine racine exact, l'alignement relâché par défaut réussit déjà proprement ; il n'est donc pas nécessaire de forcer l'alignement strict (adkim=s/aspf=s), qui ne fait qu'ajouter de la fragilité si vous envoyez plus tard depuis un sous-domaine ou un autre outil. Après une semaine ou deux de rapports agrégés propres, faites passer la politique à p=quarantine, puis p=reject pour bloquer activement quiconque usurpe votre domaine. Conservez exactement un seul enregistrement _dmarc pour l'ensemble du domaine, quel que soit le nombre d'expéditeurs que vous utilisez.

Vérifiez que tout fonctionne réellement

Vérifiez le DNS depuis la ligne de commande : dig TXT yourdomain.com (SPF), dig TXT titan1._domainkey.yourdomain.com (DKIM) et dig TXT _dmarc.yourdomain.com (DMARC) — les utilisateurs Windows peuvent utiliser nslookup -type=TXT. Confirmez les MX avec dig MX yourdomain.com ou mxtoolbox.com. Dans Titan, le panneau Email Reputation doit afficher DKIM comme VERIFIED et la Domain Verification comme terminée. Le test décisif : envoyez un message depuis votre boîte Titan vers un compte Gmail, ouvrez « Afficher l'original » et confirmez SPF: PASS, DKIM: PASS et DMARC: PASS avec votre domaine indiqué. Pour un rapport unique consolidé couvrant les trois enregistrements plus l'alignement, passez votre domaine dans le vérificateur SPF/DKIM/DMARC et le contrôle de santé de domaine de Qualisend.

Pièges courants

  • Casse l'authentification

    DKIM doit d'abord être généré dans Titan — vous ne pouvez ni deviner ni réutiliser une clé. La valeur est propre à chaque compte, et Titan ne signera pas votre courrier tant que vous n'aurez pas cliqué sur « Verify changes » après l'avoir publiée, même si l'enregistrement DNS est déjà actif.

  • Casse l'authentification

    Ne publiez jamais deux enregistrements SPF. Si vous avez déjà une ligne v=spf1 pour un autre service, ajoutez include:spf.titan.email dans cet unique enregistrement — un second enregistrement SPF TXT fait échouer SPF avec un permerror.

  • Casse l'authentification

    L'include de Titan consomme déjà ~4 de vos 10 requêtes SPF (spf.titan.email imbrique _spf1/_spf2/_spf3 plus des plages ip4 en ligne). Si vous envoyez aussi via d'autres outils, surveillez la limite des 10 requêtes, sinon SPF atteindra un permerror.

  • Couverture

    Ne passez pas ~all à -all prématurément. La valeur par défaut de Titan est ~all (softfail) ; ne durcissez à -all que lorsque vous êtes certain que chaque expéditeur légitime — Titan et tous les autres — est inclus, sinon vous rejetterez votre propre courrier.

  • Configuration DNS

    Double ajout du champ hôte : la plupart des bureaux d'enregistrement ajoutent votre domaine automatiquement, alors saisissez l'hôte DKIM comme titan1._domainkey, et non titan1._domainkey.yourdomain.com. Un domaine en double casse l'enregistrement de façon silencieuse.

  • Couverture

    Votre Control Panel peut être en marque blanche chez votre hébergeur (Hostinger, Bluehost, hosting.com, A2, Crazy Domains). Le menu peut porter une marque différente, mais le déroulé — connexion Manage/Admin → Email Reputation → DKIM → Verify changes — est le même.

  • Casse l'authentification

    MX n'est pas de l'authentification. Ajouter mx1/mx2.titan.email vous permet de recevoir du courrier mais ne fait rien pour SPF/DKIM/DMARC — vous avez toujours besoin des trois enregistrements pour que le courrier sortant réussisse chez Gmail et Yahoo.

  • Couverture

    Éditez la zone faisant autorité. Si votre domaine utilise des serveurs de noms externes (par ex. Cloudflare) plutôt que le DNS par défaut de votre bureau d'enregistrement, ajoutez les enregistrements là où les serveurs de noms résolvent réellement, sinon la vérification de Titan continuera d'échouer.

Construisez votre enregistrement SPF

Titan est présélectionné ci-dessous. Ajoutez toutes les autres plateformes par lesquelles vous envoyez, puis publiez l'enregistrement fusionné unique.

1

Sending sources

Search for each platform you send email through and tick it.

Selected
Guide →
2

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

3

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.

4

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

Your SPF record1/10 DNS lookups
v=spf1 include:spf.titan.email ~all
  • 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 list

SPF Titan — 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.

Commencer la vérification