Outlook.com/Hotmail : e‑mails non remis (depuis avril 2024) — diagnostic SPF, DKIM, DMARC et solutions

Depuis avril 2024, de nombreux utilisateurs Outlook.com/Hotmail voient leurs e‑mails figurer en « Éléments envoyés » mais ne jamais parvenir aux destinataires, ou seulement de façon aléatoire. Voici un guide concret pour diagnostiquer, limiter l’impact et résoudre le problème.

Sommaire

Problème posé

Des utilisateurs d’Outlook.com/Hotmail constatent que leurs e‑mails, bien qu’affichés dans Éléments envoyés et sans message de rebond, n’arrivent pas (ou arrivent de façon aléatoire) chez les destinataires, qu’il s’agisse d’adresses Microsoft ou d’autres services (Gmail, Yahoo, etc.). Le symptôme est trompeur : tout semble normal côté expéditeur, mais la remise est retardée, rejetée silencieusement ou filtrée en amont.

Pourquoi aucun NDR (rapport de non-remise) ?
Car la non‑remise peut se produire avant l’acceptation par le serveur destinataire (files d’attente saturées, temporisations prolongées) ou suite à des décisions de filtrage qui ne déclenchent pas de NDR.

Symptômes connexes typiques

Le même message, envoyé à plusieurs domaines, n’est reçu que par certains destinataires.
Les messages courts sans pièce jointe finissent par passer, alors que les messages riches (HTML lourd, liens de suivi) n’arrivent pas.
Les destinataires sur des domaines Microsoft (Outlook.com, Hotmail, Live, Office 365) sont touchés de façon prioritaire, ou au contraire seuls les domaines tiers sont concernés.
Aucun retour d’erreur, ni alerte de quota ; le suivi « Afficher le message envoyé » n’apporte pas d’indices supplémentaires.

Analyse des causes probables

Les facteurs les plus fréquents sont listés ci‑dessous. Plusieurs peuvent coexister.

Piste	Explication succincte	Indicateurs	Actions initiales
Incident côté serveurs Microsoft	Une panne ou une dégradation temporaire des files d’envoi peut retarder ou bloquer la remise.	Multiplication soudaine des signalements ; mêmes créneaux horaires ; impact transversal à plusieurs comptes.	Vérifier l’état du service et les canaux officiels de communication. Envoyer des tests vers plusieurs fournisseurs pour comparer.
Filtrage antispam / réputation	Rejet silencieux ou différé basé sur réputation IP/domaine, contenu, absence d’authentification SPF/DKIM/DMARC, ou incohérences DNS.	En‑têtes « Authentication‑Results » neutres/échec, variations selon le contenu et le volume d’envoi.	Mettre à jour SPF/DKIM/DMARC, alléger le contenu, limiter les lots de destinataires, surveiller la réputation.
Files d’attente saturées	Congestion temporaire : les messages restent en attente chez Microsoft sans générer de NDR.	Retards imprévisibles, livraison par vagues, disparition du symptôme lorsque la charge baisse.	Fractionner les envois, contourner temporairement avec un alias/SMTP alternatif pour les messages critiques.

Avant de commencer : sécuriser le contexte

Ne réexpédiez pas en boucle le même e‑mail : vous pourriez dégrader la réputation et empirer le filtrage.
Préparez un canal alternatif (SMS, Teams, WhatsApp) pour prévenir les contacts importants.
Conservez les originaux .eml et les captures d’écran : ils serviront lors d’une escalade.

Solutions et pistes d’action

Vérifier l’état du service

Tableau de bord d’intégrité Microsoft 365 (comptes professionnels/éducation) : ouvrez le Centre d’administration, rubrique « Intégrité du service », filtrez Exchange Online et Outlook.com. Relevez l’éventuel code d’incident (type EXxxxx) et l’heure de début.
Canaux d’alerte publics : consultez les messages officiels récents relatifs à Outlook/Exchange. Comparez l’heure de vos envois avec la plage d’incident indiquée.
Corrélez avec vos tests : si tous vos essais échouent uniquement pendant le créneau de l’incident, privilégiez l’hypothèse « panne côté service ».

