Dois-je ajouter include:spf.migadu.com à mon enregistrement SPF ?

Oui. Contrairement aux ESP uniquement en CNAME, Migadu est un véritable fournisseur include et envoie avec votre propre domaine dans l'expéditeur d'enveloppe, si bien que cet include à la fois autorise les adresses IP d'envoi de Migadu et permet à SPF de s'aligner pour DMARC. L'enregistrement complet est v=spf1 include:spf.migadu.com -all. Si vous avez déjà un enregistrement SPF, fusionnez-y l'include plutôt que d'en ajouter un second.

Pourquoi le CNAME DKIM pointe-t-il vers une cible qui contient mon propre domaine ?

C'est ainsi que Migadu délègue DKIM par domaine. Votre enregistrement key1._domainkey.yourdomain.com est un CNAME vers key1.yourdomain.com._domainkey.migadu.com, un nom au sein de la zone de Migadu où la clé publique réelle est publiée. Cela permet à Migadu de détenir la clé privée et de la faire tourner sans que vous ayez jamais à modifier le DNS. La cible est correcte exactement telle qu'elle est indiquée.

Pourquoi y a-t-il trois enregistrements DKIM (key1, key2, key3) ?

Plusieurs sélecteurs permettent à Migadu de faire tourner les clés de signature sans aucune interruption — il peut retirer un sélecteur et basculer vers un autre tandis que les deux restent valides. Ajoutez les trois CNAME ; Migadu décide quelle clé signe activement votre courrier.

Combien de mes 10 requêtes SPF Migadu utilise-t-il ?

Quatre. include:spf.migadu.com n'est pas un enregistrement plat — il imbrique include:smtp.migadu.com, include:rel.migadu.com et include:mx.migadu.com, si bien qu'il coûte une requête pour l'include de premier niveau plus trois pour les includes imbriqués. C'est plus lourd que Google Workspace ou Microsoft 365 (une chacun), alors surveillez la limite des 10 requêtes si vous combinez des expéditeurs.

Ai-je encore besoin de DKIM si le SPF de Migadu s'aligne déjà ?

Oui — configurez les deux. L'alignement SPF se rompt dès qu'un message est transféré via une liste de diffusion ou une règle .forward, et à ce moment-là le DKIM aligné est la seule chose qui porte votre réussite DMARC. Les trois CNAME DKIM de Migadu signent avec d=yourdomain.com, ce qui maintient DMARC en réussite dans le monde réel.

Devrais-je utiliser v=spf1 mx -all à la place de l'include ?

Non — préférez include:spf.migadu.com. Certains tutoriels Migadu plus anciens suggèrent v=spf1 mx -all, qui n'autorise que les adresses IP vers lesquelles vos MX (aspmx1/aspmx2.migadu.com) se résolvent. Celles-ci recoupent une partie de l'infrastructure d'envoi de Migadu mais pas la totalité — Migadu envoie aussi depuis les plages smtp.migadu.com et rel.migadu.com que le mécanisme mx ne couvre jamais. include:spf.migadu.com intègre les trois sources d'envoi (smtp, rel, mx), ce qui correspond exactement à ce que Migadu publie sur son propre domaine, c'est donc le choix complet et pérenne.

Mon courrier ne s'envoie ni ne se reçoit — qu'ai-je manqué ?

Presque toujours la vérification du domaine. Confirmez que le TXT hosted-email-verify se résout sur votre racine, que les deux enregistrements MX (aspmx1 et aspmx2.migadu.com) pointent vers Migadu avec le MX de l'ancien hébergeur supprimé, et que le panneau d'administration affiche le domaine actif. Migadu n'active un domaine qu'après la réussite de ces vérifications, ce qui peut prendre jusqu'à 24 à 48 heures pour se propager.

Guide de configuration SPF

SPF, DKIM et DMARC pour Migadu.

Q: Migadu crée-t-il mon enregistrement DMARC ?

