SPF, DKIM, DMARC cassés ou réécrits après un piratage
Un pirate ignore souvent SPF, DKIM et DMARC — ou les casse en réécrivant la zone. Recollez-les selon l'hébergeur mail. Un DMARC `p=reject` trop tôt jette aussi vos vrais messages. On durcit une fois la source morte et le légitime authentifié.
Un pirate ignore ces enregistrements, ou les casse. Recollez-les selon l'hébergeur mail. Un DMARC trop strict juste après l'incident jette aussi vos vrais messages.
Ce que ces trois enregistrements ne font pas
Ils authentifient (plus ou moins) QUI a le droit d'envoyer au nom du domaine, et comment le destinataire doit traiter les échecs. Ils n'empêchent pas un SMTP volé chez VOUS (le pirate s'authentifie « pour de vrai »). Ils n'enlèvent pas une DBL Spamhaus. Ils ne remplacent pas un journal d'envoi. Les traiter comme un antivirus est le malentendu n°1. Emails après piratage, guide.
Inversement, une zone cassée (SPF syntax error, DKIM qui ne matche plus) fait tomber le légitime EN PLUS du spam déjà parti. Recoller est utile ; ce n'est pas le premier geste si `mail()` tourne encore.
Lire la zone telle qu'elle est, pas telle qu'on s'en souvient
Export TXT actuel (SPF, DKIM `selector._domainkey`, DMARC `_dmarc`). Comparez à la doc de l'hébergeur mail et à un export d'avant (s'il existe, registrar). Un `include` ajouté, un sélecteur nouveau, un `p=none` devenu rien (record supprimé) : notez. Copiez avant de modifier : une zone DNS mal éditée coupe la boutique (MX, A) en plus du mail.
SPF : trop large, trop long, ou réécrit
`+all` ou un `ip4` d'un VPS inconnu : quelqu'un s'autorise. Un SPF à 12 includes dépasse les 10 lookups : échec permerror, le légitime tombe. Un pirate peut aussi simplifier à `+all` pour que SON envoi passe. Serrez vers les includes de VOTRE mail (OVH, Google, Brevo), retirez les IP mortes. SPF include trop large.
N'ajoutez pas l'IP web « au cas où » si vous n'envoyez plus en `mail()`. Vous authentifiez le prochain shell.
DKIM : sélecteur mort ou clé pirate
Le sélecteur configuré dans le CMS / le relais doit matcher le DNS. Un sélecteur réécrit, une clé publique remplacée, et vos messages (ou les siens) signent autrement. Relisez le sélecteur chez Brevo / Google / cPanel, recollez le TXT. Un second sélecteur que vous ne connaissez pas : retirez-le après avoir vérifié qu'aucun flux légitime ne l'utilise. DKIM sélecteur.
DMARC : rua, forensic, et la prudence du reject
`p=none` + rua vous montre les usurpations (et vos propres échecs). Pendant l'incident, `p=reject` trop tôt jette le transactionnel si DKIM n'est pas recollé. Remettez un DMARC valide (même `none`), surveillez rua quelques jours, puis `quarantine` / `reject` quand les sources légitimes passent. Les rapports forensic (ruf) sont rares et sensibles : ne les activez pas « pour voir » sans savoir qui reçoit. DMARC forensic.
- SPF syntax + ≤10 lookups.
- DKIM : sélecteur CMS = DNS.
- DMARC présent, p=reject seulement à froid.
Sous-domaines oubliés et includes
`news.`, `mail.`, un SPF sur la racine qui n'hérite pas comme vous croyez (`aspf`). Un staging qui envoie encore. Chaque From utilisé doit être couvert. Listez les From des journaux (boutique, devis, facture, RH). Staging.
Recoller sans casser Brevo / Google / OVH
Un seul wizard à la fois. La doc Brevo dit quels includes / DKIM coller ; Google Workspace aussi ; l'hébergeur mail aussi. Les empiler sans compter les lookups casse SPF. Si vous avez trois outils, un sous-domaine newsletter (DKIM/SPF dédiés) allège la racine — à froid, pas le soir du hack.
Après 7 jours : durcir, pas avant
Source morte, listes demandées, transactionnel qui passe, rua lisible : alors `quarantine` puis `reject`, SPF sans `~all` trop gentil si vous êtes prêts. Créer un compte si la zone a été touchée et que le MX a bougé avec — ne « corrigez » pas le MX au feeling.
- Zone exportée avant édition.
- Includes légitimes seulement.
- DKIM aligné.
- DMARC progressif.
Registrar, DNSSEC, et qui a pu réécrire la zone
Si SPF/DKIM ont été réécrits, quelqu'un avait le DNS : panel registrar, compte Cloudflare, token API DNS dans un script de deploy. Tournez ces mots de passe / tokens comme le SMTP. Un 2FA registrar après coup. DNSSEC : ne le « cassez » pas en éditant à la main sans comprendre ; une zone mal signée coupe plus que le mail.
Un historique de zone (Cloudflare audit, registrar) date la modification. Gardez-le. C'est plus parlant qu'un « on croit que le pirate a touché le SPF ». Si l'historique est vide, dites-le : l'enregistrement n'était peut-être que mal configuré depuis 2019, pas « cassé par le hack ». Les deux se recollent ; le discours au client change.
Les CNAMEs `em.` / `s1._domainkey` des relais : un delete « pour faire propre » casse DKIM. Recollez depuis la doc actuelle du relais (Brevo, Google), pas depuis un screenshot de 2022. Brevo.