Tester la délivrabilité de façon structurée

Créez une grille de tests pour comparer contenus, destinataires et chemins d’envoi.

<table>
  <thead>
    <tr>
      <th>Test</th>
      <th>Chemin</th>
      <th>Destinataire</th>
      <th>Contenu</th>
      <th>Résultat attendu</th>
      <th>Ce que cela prouve</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>A</td>
      <td>Outlook.com → Outlook.com</td>
      <td>Boîte 2 (perso)</td>
      <td>Texte brut, sans lien</td>
      <td>Livraison <em>rapide</em></td>
      <td>Si retard : congestion possible côté Microsoft.</td>
    </tr>
    <tr>
      <td>B</td>
      <td>Outlook.com → Gmail</td>
      <td>Boîte test</td>
      <td>HTML simple, 1 pièce jointe &lt;1 Mo</td>
      <td>Livraison <em>prévisible</em></td>
      <td>Si aléatoire : suspicion de réputation/filtrage.</td>
    </tr>
    <tr>
      <td>C</td>
      <td>Outlook.com → service de test</td>
      <td>Analyseur (score/headers)</td>
      <td>Copie du message réel</td>
      <td>Rapport lisible</td>
      <td>Met en évidence SPF/DKIM/DMARC et indices de contenu.</td>
    </tr>
    <tr>
      <td>D</td>
      <td>Client web &amp; mobile</td>
      <td>Boîte de confiance</td>
      <td>Identique</td>
      <td>Comportement identique</td>
      <td>Écarte un problème local de client/appareil.</td>
    </tr>
  </tbody>
</table>

<details>
  <summary><strong>Que regarder dans les en‑têtes&nbsp;?</strong></summary>
  <div>
    <ul>
      <li><strong>Authentication‑Results</strong> : états <code>spf=pass/neutral/fail</code>, <code>dkim=pass/fail</code>, <code>dmarc=pass/fail</code>.</li>
      <li><strong>Received‑SPF</strong> : détail du verdict SPF et de l’IP source vue par le destinataire.</li>
      <li><strong>DKIM‑Signature</strong> : présence et <em>selector</em> actif (ex. <code>selector1</code>/<code>selector2</code>).</li>
      <li><strong>ARC‑Authentication‑Results</strong> : utile si le message a transité par une liste de diffusion ou un transfert.</li>
      <li><strong>X‑Microsoft‑Antispam*</strong> (vers destinataire Microsoft) : indices de catégorisation.</li>
    </ul>
    <pre><code>Exemples d’indices courants

Authentication-Results: spf=neutral; dkim=none; dmarc=none → Authentification insuffisante, sujet à filtrage. Authentication-Results: spf=pass; dkim=pass; dmarc=pass → Authentification OK ; cherchez côté réputation/contenu/incident.

Mettre à jour l’authentification du domaine

Si vous envoyez avec une adresse de domaine personnalisé (compte Entreprise Microsoft 365 ou alias Outlook personnalisé), assurez‑vous que SPF, DKIM et DMARC sont en place et cohérents.

<div class="admonition">
  <p><strong>Rappels essentiels</strong></p>
  <ul>
    <li><strong>Un seul SPF valide</strong> par domaine (<code>TXT</code> à la racine). Les doublons invalident la politique.</li>
    <li><strong>Incluez tous les émetteurs</strong> légitimes (Microsoft, outil marketing, routeur transactionnel) dans la politique SPF ou via DKIM dédié.</li>
    <li><strong>DKIM</strong>&nbsp;: activez deux sélecteurs et publiez les deux <code>CNAME</code> fournis par l’admin center.</li>
    <li><strong>DMARC</strong>&nbsp;: commencez en <code>p=none</code> pour observer, puis montez progressivement vers <code>quarantine</code> ou <code>reject</code> après correction.</li>
  </ul>