Non — vous publiez _dmarc vous-même, en commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com dans votre propre zone DNS. Migadu suggère un enregistrement DMARC dans le panneau d'administration mais ne l'écrit jamais à votre place, et il n'est pas requis pour que le domaine s'active — seuls le TXT de propriété et les MX le sont. Ajoutez-le comme un seul enregistrement TXT à _dmarc.yourdomain.com, maintenez-le à p=none jusqu'à ce que vos rapports agrégés confirment que Migadu réussit SPF et DKIM alignés, puis renforcez vers p=quarantine et finalement p=reject.

Migadu est un hébergeur de boîtes mail complet — il envoie et reçoit le courrier de votre domaine via IMAP/POP/SMTP — et non un ESP transactionnel, si bien qu'« authentifier votre domaine » signifie ici publier les enregistrements DNS que Migadu affiche lorsque vous ajoutez un domaine dans son panneau d'administration. Cet ensemble correspond à de vrais enregistrements DNS chez votre propre registraire : un enregistrement TXT de vérification de propriété, deux enregistrements MX (aspmx1/aspmx2.migadu.com) pour que Migadu puisse recevoir votre courrier, un véritable include SPF partagé (include:spf.migadu.com), trois sélecteurs DKIM délégués par CNAME (key1/key2/key3._domainkey) qui permettent à Migadu de faire tourner les clés de signature à votre place, et une politique DMARC que vous publiez vous-même. Comme Migadu place votre propre domaine dans l'expéditeur d'enveloppe, SPF s'aligne réellement — de sorte qu'un domaine Migadu correctement configuré réussit DMARC à la fois sur SPF et sur DKIM, la configuration résiliente qui survit au transfert.

Include SPF

Your DNSAdd the CNAME / TXT records

MigaduSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Pourquoi authentifier Migadu ?

Authentifier un domaine Migadu détermine si votre courrier atteint la boîte de réception, et conditionne aussi le fait que Migadu accepte ou non d'envoyer et de recevoir pour le domaine. Depuis février 2024, Gmail et Yahoo exigent de tout expéditeur en masse (environ 5 000 messages par jour ou plus) qu'il réussisse SPF, DKIM et DMARC avec alignement, et Microsoft a commencé à appliquer les mêmes règles au courrier à fort volume vers Outlook.com/Hotmail/Live en 2025. Migadu envoie via une infrastructure d'adresses IP partagées, de sorte que la réputation d'expéditeur que vous construisez dépend du fait que votre courrier soit proprement attribuable à votre propre domaine. Migadu se comporte ici de manière inhabituellement exemplaire : il utilise votre domaine comme SMTP MAIL FROM (enveloppe/Return-Path), si bien que SPF s'aligne sur votre domaine organisationnel et contribue à lui seul à une réussite DMARC — chose que des ESP qui possèdent le Return-Path, comme Mailchimp, ne peuvent pas faire. Mais l'alignement SPF se rompt dès qu'un message est transféré via une liste de diffusion ou une règle .forward, et c'est donc le DKIM délégué par CNAME qui maintient DMARC en réussite dans le monde réel. Faites l'impasse dessus et un message transféré ne dispose plus d'aucune authentification alignée. Et tant que les enregistrements TXT de propriété et MX ne se résolvent pas, Migadu n'active pas le domaine, et le courrier ne circule tout simplement pas.

La réalité SPF pour Migadu

