{"id":12305,"date":"2026-08-31T11:35:13","date_gmt":"2026-08-31T09:35:13","guid":{"rendered":"https:\/\/gvision.be\/?p=12305"},"modified":"2026-08-31T11:35:14","modified_gmt":"2026-08-31T09:35:14","slug":"spf-dkim-dmarc-belgique","status":"publish","type":"post","link":"https:\/\/gvision.be\/nl\/spf-dkim-dmarc-belgique\/","title":{"rendered":"SPF, DKIM et DMARC en Belgique : s\u00e9curiser son domaine e-mail sans bloquer les messages l\u00e9gitimes"},"content":{"rendered":"<style>.gv-blog-article{--gv-navy:#07192d;--gv-blue:#0d6efd;--gv-cyan:#15c7dc;--gv-coral:#ff765f;--gv-ink:#17263a;--gv-muted:#5a6a7d;--gv-line:#dce6ef;--gv-soft:#f3f8fc;--gv-white:#ffffff;--gv-shadow:0 18px 48px rgba(7,25,45,0.12);max-width:960px;margin-inline:auto;color:var(--gv-ink);font-family:Inter,system-ui,-apple-system,BlinkMacSystemFont,\"Segoe UI\",sans-serif;font-size:clamp(1rem,0.97rem + 0.12vw,1.08rem);line-height:1.72;overflow-wrap:anywhere}.gv-blog-article *,.gv-blog-article *::before,.gv-blog-article *::after{box-sizing:border-box}.gv-blog-article:where(h1,h2,h3){color:var(--gv-navy);line-height:1.16;letter-spacing:-0.025em;text-wrap:balance}.gv-blog-article h1{max-width:18ch;margin:0.2em 0 0.38em;font-size:clamp(2.25rem,5.6vw,4.6rem)}.gv-blog-article h2{margin:2.15em 0 0.65em;font-size:clamp(1.65rem,3.2vw,2.45rem)}.gv-blog-article h3{margin:1.65em 0 0.45em;font-size:clamp(1.18rem,2vw,1.4rem)}.gv-blog-article:where(p,ul,ol){margin-block:0.85em}.gv-blog-article li{margin-block:0.38em;padding-inline-start:0.18em}.gv-blog-article a{color:#075fc7;font-weight:650;text-decoration-thickness:0.08em;text-underline-offset:0.16em}.gv-blog-article a:hover,.gv-blog-article a:focus-visible{color:#064b9c;text-decoration-thickness:0.13em}.gv-blog-article a:focus-visible,.gv-blog-article summary:focus-visible,.gv-blog-article [tabindex=\"0\"]:focus-visible{outline:3px solid rgba(21,199,220,0.55);outline-offset:4px}.gv-blog-header{position:relative;padding-top:clamp(1rem,3vw,2.25rem)}.gv-blog-kicker{margin-bottom:0.75rem;color:#087f95;font-size:0.78rem;font-weight:850;letter-spacing:0.1em;text-transform:uppercase}.gv-blog-intro,.gv-blog-lead{max-width:760px;color:#3d4f64;font-size:clamp(1.12rem,1.02rem + 0.45vw,1.34rem);line-height:1.58}.gv-blog-section{scroll-margin-top:7rem}.gv-blog-figure{margin:clamp(1.8rem,4vw,3.1rem) 0}.gv-blog-figure img{display:block;width:100%;height:auto;border-radius:20px;box-shadow:var(--gv-shadow)}.gv-blog-hero img{aspect-ratio:16 \/ 9;object-fit:cover}.gv-blog-infographic img{border:1px solid var(--gv-line);background:var(--gv-white);box-shadow:0 10px 34px rgba(7,25,45,0.08)}.gv-blog-figure figcaption{margin-top:0.72rem;color:var(--gv-muted);font-size:0.88rem;line-height:1.5}.gv-blog-answer,.gv-blog-summary,.gv-blog-keypoints,.gv-blog-takeaway,.gv-blog-takeaways,.gv-blog-note{margin:clamp(1.6rem,4vw,2.6rem) 0;padding:clamp(1.2rem,3vw,1.7rem);border:1px solid #c9e4ed;border-radius:18px;background:linear-gradient(135deg,#eaf8fb 0%,#f7fafc 100%)}.gv-blog-answer{border-left:5px solid var(--gv-cyan)}.gv-blog-note{border-color:#fed8d1;background:#fff7f5}.gv-blog-article:where(.gv-blog-answer,.gv-blog-summary,.gv-blog-keypoints,.gv-blog-takeaway,.gv-blog-takeaways,.gv-blog-note) h2{margin:0 0 0.6rem;font-size:clamp(1.22rem,2vw,1.45rem)}.gv-blog-toc{margin:clamp(1.8rem,4vw,2.8rem) 0;padding:clamp(1.25rem,3vw,1.8rem);border:1px solid var(--gv-line);border-radius:18px;background:var(--gv-white);box-shadow:0 10px 32px rgba(7,25,45,0.06)}.gv-blog-toc h2{margin:0 0 0.7rem;font-size:1.4rem}.gv-blog-toc ol{columns:2;column-gap:2.4rem;padding-left:1.35rem}.gv-blog-toc li{break-inside:avoid}.gv-blog-table-wrap,.gv-blog-table-responsive{width:100%;margin:1.6rem 0;overflow-x:auto;border:1px solid var(--gv-line);border-radius:16px;background:var(--gv-white);-webkit-overflow-scrolling:touch}.gv-blog-table{width:100%;min-width:720px;border-collapse:collapse;background:var(--gv-white);font-size:0.92rem;line-height:1.5}.gv-blog-table caption{padding:1rem 1.1rem;background:var(--gv-navy);color:var(--gv-white);font-weight:780;text-align:left}.gv-blog-table:where(th,td){padding:0.85rem 1rem;border-bottom:1px solid var(--gv-line);vertical-align:top;text-align:left}.gv-blog-table thead th{background:#eaf3fb;color:var(--gv-navy)}.gv-blog-table tbody th{color:var(--gv-navy);font-weight:760}.gv-blog-table tbody tr:nth-child(even){background:#f8fafc}.gv-blog-table tbody tr:last-child:where(th,td){border-bottom:0}.gv-blog-table-mobile,.gv-blog-mobile-alternative{display:none;margin:1.3rem 0;padding:1.15rem;border:1px solid var(--gv-line);border-radius:16px;background:var(--gv-soft)}.gv-blog-article:where(.gv-blog-table-mobile,.gv-blog-mobile-alternative) h3{margin-top:0}.gv-blog-faq details{margin:0.78rem 0;padding:1rem 1.15rem;border:1px solid var(--gv-line);border-radius:14px;background:var(--gv-white);box-shadow:0 5px 18px rgba(7,25,45,0.04)}.gv-blog-faq details[open]{border-color:#acdce6}.gv-blog-faq summary{color:var(--gv-navy);font-weight:780;cursor:pointer}.gv-blog-faq details>:last-child{margin-bottom:0}.gv-blog-conclusion{margin-top:3rem;padding:clamp(1.35rem,3.5vw,2rem);border-radius:20px;background:var(--gv-navy);color:#eaf2fa}.gv-blog-conclusion:where(h2,h3){color:var(--gv-white)}.gv-blog-conclusion h2{margin-top:0}.gv-blog-conclusion a{color:#64dcea}.gv-blog-sources{margin-top:3rem;padding-top:1.5rem;border-top:2px solid var(--gv-line);color:var(--gv-muted);font-size:0.88rem}.gv-blog-footer{clear:both}.gv-blog-sources h2{margin-top:0;font-size:1.4rem}.gv-blog-disclaimer{color:var(--gv-muted);font-size:0.84rem}.gv-blog-article code{padding:0.08em 0.32em;border-radius:0.28em;background:#edf2f7}@media (max-width:760px){.gv-blog-article{font-size:1rem}.gv-blog-article h1{font-size:clamp(2.15rem,11vw,3rem)}.gv-blog-toc ol{columns:1}.gv-blog-table-wrap + .gv-blog-table-mobile,.gv-blog-table-responsive + .gv-blog-table-mobile,.gv-blog-table-wrap + .gv-blog-mobile-alternative,.gv-blog-table-responsive + .gv-blog-mobile-alternative{display:block}.gv-blog-table-wrap,.gv-blog-table-responsive{display:none}}@media (prefers-reduced-motion:reduce){.gv-blog-article *,.gv-blog-article *::before,.gv-blog-article *::after{scroll-behavior:auto !important}}@media print{.gv-blog-article{max-width:none;color:#000;font-size:11pt}.gv-blog-figure img,.gv-blog-toc,.gv-blog-faq details{box-shadow:none}.gv-blog-table-wrap,.gv-blog-table-responsive{display:block;overflow:visible}.gv-blog-table{min-width:0}}<\/style>\n<article class=\"gv-blog-article\" lang=\"fr-BE\">\n<header class=\"gv-blog-header\">\n<p class=\"gv-blog-kicker\">Cybers\u00e9curit\u00e9 \u00b7 E-mail \u00b7 Belgique<\/p>\n<p class=\"gv-blog-intro\">Un faux e-mail envoy\u00e9 avec le nom de votre organisation peut viser un client, un fournisseur ou un coll\u00e8gue sans jamais entrer dans votre environnement Microsoft 365. La d\u00e9fense commence donc dans le DNS public. Ce guide explique comment combiner SPF, DKIM et DMARC, puis quand ajouter MTA-STS, TLS-RPT, DANE et DNSSEC.<\/p>\n<aside class=\"gv-blog-answer\" aria-labelledby=\"reponse-essentielle\">\n<h2 id=\"reponse-essentielle\">R\u00e9ponse essentielle<\/h2>\n<p>SPF autorise les serveurs d\u2019envoi, DKIM signe les messages et DMARC v\u00e9rifie que ces contr\u00f4les correspondent au domaine visible dans le champ \u00ab De \u00bb. Une organisation belge devrait inventorier tous ses exp\u00e9diteurs, corriger SPF, activer DKIM, observer les rapports DMARC avec <code>p=none<\/code>, puis passer progressivement \u00e0 <code>quarantine<\/code> et <code>reject<\/code>. MTA-STS ou DANE prot\u00e8ge ensuite le transport SMTP\u00a0; aucun de ces m\u00e9canismes ne remplace la s\u00e9curit\u00e9 des comptes.<\/p>\n<\/aside>\n<aside class=\"gv-blog-summary\" aria-labelledby=\"en-bref\">\n<h2 id=\"en-bref\">En bref<\/h2>\n<ul>\n<li>DMARC bloque l\u2019usurpation directe d\u2019un domaine, pas le piratage d\u2019une bo\u00eete l\u00e9gitime ni les domaines ressemblants.<\/li>\n<li>La difficult\u00e9 principale n\u2019est pas d\u2019\u00e9crire un enregistrement DNS, mais de retrouver chaque service qui envoie au nom de l\u2019organisation.<\/li>\n<li>Une politique <code>p=reject<\/code> se publie apr\u00e8s analyse et tests, jamais comme premier changement.<\/li>\n<li>Les domaines inutilis\u00e9s et les sous-domaines doivent aussi recevoir une politique explicite.<\/li>\n<li>MTA-STS, TLS-RPT et DANE traitent la s\u00e9curit\u00e9 du transport\u00a0; SPF, DKIM et DMARC traitent l\u2019identit\u00e9 de l\u2019exp\u00e9diteur.<\/li>\n<\/ul>\n<\/aside>\n<\/header>\n<nav class=\"gv-blog-toc\" aria-labelledby=\"sommaire\">\n<h2 id=\"sommaire\">Sommaire<\/h2>\n<ol>\n<li><a href=\"#pourquoi-maintenant\">Pourquoi agir maintenant<\/a><\/li>\n<li><a href=\"#roles\">Le r\u00f4le de chaque standard<\/a><\/li>\n<li><a href=\"#inventaire\">Inventorier les exp\u00e9diteurs<\/a><\/li>\n<li><a href=\"#microsoft-365\">M\u00e9thode Microsoft 365<\/a><\/li>\n<li><a href=\"#progression-dmarc\">Passer de p=none \u00e0 reject<\/a><\/li>\n<li><a href=\"#transport\">MTA-STS ou DANE<\/a><\/li>\n<li><a href=\"#cas-belges\">Cas d\u2019usage belges<\/a><\/li>\n<li><a href=\"#erreurs\">Erreurs fr\u00e9quentes<\/a><\/li>\n<li><a href=\"#checklist\">Checklist de validation<\/a><\/li>\n<li><a href=\"#faq\">FAQ<\/a><\/li>\n<\/ol>\n<\/nav>\n<figure class=\"gv-blog-figure gv-blog-hero\">\n<picture><img fetchpriority=\"high\" src=\"https:\/\/gvision.be\/wp-content\/uploads\/2026\/08\/securite-domaine-email-belgique-hero.webp\" width=\"1600\" height=\"900\" alt=\"\u00c9quipe belge analysant les chemins d\u2019envoi et la protection d\u2019un domaine e-mail\" decoding=\"async\"><\/picture><figcaption>La protection du domaine commence par une vision compl\u00e8te des services qui envoient r\u00e9ellement des e-mails. Illustration GVISION.<\/figcaption><\/figure>\n<section class=\"gv-blog-section\" id=\"pourquoi-maintenant\">\n<h2>Pourquoi la s\u00e9curit\u00e9 du domaine e-mail devient prioritaire en Belgique<\/h2>\n<p><strong>Un domaine connu est une identit\u00e9 num\u00e9rique\u00a0: s\u2019il peut \u00eatre usurp\u00e9, la confiance construite par l\u2019organisation sert l\u2019attaquant.<\/strong> Le faux message peut demander un changement de compte bancaire, diffuser une fausse facture, inviter \u00e0 se connecter sur une page de phishing ou se faire passer pour la direction. Il ne faut pas que l\u2019attaquant ait acc\u00e8s au tenant pour imiter l\u2019adresse visible.<\/p>\n<p>Safeonweb@work, le service destin\u00e9 aux organisations du Centre pour la Cybers\u00e9curit\u00e9 Belgique, pr\u00e9sente SPF, DKIM, DMARC et DNSSEC comme des m\u00e9canismes compl\u00e9mentaires contre le spoofing et le phishing. Sa recommandation du <a href=\"https:\/\/atwork.safeonweb.be\/tools-resources\/top-advice\/dns-security-enabler-crucial-role-spf-dkim-dmarc-and-dnssec\" target=\"_blank\" rel=\"noopener\">2 septembre 2025 sur la s\u00e9curisation du DNS et de l\u2019e-mail<\/a> fournit des guides d\u2019impl\u00e9mentation distincts pour SPF, DKIM et DMARC. Cette source belge \u00e9vite de r\u00e9duire le sujet \u00e0 la seule d\u00e9livrabilit\u00e9 marketing.<\/p>\n<p>La page <a href=\"https:\/\/gvision.be\/cybersecurite\/\">cybers\u00e9curit\u00e9 de GVISION<\/a> replace cette protection dans un ensemble plus large\u00a0: identit\u00e9s, postes, r\u00e9seaux, donn\u00e9es, sensibilisation et r\u00e9ponse. C\u2019est important, car DMARC ne bloque ni un message envoy\u00e9 depuis une bo\u00eete r\u00e9ellement compromise, ni un domaine ressemblant achet\u00e9 par un fraudeur.<\/p>\n<\/section>\n<section class=\"gv-blog-section\" id=\"roles\">\n<h2>SPF, DKIM, DMARC, DNSSEC, MTA-STS et DANE\u00a0: qui fait quoi\u00a0?<\/h2>\n<p><strong>Les standards ne sont pas des alternatives\u00a0: ils couvrent des questions diff\u00e9rentes et se renforcent lorsqu\u2019ils sont d\u00e9ploy\u00e9s ensemble.<\/strong> SPF demande si le serveur est autoris\u00e9 \u00e0 envoyer. DKIM demande si une signature valide prot\u00e8ge le message. DMARC demande si l\u2019un de ces r\u00e9sultats est align\u00e9 avec le domaine visible. MTA-STS et DANE prot\u00e8gent le trajet entre serveurs.<\/p>\n<div class=\"gv-blog-table-wrap\" tabindex=\"0\" aria-label=\"Tableau comparatif des standards de s\u00e9curit\u00e9 e-mail\">\n<table class=\"gv-blog-table\">\n<caption>Comparaison des principaux m\u00e9canismes de s\u00e9curit\u00e9 du domaine e-mail<\/caption>\n<thead>\n<tr>\n<th scope=\"col\">M\u00e9canisme<\/th>\n<th scope=\"col\">Question trait\u00e9e<\/th>\n<th scope=\"col\">Avantage<\/th>\n<th scope=\"col\">Limite<\/th>\n<th scope=\"col\">Meilleur usage selon le besoin<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<th scope=\"row\">SPF<\/th>\n<td>Cette adresse IP est-elle autoris\u00e9e pour le domaine d\u2019enveloppe\u00a0?<\/td>\n<td>Inventorie les infrastructures d\u2019envoi autoris\u00e9es.<\/td>\n<td>Peut casser lors d\u2019un transfert\u00a0; limite de recherches DNS\u00a0; n\u2019aligne pas seul le champ \u00ab De \u00bb.<\/td>\n<td>Base de contr\u00f4le de toutes les sources d\u2019envoi.<\/td>\n<\/tr>\n<tr>\n<th scope=\"row\">DKIM<\/th>\n<td>La signature cryptographique est-elle valide et le contenu sign\u00e9 est-il intact\u00a0?<\/td>\n<td>R\u00e9siste mieux au transfert lorsque le message n\u2019est pas modifi\u00e9.<\/td>\n<td>Une signature valide n\u2019est utile \u00e0 DMARC que si le domaine est align\u00e9.<\/td>\n<td>Signature de Microsoft 365 et des services tiers.<\/td>\n<\/tr>\n<tr>\n<th scope=\"row\">DMARC<\/th>\n<td>SPF ou DKIM passe-t-il avec alignement au domaine visible\u00a0?<\/td>\n<td>Politique de traitement et rapports agr\u00e9g\u00e9s.<\/td>\n<td>N\u2019emp\u00eache pas l\u2019usage d\u2019un domaine ressemblant ni l\u2019envoi depuis un compte compromis.<\/td>\n<td>R\u00e9duire l\u2019usurpation directe du domaine.<\/td>\n<\/tr>\n<tr>\n<th scope=\"row\">DNSSEC<\/th>\n<td>La r\u00e9ponse DNS est-elle authentique\u00a0?<\/td>\n<td>Ajoute une cha\u00eene de confiance aux donn\u00e9es DNS.<\/td>\n<td>Demande un support correct du registre, du registrar et de l\u2019h\u00e9bergeur DNS.<\/td>\n<td>Prot\u00e9ger les enregistrements DNS et pr\u00e9parer DANE.<\/td>\n<\/tr>\n<tr>\n<th scope=\"row\">MTA-STS + TLS-RPT<\/th>\n<td>Le serveur \u00e9metteur doit-il exiger TLS vers les MX annonc\u00e9s\u00a0?<\/td>\n<td>D\u00e9ploiement compatible sans DNSSEC et rapports sur les erreurs TLS.<\/td>\n<td>D\u00e9pend du DNS et d\u2019une politique publi\u00e9e en HTTPS avec certificat valide.<\/td>\n<td>Renforcer le transport entrant d\u2019un domaine.<\/td>\n<\/tr>\n<tr>\n<th scope=\"row\">SMTP DANE<\/th>\n<td>Le certificat du serveur mail correspond-il aux donn\u00e9es TLSA authentifi\u00e9es\u00a0?<\/td>\n<td>Authentification du transport fond\u00e9e sur DNSSEC.<\/td>\n<td>DNSSEC est obligatoire et l\u2019exploitation est plus exigeante.<\/td>\n<td>Cha\u00eene DNSSEC ma\u00eetris\u00e9e et exigences \u00e9lev\u00e9es.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<div class=\"gv-blog-table-mobile\" aria-label=\"R\u00e9sum\u00e9 mobile du comparatif\">\n<h3>Lecture mobile<\/h3>\n<ul>\n<li><strong>Identit\u00e9\u00a0:<\/strong> SPF autorise, DKIM signe, DMARC aligne et applique une politique.<\/li>\n<li><strong>DNS\u00a0:<\/strong> DNSSEC authentifie les r\u00e9ponses.<\/li>\n<li><strong>Transport\u00a0:<\/strong> MTA-STS ou DANE impose une livraison TLS v\u00e9rifi\u00e9e\u00a0; TLS-RPT signale les \u00e9checs.<\/li>\n<li><strong>Choix\u00a0:<\/strong> d\u00e9ployer d\u2019abord SPF, DKIM et DMARC\u00a0; ajouter le transport selon l\u2019architecture.<\/li>\n<\/ul>\n<\/div>\n<p>L\u2019alignement est le point souvent oubli\u00e9. Microsoft explique que SPF v\u00e9rifie le domaine du <em>MAIL FROM<\/em> et que DKIM signe avec un domaine indiqu\u00e9 dans la signature\u00a0; sans DMARC, ces domaines peuvent \u00eatre diff\u00e9rents de celui affich\u00e9 \u00e0 l\u2019utilisateur. La <a href=\"https:\/\/learn.microsoft.com\/en-us\/defender-office-365\/email-authentication-about\" target=\"_blank\" rel=\"noopener\">documentation Microsoft sur l\u2019authentification e-mail<\/a> montre comment DMARC relie ces r\u00e9sultats au champ \u00ab From \u00bb visible.<\/p>\n<\/section>\n<section class=\"gv-blog-section\" id=\"inventaire\">\n<h2>Commencer par l\u2019inventaire des exp\u00e9diteurs, pas par un enregistrement DNS<\/h2>\n<p><strong>Le d\u00e9ploiement r\u00e9ussit lorsque chaque source l\u00e9gitime est connue, attribu\u00e9e \u00e0 un propri\u00e9taire et test\u00e9e\u00a0; le DNS vient ensuite.<\/strong> Un inventaire incomplet produit deux r\u00e9sultats possibles\u00a0: une politique trop faible qui laisse passer l\u2019usurpation, ou une politique stricte qui bloque des factures, confirmations ou alertes utiles.<\/p>\n<h3>Cr\u00e9er une matrice par domaine et par flux<\/h3>\n<p>Listez le domaine principal, les domaines secondaires, les anciennes marques, les domaines d\u00e9fensifs et les sous-domaines. Pour chacun, documentez l\u2019adresse visible, le domaine d\u2019enveloppe, le domaine DKIM, le prestataire, le propri\u00e9taire m\u00e9tier, le volume approximatif, les destinataires habituels et la criticit\u00e9. Les rapports DMARC confirmeront l\u2019observation, mais ils ne remplacent pas les entretiens avec la finance, le marketing, les RH et les \u00e9quipes op\u00e9rationnelles.<\/p>\n<p>Les sources \u00e0 rechercher comprennent notamment\u00a0:<\/p>\n<ul>\n<li>Exchange Online, serveurs SMTP, relais et connecteurs hybrides\u00a0;<\/li>\n<li>CRM, ERP, facturation \u00e9lectronique, plateformes de paiement et signatures\u00a0;<\/li>\n<li>newsletters, outils de recrutement, enqu\u00eates, billetterie et \u00e9v\u00e9nements\u00a0;<\/li>\n<li>applications web, formulaires de contact, monitoring et syst\u00e8mes de tickets\u00a0;<\/li>\n<li>scanners, imprimantes multifonctions, NAS, alarmes et \u00e9quipements techniques\u00a0;<\/li>\n<li>prestataires qui envoient r\u00e9ellement avec votre domaine, et pas seulement en leur nom.<\/li>\n<\/ul>\n<h3>S\u00e9parer les flux lorsque c\u2019est utile<\/h3>\n<p>Les domaines qui n\u2019envoient jamais doivent recevoir une politique explicite. Ils n\u2019ont pas besoin d\u2019autoriser des serveurs dans SPF ni de publier des cl\u00e9s DKIM. Une politique DMARC stricte r\u00e9duit leur int\u00e9r\u00eat pour l\u2019usurpation. Documentez n\u00e9anmoins l\u2019intention\u00a0: un domaine \u00ab inutilis\u00e9 \u00bb aujourd\u2019hui pourrait \u00eatre activ\u00e9 demain par un projet oubli\u00e9.<\/p>\n<\/section>\n<section class=\"gv-blog-section\" id=\"microsoft-365\">\n<h2>Configurer SPF, DKIM et DMARC autour de Microsoft 365<\/h2>\n<p><strong>Dans Microsoft 365, le bon ordre est SPF, DKIM sur chaque domaine personnalis\u00e9, puis DMARC progressif, avec un test externe des en-t\u00eates.<\/strong> Microsoft pr\u00e9cise que DKIM n\u2019est pas automatiquement sign\u00e9 avec le domaine personnalis\u00e9 tant que sa configuration n\u2019est pas activ\u00e9e. L\u2019envoi avec le domaine initial <code>onmicrosoft.com<\/code> suit une logique diff\u00e9rente.<\/p>\n<h3>1. Consolider SPF<\/h3>\n<p>Il ne doit exister qu\u2019un seul enregistrement SPF par domaine ou sous-domaine. Fusionnez les sources au lieu de publier plusieurs TXT commen\u00e7ant par <code>v=spf1<\/code>. V\u00e9rifiez les m\u00e9canismes <code>include<\/code>, retirez les anciens prestataires et surveillez la limite de dix recherches DNS fix\u00e9e par SPF. La <a href=\"https:\/\/learn.microsoft.com\/en-us\/defender-office-365\/email-authentication-spf-configure\" target=\"_blank\" rel=\"noopener\">proc\u00e9dure Microsoft SPF<\/a> insiste sur le fait que SPF seul ne suffit pas.<\/p>\n<h3>2. Activer DKIM sur les domaines personnalis\u00e9s<\/h3>\n<p>Cr\u00e9ez les deux CNAME demand\u00e9s dans le portail Microsoft Defender, attendez leur r\u00e9solution, puis activez la signature. Les valeurs sont propres au tenant et au domaine\u00a0: ne recopiez pas un exemple trouv\u00e9 dans un article. Envoyez ensuite un message vers une bo\u00eete externe et v\u00e9rifiez <code>dkim=pass<\/code> ainsi que le domaine de signature. Pr\u00e9voyez aussi DKIM chez chaque prestataire tiers capable de signer avec votre domaine.<\/p>\n<h3>3. Publier DMARC en observation<\/h3>\n<p>Une premi\u00e8re politique peut utiliser <code>p=none<\/code> avec une adresse d\u00e9di\u00e9e aux rapports agr\u00e9g\u00e9s. Elle n\u2019applique pas encore de mise en quarantaine, mais r\u00e9v\u00e8le les domaines, IP et r\u00e9sultats observ\u00e9s par les destinataires participants. Les rapports XML bruts deviennent vite volumineux\u00a0; une plateforme de traitement ou un processus d\u2019analyse interne doit transformer ces donn\u00e9es en sources, tendances et exceptions actionnables.<\/p>\n<figure class=\"gv-blog-figure\">\n<picture><img loading=\"lazy\" src=\"https:\/\/gvision.be\/wp-content\/uploads\/2026\/08\/test-authentification-email-microsoft-365.webp\" width=\"1200\" height=\"800\" alt=\"Administrateurs testant les r\u00e9sultats SPF DKIM et DMARC de plusieurs applications m\u00e9tier\" decoding=\"async\" loading=\"lazy\"><\/picture><figcaption>Avant l\u2019application d\u2019une politique stricte, testez les messages de Microsoft 365 et de chaque application autoris\u00e9e. Illustration GVISION.<\/figcaption><\/figure>\n<p>Le service <a href=\"https:\/\/gvision.be\/modern-workplace\/microsoft-365\/\">Microsoft 365 de GVISION<\/a> peut int\u00e9grer ce chantier \u00e0 la gouvernance du tenant, aux connecteurs, aux comptes techniques et au support des applications. L\u2019objectif n\u2019est pas seulement d\u2019obtenir trois r\u00e9sultats \u00ab pass \u00bb, mais de garder cette configuration coh\u00e9rente lors de chaque changement.<\/p>\n<\/section>\n<section class=\"gv-blog-section\" id=\"progression-dmarc\">\n<h2>Passer de p=none \u00e0 quarantine puis reject sans incident<\/h2>\n<p><strong>La progression DMARC doit \u00eatre fond\u00e9e sur des preuves\u00a0: les flux l\u00e9gitimes passent avec alignement, les inconnus sont qualifi\u00e9s et une proc\u00e9dure de retour existe.<\/strong> Microsoft recommande explicitement une approche graduelle vers <code>p=reject<\/code> afin d\u2019\u00e9viter le rejet de bons messages provoqu\u00e9 par des \u00e9checs non intentionnels.<\/p>\n<figure class=\"gv-blog-figure gv-blog-infographic\">\n<picture><img loading=\"lazy\" src=\"https:\/\/gvision.be\/wp-content\/uploads\/2026\/08\/deploiement-dmarc-fr.svg\" width=\"1200\" height=\"760\" alt=\"Processus en six \u00e9tapes pour d\u00e9ployer DMARC de l\u2019inventaire au suivi continu\" decoding=\"async\" loading=\"lazy\"><\/picture><figcaption>Une politique stricte est la derni\u00e8re \u00e9tape d\u2019un processus d\u2019identification, d\u2019alignement et de test. Illustration GVISION.<\/figcaption><\/figure>\n<h3>D\u00e9finir des crit\u00e8res de passage<\/h3>\n<p>Le passage \u00e0 <code>quarantine<\/code> permet aux destinataires compatibles de traiter les \u00e9checs plus s\u00e9v\u00e8rement, souvent vers le courrier ind\u00e9sirable. Le param\u00e8tre <code>pct<\/code> peut limiter la proportion demand\u00e9e, mais son interpr\u00e9tation d\u00e9pend du destinataire et ne remplace pas les tests. Le passage \u00e0 <code>reject<\/code> demande que les flux utiles soient ma\u00eetris\u00e9s. Utilisez aussi <code>sp<\/code> pour d\u00e9finir le comportement des sous-domaines lorsque la politique doit diff\u00e9rer.<\/p>\n<h3>Garder une proc\u00e9dure de changement<\/h3>\n<p>Tout nouvel outil qui envoie des messages doit passer par une revue avant sa mise en production\u00a0: sous-domaine, adresses, DKIM, SPF, alignement, destinataires de test et responsable. Sans cette porte d\u2019entr\u00e9e, la configuration se d\u00e9grade en quelques mois. Les rapports DMARC doivent rester surveill\u00e9s apr\u00e8s <code>reject<\/code> pour d\u00e9tecter un prestataire modifi\u00e9, une cl\u00e9 expir\u00e9e, une nouvelle source non autoris\u00e9e ou une campagne d\u2019usurpation.<\/p>\n<\/section>\n<section class=\"gv-blog-section\" id=\"transport\">\n<h2>MTA-STS ou DANE\u00a0: s\u00e9curiser le transport SMTP apr\u00e8s l\u2019identit\u00e9<\/h2>\n<p><strong>SPF, DKIM et DMARC authentifient l\u2019exp\u00e9diteur\u00a0; MTA-STS et DANE cherchent \u00e0 emp\u00eacher qu\u2019un serveur \u00e9metteur livre le message vers une destination non authentifi\u00e9e ou sans TLS fiable.<\/strong> Ils r\u00e9pondent donc \u00e0 une autre couche du risque.<\/p>\n<p>SMTP utilise souvent TLS de mani\u00e8re opportuniste\u00a0: le chiffrement est utilis\u00e9 lorsque les deux serveurs l\u2019acceptent, mais un attaquant capable d\u2019influencer le DNS ou la n\u00e9gociation peut tenter une redirection ou une d\u00e9gradation. <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc8461\" target=\"_blank\" rel=\"noopener\">MTA-STS, d\u00e9fini par la RFC 8461<\/a>, publie en HTTPS une politique indiquant les serveurs MX attendus et l\u2019exigence TLS. <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc8460\" target=\"_blank\" rel=\"noopener\">TLS-RPT, d\u00e9fini par la RFC 8460<\/a>, fournit des rapports sur les \u00e9checs de n\u00e9gociation ou de validation.<\/p>\n<p>DANE pour SMTP utilise des enregistrements TLSA authentifi\u00e9s par DNSSEC. Microsoft r\u00e9sume la diff\u00e9rence ainsi\u00a0: DANE exige DNSSEC, tandis que MTA-STS s\u2019appuie sur le syst\u00e8me d\u2019autorit\u00e9s de certification. La documentation <a href=\"https:\/\/learn.microsoft.com\/en-us\/exchange\/security-and-compliance\/how-dane-secures-email\" target=\"_blank\" rel=\"noopener\">Exchange Online sur DANE et MTA-STS<\/a>, mise \u00e0 jour le 21 juillet 2026, explique \u00e9galement pourquoi TLS opportuniste ne suffit pas contre certaines attaques de r\u00e9solution DNS.<\/p>\n<\/section>\n<section class=\"gv-blog-section\" id=\"cas-belges\">\n<h2>Adapter la mise en \u0153uvre au fonctionnement r\u00e9el de l\u2019organisation<\/h2>\n<p><strong>La taille ne d\u00e9termine pas la complexit\u00e9\u00a0: le nombre de domaines, de prestataires et de flux m\u00e9tiers est plus r\u00e9v\u00e9lateur.<\/strong> Un cabinet de dix personnes avec facturation, portail client, newsletter et scanners peut avoir plus de sources d\u2019envoi qu\u2019une structure centralis\u00e9e de cent personnes.<\/p>\n<h3>ASBL, \u00e9cole ou organisation publique<\/h3>\n<p>Les outils se multiplient souvent par projet, ann\u00e9e scolaire ou subvention. Maintenez un registre avec propri\u00e9taire et date de fin. D\u00e9sactivez l\u2019autorisation SPF et les cl\u00e9s d\u2019un fournisseur quitt\u00e9. Prot\u00e9gez les domaines inactifs et les anciennes variantes. Pour les listes de diffusion qui modifient l\u2019objet ou le corps, v\u00e9rifiez l\u2019impact sur DKIM et envisagez les m\u00e9canismes ARC lorsque la cha\u00eene de transfert est l\u00e9gitime.<\/p>\n<h3>Groupe multi-sites ou grande entreprise<\/h3>\n<p>La gouvernance doit \u00eatre f\u00e9d\u00e9r\u00e9e sans perdre le contr\u00f4le central. Attribuez des sous-domaines par usage, automatisez l\u2019inventaire DNS, imposez des exigences contractuelles aux fournisseurs et centralisez les rapports. Une \u00e9quipe valide les standards\u00a0; chaque entit\u00e9 reste responsable de ses applications. Les acquisitions n\u00e9cessitent un inventaire avant de modifier une politique h\u00e9rit\u00e9e.<\/p>\n<h3>Site web et formulaires<\/h3>\n<p>Le serveur web ne devrait pas usurper arbitrairement l\u2019adresse du visiteur dans le champ \u00ab From \u00bb. Utilisez une adresse de votre domaine correctement authentifi\u00e9e et placez l\u2019adresse du demandeur dans <code>Reply-To<\/code>. Cette distinction \u00e9vite de casser DMARC tout en permettant la r\u00e9ponse. Pour les notifications h\u00e9berg\u00e9es chez un prestataire, privil\u00e9giez DKIM align\u00e9 et un sous-domaine d\u00e9di\u00e9.<\/p>\n<\/section>\n<section class=\"gv-blog-section\" id=\"erreurs\">\n<h2>Les erreurs qui fragilisent ou interrompent la messagerie<\/h2>\n<p><strong>La plupart des incidents viennent d\u2019une vue incompl\u00e8te des flux, d\u2019un alignement mal compris ou d\u2019une politique publi\u00e9e sans observation.<\/strong> La syntaxe DNS est rarement le seul probl\u00e8me.<\/p>\n<ol>\n<li><strong>Publier plusieurs SPF\u00a0:<\/strong> un domaine ne doit avoir qu\u2019une politique SPF. Plusieurs enregistrements cr\u00e9ent une erreur permanente.<\/li>\n<li><strong>D\u00e9passer les recherches DNS\u00a0:<\/strong> les <code>include<\/code> imbriqu\u00e9s peuvent d\u00e9passer la limite. Mesurez l\u2019\u00e9valuation compl\u00e8te avant d\u2019ajouter un fournisseur.<\/li>\n<li><strong>Confondre pass et alignement\u00a0:<\/strong> SPF ou DKIM peut passer sur un domaine tiers tandis que DMARC \u00e9choue face au domaine visible.<\/li>\n<li><strong>Passer directement \u00e0 reject\u00a0:<\/strong> les imprimantes, CRM, formulaires ou factures oubli\u00e9s deviennent des victimes collat\u00e9rales.<\/li>\n<li><strong>Laisser p=none ind\u00e9finiment\u00a0:<\/strong> l\u2019organisation collecte des rapports mais ne demande jamais aux destinataires de bloquer les \u00e9checs.<\/li>\n<li><strong>Autoriser trop largement\u00a0:<\/strong> l\u2019inclusion d\u2019une grande plateforme peut permettre \u00e0 d\u2019autres clients du fournisseur de passer SPF\u00a0; DKIM align\u00e9 r\u00e9duit cette d\u00e9pendance.<\/li>\n<li><strong>Ignorer les domaines dormants\u00a0:<\/strong> ils restent attractifs pour l\u2019usurpation alors qu\u2019une politique stricte y est souvent simple.<\/li>\n<li><strong>Utiliser une allowlist comme correction permanente\u00a0:<\/strong> Microsoft avertit que certaines listes d\u2019autorisation peuvent contourner des contr\u00f4les d\u2019authentification et de filtrage.<\/li>\n<li><strong>Oublier l\u2019exploitation\u00a0:<\/strong> une cl\u00e9, un connecteur ou un fournisseur change\u00a0; sans supervision, la conformit\u00e9 d\u2019aujourd\u2019hui devient l\u2019incident de demain.<\/li>\n<\/ol>\n<aside class=\"gv-blog-note\">\n<h2>Limite importante<\/h2>\n<p>Si un attaquant contr\u00f4le r\u00e9ellement une bo\u00eete Microsoft 365, ses messages peuvent passer SPF, DKIM et DMARC parce qu\u2019ils sont envoy\u00e9s par l\u2019infrastructure l\u00e9gitime. Les passkeys, l\u2019authentification multifacteur r\u00e9sistante au phishing, les politiques d\u2019acc\u00e8s, la d\u00e9tection et la r\u00e9ponse restent n\u00e9cessaires.<\/p>\n<\/aside>\n<\/section>\n<section class=\"gv-blog-section\" id=\"checklist\">\n<h2>Checklist de validation avant une politique DMARC stricte<\/h2>\n<p><strong>Une politique stricte est pr\u00eate lorsque l\u2019organisation peut prouver qui envoie, comment chaque flux s\u2019authentifie et qui r\u00e9agit \u00e0 un \u00e9chec.<\/strong> Utilisez cette liste comme contr\u00f4le de changement, pas comme certification.<\/p>\n<ul>\n<li>Tous les domaines et sous-domaines sont inventori\u00e9s, y compris les domaines inactifs.<\/li>\n<li>Chaque source a un propri\u00e9taire m\u00e9tier et un responsable technique.<\/li>\n<li>Un seul enregistrement SPF valide existe et reste sous la limite de recherches DNS.<\/li>\n<li>DKIM est activ\u00e9 et v\u00e9rifi\u00e9 pour Microsoft 365 et les plateformes tierces importantes.<\/li>\n<li>Le domaine SPF ou DKIM s\u2019aligne avec le champ \u00ab From \u00bb pour chaque flux critique.<\/li>\n<li>Les rapports DMARC couvrent les cycles rares\u00a0: paie, facturation, campagnes et notifications saisonni\u00e8res.<\/li>\n<li>Les transferts, listes de diffusion et passerelles ont \u00e9t\u00e9 test\u00e9s.<\/li>\n<li>Les sous-domaines et domaines dormants ont une politique document\u00e9e.<\/li>\n<li>Un canal d\u2019alerte, une proc\u00e9dure de retour et un propri\u00e9taire existent.<\/li>\n<li>Les changements futurs de CRM, ERP, site ou fournisseur passent par une revue e-mail.<\/li>\n<li>MTA-STS ou DANE est \u00e9valu\u00e9 s\u00e9par\u00e9ment selon la ma\u00eetrise de DNSSEC et des connecteurs.<\/li>\n<li>La date, les preuves et la d\u00e9cision de passer \u00e0 <code>quarantine<\/code> ou <code>reject<\/code> sont conserv\u00e9es.<\/li>\n<\/ul>\n<\/section>\n<aside class=\"gv-blog-takeaway\" aria-labelledby=\"a-retenir\">\n<h2 id=\"a-retenir\">\u00c0 retenir<\/h2>\n<p>SPF, DKIM et DMARC forment un syst\u00e8me d\u2019identit\u00e9, pas un filtre magique. Le projet doit relier DNS, Microsoft 365 et applications m\u00e9tier. Une progression fond\u00e9e sur les rapports prot\u00e8ge la d\u00e9livrabilit\u00e9 tout en allant vers <code>p=reject<\/code>. MTA-STS, TLS-RPT, DANE et DNSSEC compl\u00e8tent la protection du transport et du DNS. La s\u00e9curit\u00e9 des comptes et la d\u00e9tection restent indispensables.<\/p>\n<\/aside>\n<section class=\"gv-blog-section gv-blog-faq\" id=\"faq\">\n<h2>Questions fr\u00e9quentes<\/h2>\n<details>\n<summary>DMARC exige-t-il que SPF et DKIM passent tous les deux\u00a0?<\/summary>\n<p>Non. DMARC r\u00e9ussit si SPF ou DKIM passe et si le domaine correspondant est align\u00e9 avec le domaine visible dans le champ \u00ab From \u00bb. Disposer des deux m\u00e9canismes augmente toutefois la r\u00e9silience, notamment face aux transferts qui peuvent casser SPF.<\/p>\n<\/details>\n<details>\n<summary>Peut-on publier directement p=reject\u00a0?<\/summary>\n<p>C\u2019est techniquement possible, mais risqu\u00e9 pour un domaine actif. Microsoft recommande de configurer SPF et DKIM, d\u2019observer les rapports, de corriger les flux puis de progresser vers <code>quarantine<\/code> et <code>reject<\/code>. Un domaine r\u00e9ellement inactif peut suivre une proc\u00e9dure plus courte apr\u00e8s v\u00e9rification.<\/p>\n<\/details>\n<details>\n<summary>DMARC prot\u00e8ge-t-il contre tous les e-mails de phishing\u00a0?<\/summary>\n<p>Non. Il r\u00e9duit surtout l\u2019usurpation directe de votre domaine. Il ne bloque pas automatiquement un domaine ressemblant, un compte l\u00e9gitime compromis, une fraude sans usurpation ou un lien malveillant envoy\u00e9 depuis une plateforme autoris\u00e9e.<\/p>\n<\/details>\n<details>\n<summary>Pourquoi SPF \u00e9choue-t-il lors d\u2019un transfert\u00a0?<\/summary>\n<p>Le serveur qui retransmet le message n\u2019est g\u00e9n\u00e9ralement pas autoris\u00e9 dans l\u2019enregistrement SPF du domaine d\u2019origine. DKIM peut continuer \u00e0 r\u00e9ussir si la signature et les parties sign\u00e9es restent intactes. ARC peut pr\u00e9server des r\u00e9sultats d\u2019authentification dans certaines cha\u00eenes l\u00e9gitimes.<\/p>\n<\/details>\n<details>\n<summary>Faut-il prot\u00e9ger un domaine qui n\u2019envoie aucun e-mail\u00a0?<\/summary>\n<p>Oui. Un domaine dormant peut \u00eatre usurp\u00e9 pr\u00e9cis\u00e9ment parce qu\u2019aucun flux l\u00e9gitime ne doit \u00eatre pr\u00e9serv\u00e9. Publiez une politique explicite adapt\u00e9e, v\u00e9rifiez qu\u2019aucun service oubli\u00e9 ne l\u2019utilise et documentez la d\u00e9cision avant tout futur changement.<\/p>\n<\/details>\n<details>\n<summary>MTA-STS et DANE remplacent-ils DMARC\u00a0?<\/summary>\n<p>Non. MTA-STS et DANE s\u00e9curisent la connexion entre serveurs de messagerie. DMARC traite l\u2019alignement de l\u2019identit\u00e9 de l\u2019exp\u00e9diteur. Les deux couches sont compl\u00e9mentaires et doivent \u00eatre op\u00e9r\u00e9es avec TLS-RPT ou une supervision \u00e9quivalente.<\/p>\n<\/details>\n<details>\n<summary>Combien de temps faut-il observer les rapports DMARC\u00a0?<\/summary>\n<p>Il n\u2019existe pas de dur\u00e9e universelle. Elle doit couvrir les cycles d\u2019envoi r\u00e9els de l\u2019organisation, y compris les campagnes, factures ou notifications peu fr\u00e9quentes. La d\u00e9cision d\u00e9pend de la compl\u00e9tude des sources, de la criticit\u00e9 et de la capacit\u00e9 de retour arri\u00e8re.<\/p>\n<\/details>\n<\/section>\n<section class=\"gv-blog-conclusion\" id=\"conclusion\">\n<h2>Transformer les enregistrements DNS en contr\u00f4le durable<\/h2>\n<p>Une configuration fiable relie l\u2019inventaire des applications, les param\u00e8tres Microsoft 365, le DNS, les rapports et la proc\u00e9dure de changement. GVISION peut cartographier les flux, corriger l\u2019alignement, piloter la progression DMARC et documenter l\u2019exploitation sans pr\u00e9senter ce travail comme une garantie absolue contre le phishing.<\/p>\n<p>Pour cadrer votre domaine principal, vos sous-domaines et vos services d\u2019envoi, <a href=\"https:\/\/gvision.be\/contacts\/\">parlez de votre environnement e-mail avec GVISION<\/a>.<\/p>\n<\/section>\n<footer class=\"gv-blog-footer\">\n<section class=\"gv-blog-sources\" aria-labelledby=\"sources\">\n<h2 id=\"sources\">Sources officielles et r\u00e9f\u00e9rences<\/h2>\n<ol>\n<li><a href=\"https:\/\/atwork.safeonweb.be\/tools-resources\/top-advice\/dns-security-enabler-crucial-role-spf-dkim-dmarc-and-dnssec\" target=\"_blank\" rel=\"noopener\">Safeonweb@work \u2014 SPF, DKIM, DMARC et DNSSEC<\/a>, 2 septembre 2025.<\/li>\n<li><a href=\"https:\/\/learn.microsoft.com\/en-us\/defender-office-365\/email-authentication-spf-configure\" target=\"_blank\" rel=\"noopener\">Microsoft Learn \u2014 Configurer SPF pour Microsoft 365<\/a>, mise \u00e0 jour du 3 juillet 2026.<\/li>\n<li><a href=\"https:\/\/learn.microsoft.com\/en-us\/defender-office-365\/email-authentication-dkim-configure\" target=\"_blank\" rel=\"noopener\">Microsoft Learn \u2014 Configurer DKIM<\/a>, mise \u00e0 jour du 3 juillet 2026.<\/li>\n<li><a href=\"https:\/\/learn.microsoft.com\/en-us\/defender-office-365\/email-authentication-dmarc-configure\" target=\"_blank\" rel=\"noopener\">Microsoft Learn \u2014 Configurer DMARC<\/a>, mise \u00e0 jour du 17 juillet 2026.<\/li>\n<li><a href=\"https:\/\/learn.microsoft.com\/en-us\/exchange\/security-and-compliance\/how-dane-secures-email\" target=\"_blank\" rel=\"noopener\">Microsoft Learn \u2014 SMTP DANE et MTA-STS<\/a>, mise \u00e0 jour du 21 juillet 2026.<\/li>\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc7208\" target=\"_blank\" rel=\"noopener\">RFC 7208 \u2014 Sender Policy Framework<\/a>\u00a0; <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc6376\" target=\"_blank\" rel=\"noopener\">RFC 6376 \u2014 DKIM<\/a>\u00a0; <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc7489\" target=\"_blank\" rel=\"noopener\">RFC 7489 \u2014 DMARC<\/a>.<\/li>\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc8461\" target=\"_blank\" rel=\"noopener\">RFC 8461 \u2014 MTA-STS<\/a>\u00a0; <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc8460\" target=\"_blank\" rel=\"noopener\">RFC 8460 \u2014 TLS-RPT<\/a>\u00a0; <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc7672\" target=\"_blank\" rel=\"noopener\">RFC 7672 \u2014 SMTP DANE<\/a>.<\/li>\n<\/ol>\n<p class=\"gv-blog-disclaimer\">Article v\u00e9rifi\u00e9 le 30 ao\u00fbt 2026. Les exemples DNS sont explicatifs\u00a0: les valeurs r\u00e9elles d\u00e9pendent de vos domaines, de votre tenant et de vos prestataires. Ce contenu ne constitue ni une certification ni une garantie de d\u00e9livrabilit\u00e9.<\/p>\n<\/section>\n<\/footer>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>Comment prot\u00e9ger un domaine e-mail belge contre l\u2019usurpation sans casser les factures, formulaires et applications m\u00e9tier\u00a0: inventaire, alignement, rapports et d\u00e9ploiement DMARC progressif.<\/p>","protected":false},"author":4,"featured_media":12318,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_price":"","_stock":"","_tribe_ticket_header":"","_tribe_default_ticket_provider":"","_tribe_ticket_capacity":"0","_ticket_start_date":"","_ticket_end_date":"","_tribe_ticket_show_description":"","_tribe_ticket_show_not_going":false,"_tribe_ticket_use_global_stock":"","_tribe_ticket_global_stock_level":"","_global_stock_mode":"","_global_stock_cap":"","_tribe_rsvp_for_event":"","_tribe_ticket_going_count":"","_tribe_ticket_not_going_count":"","_tribe_tickets_list":"[]","_tribe_ticket_has_attendee_info_fields":false,"footnotes":""},"categories":[96,18],"tags":[],"class_list":["post-12305","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-fr","category-cybersecurity"],"_links":{"self":[{"href":"https:\/\/gvision.be\/nl\/wp-json\/wp\/v2\/posts\/12305","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gvision.be\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/gvision.be\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/gvision.be\/nl\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/gvision.be\/nl\/wp-json\/wp\/v2\/comments?post=12305"}],"version-history":[{"count":1,"href":"https:\/\/gvision.be\/nl\/wp-json\/wp\/v2\/posts\/12305\/revisions"}],"predecessor-version":[{"id":12306,"href":"https:\/\/gvision.be\/nl\/wp-json\/wp\/v2\/posts\/12305\/revisions\/12306"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/gvision.be\/nl\/wp-json\/wp\/v2\/media\/12318"}],"wp:attachment":[{"href":"https:\/\/gvision.be\/nl\/wp-json\/wp\/v2\/media?parent=12305"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/gvision.be\/nl\/wp-json\/wp\/v2\/categories?post=12305"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/gvision.be\/nl\/wp-json\/wp\/v2\/tags?post=12305"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}