</div>

<h4>Modèles de départ</h4>
<table>
  <thead>
    <tr>
      <th>Cas</th>
      <th>SPF (TXT)</th>
      <th>DMARC (TXT)</th>
      <th>DKIM</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Outlook.com (alias personnalisé)</td>
      <td><code>v=spf1 include:outlook.com -all</code></td>
      <td><code>v=DMARC1; p=none; pct=100; rua=mailto:postmaster@votredomaine</code></td>
      <td>Publiez <em>deux</em> CNAME générés dans les paramètres d’Outlook.com</td>
    </tr>
    <tr>
      <td>Microsoft&nbsp;365 (Exchange Online)</td>
      <td><code>v=spf1 include:spf.protection.outlook.com -all</code></td>
      <td><code>v=DMARC1; p=none; rua=mailto:postmaster@votredomaine</code></td>
      <td>Activez DKIM dans le Centre d’administration, publiez <code>selector1</code> et <code>selector2</code></td>
    </tr>
    <tr>
      <td>Microsoft&nbsp;365 + routeur tiers (ex. SendGrid)</td>
      <td><code>v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all</code></td>
      <td><code>v=DMARC1; p=none; rua=mailto:postmaster@votredomaine</code></td>
      <td>DKIM distinct pour chaque routeur ; évitez « tout via SPF »</td>
    </tr>
  </tbody>
</table>

<p><em>Astuce :</em> si votre SPF dépasse ~10 mécanismes DNS (limite de recursions), segmentez ou privilégiez DKIM chez les sous‑traitants afin d’éviter les <strong>permerror</strong>.</p>

<pre><code>Récapitulatif minimal viable

SPF : v=spf1 include:outlook.com -all DMARC : v=DMARC1; p=none; pct=100; rua=mailto:postmaster@votredomaine DKIM : deux CNAME générés dans le Centre d’administration

Réduire les facteurs de blocage

Contenu : allégez le HTML, retirez les pixels de suivi agressifs, limitez le nombre de liens, évitez les URL raccourcies.
Pièces jointes : favorisez des fichiers < 5 Mo, compressez si nécessaire, évitez archives protégées par mot de passe.
Cadence : envoyez par lots ≤ 30 destinataires pendant l’incident, espacez de 2–5 minutes, introduisez un « palier » si les taux de remise chutent.
Destinataires : purgez les adresses inactives et faites valider l’opt‑in pour les envois volumineux.
Expéditeur : stabilisez le « From: » (même domaine, même adresse) et évitez de changer trop souvent l’adresse d’envoi.

Solutions de contournement temporaires

Alias Outlook différent : envoyez les messages critiques depuis un alias secondaire.
Compte tiers : utilisez un SMTP professionnel (ex. routeur transactionnel) pour les communications indispensables, le temps de l’incident.
Canaux alternatifs : informez vos contacts via SMS, Teams, WhatsApp, avec un court message d’alerte et une promesse de renvoi quand la remise sera stabilisée.
Planification : programmez l’envoi différé d’e‑mails non urgents pour diluer la charge.

Escalader efficacement auprès de Microsoft

Préparez un dossier clair : plus les éléments sont précis, plus le diagnostic est rapide.

Pour Microsoft 365 : ouvrez un ticket depuis le Centre d’administration. Joignez :
- exemples représentatifs (3–5 messages),
- fichiers .eml complets,
- horodatage exact (UTC),
- adresses source et cible,
- résumé de vos tests (cf. matrice ci‑dessus).
Pour Outlook.com : utilisez le formulaire de commentaires/assistance intégré. Fournissez le Message‑ID, les captures d’écran et, si possible, les en‑têtes du destinataire lorsque le message finit par arriver.

Ce qui n’apporte généralement pas de résultat

Réinstaller Outlook / recréer un profil : le problème est côté serveur, la réinstallation n’affecte pas la file de remise.
Changer d’appareil ou de réseau : n’a pas d’impact si la congestion ou le filtrage se produit chez Microsoft.
Demander aux destinataires de « débloquer » : inutile si le message n’atteint jamais leur serveur.