Migadu est un véritable fournisseur « include » : vous ajoutez un seul mécanisme partagé, include:spf.migadu.com, à l'unique enregistrement SPF TXT de votre domaine racine, ce qui donne v=spf1 include:spf.migadu.com -all — exactement ce que Migadu publie sur son propre domaine. Il s'agit d'un véritable include partagé qu'utilise chaque client Migadu, et non d'une délégation par CNAME. Il pèse réellement dans DMARC parce que Migadu envoie avec votre propre domaine dans l'expéditeur d'enveloppe / Return-Path — vous possédez le domaine, Migadu en traite les rebonds — si bien que SPF s'aligne sur votre domaine organisationnel plutôt que de se résoudre par rapport à un domaine de rebond appartenant au fournisseur. Migadu recommande le qualificateur -all (échec strict), et son propre domaine publie -all. Le vrai piège propre à Migadu, c'est le coût : include:spf.migadu.com N'EST PAS un include économique à une seule requête comme le _spf.google.com de Google ou le spf.protection.outlook.com de Microsoft. Il imbrique trois sous-includes — include:smtp.migadu.com (les serveurs de soumission), include:rel.migadu.com (les relais sortants) et include:mx.migadu.com (les serveurs de messagerie) — de sorte qu'il consomme QUATRE de vos 10 requêtes DNS SPF au sens du RFC 7208, et non une seule. Si vous empilez en plus Google Workspace, Microsoft 365 ou un outil d'infolettre dans le même enregistrement SPF, ce budget s'épuise vite et peut vous faire basculer en PermError. Conservez exactement un seul enregistrement SPF TXT sur le domaine et fusionnez-y le mécanisme de chaque expéditeur — ne publiez jamais un second enregistrement v=spf1, ce qui constitue en soi un PermError.

Étape par étape

Dans Migadu

1
Ajoutez votre domaine dans le panneau d'administration
Connectez-vous sur admin.migadu.com et ouvrez Domains, puis ajoutez yourdomain.com. Migadu génère les enregistrements DNS exacts pour ce domaine — le TXT de propriété, les MX, le SPF, les trois CNAME DKIM et le DMARC suggéré — et les affiche sur la page du domaine. Laissez cet onglet ouvert ; vous allez y copier des valeurs.

Dans votre DNS

2
Ajoutez le TXT de vérification de propriété
Chez votre hébergeur DNS, ajoutez un enregistrement TXT sur la racine (hôte @ ou vide) avec la valeur affichée par Migadu, sous la forme hosted-email-verify=xxxxxxxxxxxx. Migadu l'utilise pour confirmer que vous contrôlez le domaine avant d'activer le courrier. Laissez-le en place — Migadu le revérifie en continu, donc ne le supprimez pas une fois le domaine vérifié.
3
Pointez les MX vers Migadu
Ajoutez deux enregistrements MX sur la racine : aspmx1.migadu.com en priorité 10 et aspmx2.migadu.com en priorité 20. Supprimez tout enregistrement MX d'un hébergeur précédent afin que le courrier entrant soit routé uniquement vers Migadu. Les MX concernent la réception, pas l'authentification, mais un MX à moitié migré est la raison la plus fréquente pour laquelle le courrier Migadu ne fonctionne pas.
4
Publiez ou fusionnez l'enregistrement SPF
Ajoutez un enregistrement TXT sur la racine avec v=spf1 include:spf.migadu.com -all. Si un enregistrement v=spf1 existe déjà (Google Workspace, un outil d'infolettre, etc.), fusionnez include:spf.migadu.com dans cet unique enregistrement — n'ajoutez jamais un second SPF TXT. Rappelez-vous que cet include coûte quatre requêtes DNS, donc gardez à l'esprit la limite des 10 requêtes si vous empilez des expéditeurs.
5
Ajoutez les trois CNAME DKIM
Créez trois enregistrements CNAME : hôte key1._domainkey pointant vers key1.yourdomain.com._domainkey.migadu.com, key2._domainkey vers key2.yourdomain.com._domainkey.migadu.com, et key3._domainkey vers key3.yourdomain.com._domainkey.migadu.com. La cible intégrant votre propre domaine est correcte, ce n'est pas une faute de frappe. Conservez le type CNAME — ne passez pas en TXT et ne collez pas de clé.
6
Publiez l'enregistrement DMARC
Migadu ne crée pas le DMARC à votre place. Ajoutez un enregistrement TXT à l'hôte _dmarc avec v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est un mode surveillance seule, donc rien ne change à la distribution pendant que vous confirmez que SPF et DKIM s'alignent tous deux. Conservez exactement un seul enregistrement _dmarc par domaine.
7
(Facultatif) Ajoutez les enregistrements d'autoconfiguration des clients
Pour permettre à Thunderbird, Apple Mail et Outlook de détecter automatiquement les réglages, ajoutez un CNAME autoconfig pointant vers autoconfig.migadu.com ainsi que les enregistrements SRV listés par Migadu — _submissions._tcp (port 465, smtp.migadu.com), _imaps._tcp (993, imap.migadu.com) et _pop3s._tcp (995, pop.migadu.com). Ce sont des enregistrements de confort pour les clients de messagerie, pas de l'authentification — ignorez-les si vous configurez les clients à la main.

Dans Migadu

8
Attendez l'activation du domaine
Migadu revérifie votre DNS selon une planification ; le domaine passe généralement en vérifié/actif en 30 minutes environ, même si la propagation DNS complète peut prendre jusqu'à 24 à 48 heures. Vous ne pouvez ni envoyer ni recevoir tant que le panneau n'affiche pas le domaine actif avec le TXT de propriété et les MX détectés.

Vérifier

9
Envoyez un test et lisez les en-têtes
Depuis une boîte mail du domaine, envoyez-vous un e-mail sur Gmail, ouvrez le message et choisissez ⋮ → Afficher l'original. Confirmez SPF: PASS affichant votre domaine, DKIM: PASS avec d=yourdomain.com (sélecteur key1, key2 ou key3) et DMARC: PASS. Passez ensuite le domaine dans un contrôle de santé pour confirmer que chaque enregistrement se résout.

Enregistrements à ajouter

Migadu 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
TXT	@	hosted-email-verify=xxxxxxxxxxxxxxxxVérification de propriété du domaine — à titre indicatif ; copiez la chaîne exacte depuis admin.migadu.com. Laissez-la en place ; Migadu la revérifie en continu.
MX	@	aspmx1.migadu.comCourrier entrant, priorité 10. Requis pour recevoir — supprimez le MX de tout ancien hébergeur.
MX	@	aspmx2.migadu.comCourrier entrant, priorité 20 (serveur de messagerie de secours).
TXT	@	v=spf1 include:spf.migadu.com -allSPF racine — conservez exactement un seul enregistrement SPF ; fusionnez les autres expéditeurs dans cette ligne. Cet include coûte 4 requêtes DNS (il imbrique smtp/rel/mx).
CNAME	key1._domainkey	key1.yourdomain.com._domainkey.migadu.comSélecteur DKIM 1 — délégué par CNAME ; Migadu détient et fait tourner la clé. La cible contient votre propre domaine, à dessein.
CNAME	key2._domainkey	key2.yourdomain.com._domainkey.migadu.comSélecteur DKIM 2 — à associer à key1 ; permet à Migadu de faire tourner les clés sans interruption.
CNAME	key3._domainkey	key3.yourdomain.com._domainkey.migadu.comSélecteur DKIM 3 — ajoutez les trois exactement tels qu'ils sont indiqués.
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVous l'ajoutez vous-même — Migadu ne le crée jamais. Un seul par domaine ; commencez à p=none, puis renforcez.

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

SPF 10-lookup budget4 used · 6 free

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

DKIM

Migadu gère DKIM par délégation CNAME, il n'y a donc aucune clé à générer ou à coller. Migadu publie trois sélecteurs pour votre domaine — key1, key2 et key3 — et vous ajoutez trois enregistrements CNAME : key1._domainkey.yourdomain.com pointant vers key1.yourdomain.com._domainkey.migadu.com, et le même schéma pour key2 et key3. Le nom d'hôte cible qui intègre votre propre domaine (keyN.yourdomain.com._domainkey.migadu.com) paraît étrange mais est parfaitement correct : ce nom réside dans la zone de Migadu et se résout en un enregistrement TXT contenant la clé publique réelle (v=DKIM1; k=rsa; p=…). Comme il s'agit de CNAME plutôt que d'enregistrements TXT que vous copiez, Migadu détient les clés privées et peut faire tourner les clés publiques publiées derrière les trois sélecteurs sans que vous ayez jamais à modifier à nouveau le DNS — ce qui explique la présence de trois sélecteurs : Migadu peut en retirer un et basculer vers un autre sans aucune interruption. Migadu signe votre courrier sortant avec d=yourdomain.com, de sorte que DKIM s'aligne sur votre domaine From et porte une réussite DMARC même lorsque SPF se rompt lors d'un transfert. Ajoutez les trois CNAME exactement tels qu'ils sont indiqués ; si votre DNS est derrière Cloudflare, réglez chacun sur DNS only (nuage gris), car un CNAME proxifié en nuage orange ne se résoudra pas vers migadu.com et DKIM échouera.

DMARC

DMARC est un enregistrement de politique distinct que vous publiez vous-même — Migadu en suggère un mais ne le crée pas dans votre zone, et il n'est pas requis pour que le domaine s'active (seuls le TXT de propriété et les MX le sont). Ajoutez un enregistrement TXT à _dmarc.yourdomain.com commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est un mode surveillance seule : il ne change rien à la distribution mais indique aux destinataires de vous envoyer par e-mail des rapports agrégés (rua) afin que vous puissiez confirmer que le courrier Migadu réussit SPF et DKIM alignés sur votre domaine. Migadu fait partie des fournisseurs où cette montée en puissance se fait proprement et rapidement — parce qu'il aligne SPF (votre propre domaine d'enveloppe) et DKIM (les sélecteurs keyN de votre domaine), vous obtenez des réussites doublement alignées, la configuration qui continue de réussir même lorsqu'un message est transféré. Surveillez les rapports pendant une semaine ou deux, assurez-vous que chaque expéditeur légitime s'authentifie, puis renforcez vers p=quarantine et finalement p=reject. Conservez exactement un seul enregistrement _dmarc pour l'ensemble du domaine organisationnel, quel que soit le nombre d'expéditeurs que vous utilisez ; les sous-domaines héritent de la politique parente sauf si vous la remplacez. À titre de référence, le propre domaine de Migadu applique p=quarantine — une cible d'application raisonnable une fois l'alignement confirmé.