Bonnes pratiques pour prévenir de futurs blocages

Activez l’authentification multifacteur (MFA) pour réduire les comportements suspects et le risque de limitation.
Surveillez la réputation d’expéditeur (ex. signaux de Microsoft SNDS, Google Postmaster Tools) et corrigez rapidement les dérives.
Mettez en place DMARC avec rapports (rua) pour recevoir des agrégats quotidiens et repérer les anomalies.
Segmentez vos envois : distinguez transactionnels (factures, 2FA) et marketing. Utilisez des domaines/sous‑domaines et signatures DKIM dédiés.
Échauffement d’expéditeur : après une période d’inactivité, reprenez progressivement le volume (5 → 20 → 50 → 100/jour).
Sauvegardez régulièrement vos e‑mails essentiels hors ligne (export PST ou EML), et documentez vos DNS (captures de SPF/DKIM/DMARC).

Procédure express en 10 minutes

Envoyez 3 messages de test : Outlook.com, Gmail, boîte pro.
Notez l’heure exacte et le contenu (texte ou HTML, PJ oui/non).
Si aucun n’arrive : probabilité élevée d’incident côté Microsoft.
Si certains arrivent : ouvrez les en‑têtes côté destinataire et repérez Authentication‑Results.
Vérifiez SPF/DKIM/DMARC sur votre domaine d’envoi.
Allégez le message (supprimez liens de suivi, test texte brut).
Fragmenter en lots ≤ 30 destinataires.
Envoyez depuis un alias Outlook ou via un SMTP pro pour les urgences.
Consolidez vos preuves (Message‑ID, en‑têtes, captures).
Escaladez avec un dossier complet si le problème persiste.

Tableaux de référence rapide

Interprétation des en‑têtes d’authentification

Observation	Hypothèse	Action recommandée
`spf=neutral` ou `none`	SPF absent ou non décisif	Publier/ajuster SPF ; vérifier le domaine MAIL FROM
`dkim=none`	Signature manquante	Activer DKIM sur deux sélecteurs
`dmarc=fail`	Alignement défaillant	Harmoniser From/Return‑Path/DKIM et la politique DMARC
Taux de remise variable selon contenu	Filtrage basé sur contenu/liens	Alléger HTML, retirer suivi, tester texte brut
Retards longs puis livraison par lot	Files d’attente saturées	Fractionner et planifier ; contournement temporaire

Check‑list DNS (SPF/DKIM/DMARC)

Un seul enregistrement SPF TXT à la racine (pas de doublons).
SPF inclut tous les services émetteurs (Microsoft, outils tiers).
DKIM activé : selector1 et selector2 publiés.
DMARC publié, rua configuré vers une boîte surveillée.
Aucune « permerror » SPF (éviter >10 lookups).

Modèles prêts à l’emploi

Message d’information à vos contacts

Objet : Problème de remise de nos e‑mails (information)

Bonjour,

Nous rencontrons un problème de remise depuis Outlook.com/Hotmail : certains messages
peuvent ne pas vous parvenir ou arriver en retard. En cas d’urgence, merci d’utiliser
ce canal alternatif (téléphone/SMS/Teams/WhatsApp).

Dès rétablissement, nous renverrons les e‑mails importants.
Merci pour votre compréhension.

Liste de contrôle d’escalade

• Comptes affectés&nbsp;:
* Heure de début (UTC)&nbsp;:
* Types de destinataires impactés&nbsp;: Microsoft / Gmail / autres
* Exemples fournis&nbsp;: 3–5 fichiers .eml + captures « Éléments envoyés »
* Résultats d’authentification&nbsp;: SPF / DKIM / DMARC
* Matrice de tests exécutés (A/B/C/D) + résultats
* Message‑ID et horodatage exact pour chaque envoi
* Description des contournements tentés