Vérifiez que tout fonctionne réellement

Ne vous fiez pas au seul badge de statut du panneau d'administration — confirmez-le sur un vrai message. Envoyez-vous un test depuis une boîte mail du domaine, ouvrez-le dans Gmail et choisissez ⋮ → Afficher l'original : vous voulez SPF: PASS affichant yourdomain.com, DKIM: PASS avec d=yourdomain.com et un sélecteur key1/key2/key3 (et non une signature migadu.com), et DMARC: PASS. Vous pouvez vérifier ponctuellement les enregistrements bruts depuis un terminal avec dig TXT yourdomain.com (SPF), dig CNAME key1._domainkey.yourdomain.com (devrait se résoudre vers key1.yourdomain.com._domainkey.migadu.com puis vers une clé DKIM1) et dig TXT _dmarc.yourdomain.com. Dans le panneau d'administration Migadu, le domaine devrait apparaître comme vérifié/actif avec MX et SPF détectés. Enfin, passez le domaine dans le {healthCheck} de Qualisend pour confirmer que le SPF, les trois sélecteurs DKIM, les MX et le DMARC se résolvent proprement et que le SPF reste sous la limite des 10 requêtes — et une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'{dmarcAnalyzer} pour confirmer que Migadu apparaît bien comme une source alignée et en réussite.

Vérification de l'état du domaine Analyseur de rapports DMARC

Pièges courants

Casse l'authentification
Le SPF de Migadu est lourd : include:spf.migadu.com coûte QUATRE requêtes DNS car il imbrique smtp.migadu.com, rel.migadu.com et mx.migadu.com — et non une seule requête comme Google ou Microsoft. Empiler d'autres expéditeurs dans le même enregistrement peut faire dépasser la limite des 10 requêtes du RFC 7208 et provoquer un PermError, alors budgétez avec soin.
Configuration DNS
Migadu n'enverra ni ne recevra pour le domaine tant que le TXT de propriété (hosted-email-verify=…) ne se résout pas et que le domaine n'apparaît pas actif dans le panneau. Ne supprimez pas ce TXT après la configuration — Migadu le revérifie en continu, et le retirer peut désactiver le domaine.
Couverture
Les deux enregistrements MX sont requis et doivent être ceux de Migadu : aspmx1.migadu.com (priorité 10) et aspmx2.migadu.com (priorité 20). Laisser le MX d'un ancien hébergeur en place scinde votre courrier entrant et constitue la cause la plus fréquente du « mon e-mail Migadu ne fonctionne pas ».
Configuration DNS
La cible du CNAME DKIM contient légitimement votre propre domaine — key1.yourdomain.com._domainkey.migadu.com est correct, ce n'est ni une faute de frappe ni un hôte dédoublé. Conservez le type d'enregistrement CNAME ; ne le convertissez jamais en TXT et ne collez pas de clé publique DKIM.
Configuration DNS
Le proxy Cloudflare casse le DKIM en CNAME : réglez key1/key2/key3._domainkey sur DNS only (nuage gris). Un CNAME proxifié en nuage orange ne se résoudra pas vers migadu.com et la validation DKIM échoue.
Configuration DNS
Dédoublement du champ hôte : les registraires qui ajoutent automatiquement votre domaine transforment key1._domainkey en key1._domainkey.yourdomain.com.yourdomain.com. Saisissez uniquement le libellé (key1._domainkey) lorsque le panneau ajoute le domaine à votre place.
Casse l'authentification
Conservez exactement un seul enregistrement SPF TXT sur la racine. Si vous envoyez aussi via Google Workspace, Microsoft 365 ou un outil marketing, fusionnez include:spf.migadu.com dans cette unique ligne v=spf1 — deux enregistrements SPF constituent en soi un PermError.
Couverture
Utilisez ~all pendant la migration et ne passez à -all qu'une fois chaque expéditeur légitime répertorié. Migadu recommande -all (échec strict) et l'emploie sur son propre domaine, mais un -all prématuré rejette de manière stricte toute source de courrier que vous auriez oublié d'ajouter.

Construisez votre enregistrement SPF

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

Sending sources

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

Selected

Migaduinclude:spf.migadu.comGuide →

This domain's own servers

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

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

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

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record1/10 DNS lookups

v=spf1 include:spf.migadu.com ~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 Migadu — FAQ

Lectures complémentaires

SPF, DKIM et DMARC expliquésComment les trois enregistrements fonctionnent ensemble — la fondation sur laquelle un domaine Migadu s'appuie pour une authentification doublement alignée.Comment configurer DMARCLe seul enregistrement que Migadu ne crée jamais pour vous : publiez _dmarc, lisez les rapports et montez en puissance de p=none à p=reject.Exigences des expéditeurs Google et YahooPourquoi l'alignement SPF, DKIM et DMARC est désormais obligatoire pour atteindre les boîtes de réception Gmail, Yahoo et Outlook.Contrôle de santé du domaineConfirmez que votre SPF Migadu, les trois sélecteurs DKIM, les MX et le DMARC se résolvent proprement et restent sous la limite des 10 requêtes.Générateur d'enregistrement SPFFusionnez l'include lourd à quatre requêtes de Migadu avec d'autres expéditeurs en un seul enregistrement SPF valide, sans PermError.Analyseur de rapports DMARCDéposez vos rapports agrégés pour confirmer que Migadu apparaît comme une source alignée et en réussite avant de renforcer la politique.

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