FAQ

Pourquoi mon e‑mail est‑il visible en « Éléments envoyés » s’il n’est pas livré ?

« Éléments envoyés » confirme que votre client a remis le message au service d’envoi d’Outlook. Cela ne garantit pas la remise finale au serveur du destinataire, qui peut différer ou échouer sans NDR en cas de congestion ou de filtrage amont.Modifier d’appareil (PC → mobile) change‑t‑il quelque chose ?

Non, si l’incident se situe côté serveur Microsoft. Le changement d’appareil n’influence pas les files d’attente ou la réputation.Dois‑je passer immédiatement DMARC en « reject » ?

Non. Commencez par p=none pour collecter les rapports, corrigez les incohérences, puis montez vers quarantine et enfin reject une fois les flux propres.Les messages texte brut sont‑ils mieux livrés ?

Souvent oui pendant un incident : contenu léger, peu de liens et pas de suivi sont moins susceptibles d’être retenus par certains filtres.Comment savoir si le destinataire a lu mon e‑mail ?

Les accusés de lecture/MDN ne sont ni fiables ni universels. Pour les messages critiques, utilisez un canal alternatif ; pour les campagnes, un routeur disposant de métriques après résolution de l’incident.

Étude de cas synthétique

Contexte : une PME envoie 120 e‑mails d’invitation depuis un alias Outlook.com. Les destinataires Office 365 reçoivent à 20 %, Gmail à 60 %, les autres à 0 %. Aucun NDR.

Actions : passage en texte brut, suppression des pixels de suivi, lots de 25, activation DKIM et correction SPF (ajout d’un routeur légitime oublié). Contournement temporaire pour les VIP via SMTP pro.

Résultat : livraison > 95 % en 48 h, le reliquat correspondant au créneau d’un incident identifié côté service.

Conclusion

Les problèmes de remise Outlook.com/Hotmail apparus depuis avril 2024 proviennent le plus souvent d’un mélange d’incidents temporaires et de signaux d’authentification/réputation insuffisants. En appliquant une démarche structurée — état du service, tests comparatifs, durcissement SPF/DKIM/DMARC, allègement de contenu, fractionnement des envois et escalade outillée — vous maximisez vos chances de remise, tout en réduisant l’impact pour vos correspondants. Conservez vos preuves et professionnalisez vos flux d’e‑mail : vous serez mieux armé si le problème réapparaît.

Annexes

Gabarit de politique DMARC progressive

; Phase 1 : observation
_dmarc.votredomaine  IN TXT  "v=DMARC1; p=none; pct=100; rua=mailto:postmaster@votredomaine"

; Phase 2 : quarantaine partielle
_dmarc.votredomaine  IN TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:postmaster@votredomaine; ruf=mailto:abuse@votredomaine"

; Phase 3 : rejet progressif
_dmarc.votredomaine  IN TXT  "v=DMARC1; p=reject; pct=50; rua=mailto:postmaster@votredomaine"

; Phase 4 : rejet total une fois stable
_dmarc.votredomaine  IN TXT  "v=DMARC1; p=reject; pct=100; rua=mailto:postmaster@votredomaine"

Modèle d’enregistrement SPF multi‑émetteurs (exemple)

v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:_spf.mailjet.com ~all
; Remarques&nbsp;:
; • Préférez ~all au début si vous testez l’impact (softfail), puis passez en -all quand tout est validé.
; • Évitez de dépasser 10 « lookups ». Supprimez les includes inutilisés.

Checklist « hygiène de contenu »

Liens directs, non raccourcis, vers des domaines de bonne réputation.
Moins de 8 liens par message, pas de répétition excessive.
Police/HTML sobrires, pas d’images géantes ni d’animations lourdes.
Texte alternatif pertinent pour les images (ALT).
En‑tête et pied cohérents (adresse postale, identité claire).

Outlook.com/Hotmail : e‑mails non remis (depuis avril 2024) — diagnostic SPF, DKIM, DMARC et solutions