Des clients Apple reçoivent encore du phishing à votre nom
Des clients Apple reçoivent encore un phishing à votre nom : usurpation (spoof) ou vrai envoi depuis vos serveurs. DMARC en quarantaine puis reject, une fois stable. Un reject trop tôt pendant l’incident jette aussi vos devis. Deux temps, pas un interrupteur de panique.
Usurpation vs envoi réel. DMARC en quarantaine ou reject, une fois stable. Pendant l'incident, un reject trop tôt jette vos devis. Deux temps.
Usurpation vs envoi réel
Spoof : le From: affiche contact@vous.fr, le message n’est pas passé par vos MX / votre SMTP. DMARC + SPF/DKIM bien calés le rendent plus difficile (pas impossible partout). Envoi réel : un script chez vous, un compte SMTP volé, un formulaire. Les journaux d’envoi le montrent (les demander). Les deux existent. Le traitement diffère.
Les clients disent « j’ai reçu un mail de vous ». Sur iPhone, l’affichage est encore plus lisse. Vous jurez que vous n’avez rien envoyé. Les deux pouvez avoir raison (spoof) ou vous avez un trou (envoi réel). Ne tranchez pas au feeling.
Le guide emails en spam et la page domaine blacklisté cadrent les listes. Ici : le nom dans Mail.app, souvent le premier signal pour une PME française.
- Demandez un transfert « afficher l’original » / en-têtes complets.
- Regardez Return-Path, Received, authentification (SPF/DKIM/DMARC).
- Croisez avec le journal hébergeur sur la même heure.
Ce qu’Apple Mail change (et ce qu’il ne change pas)
Mail Privacy Protection masque les pixels d’ouverture. Ça gêne vos stats de newsletter, pas le diagnostic d’un phishing. Ne perdez pas une journée sur « Apple cache les images donc on ne peut rien savoir ». Les en-têtes, eux, sont là si le client les transfère correctement (souvent il faut le guider : Mac Mail > Présenter > Message brut, ou l’équivalent iOS du moment).
Apple applique aussi ses propres filtres et, de plus en plus, DMARC. Un reject chez vous aide Apple à jeter le spoof. Un SPF +all ou un trou DKIM n’aide pas (SPF trop large, DKIM réécrit).
iCloud Mail n’est pas Gmail. Un test « ça passe chez Gmail » ne dit rien pour un client iCloud. Testez les deux, plus Orange.
Lire un en-tête plutôt que le ressenti
SPF fail + DKIM fail + DMARC fail : souvent spoof, ou un envoi légitime mal aligné (un outil qui n’est pas dans le SPF). SPF pass depuis une IP qui n’est pas à vous : include trop large, ou quelqu’un autorisé à parler en votre nom. DKIM pass avec un sélecteur que vous ne connaissez pas : lisez l’article DKIM.
On ne forme pas ici à forger des messages. On lit ce que le client a reçu. Si vous ne lisez pas les en-têtes, un prestataire mail ou nous sur le volet technique du site — le mail parfois s’arrête à « coupez le script ».
Les rapports DMARC RUA aident à voir les IP. Gardez-les deux semaines.
SPF, DKIM, DMARC : l’ordre pendant l’incident
D’abord : couper un envoi réel (script, SMTP CMS, compte messagerie). Ensuite : inventaire des includes SPF (site, ESP, OVH mail). DKIM des envois légitimes qui doivent encore partir (devis). DMARC en none ou quarantine tant que l’inventaire n’est pas stable. Reject quand les mails métier passent les contrôles.
Inverser (reject le soir du kit) : vos devis, vos reset de mot de passe, vos confirmations de RDV tombent. Le client Apple n’a plus le phishing ? Peut-être. Il n’a plus votre facture non plus.
Les FAI français ont leurs listes en plus (Orange SFR Free). DMARC n’est pas un recours Orange.
Reject trop tôt : vos devis dans le vide
Un prestataire « sécurité mail » pousse p=reject en une heure. Sur une PME avec Brevo + o2switch + une imprimante qui scan-to-mail, c’est un carnage. Deux temps : couper l’abus, aligner les envois connus, puis durcir.
Annoncez en interne : les devis passent par tel canal cette semaine (PDF au téléphone, autre From temporaire seulement si vous savez ce que vous faites — changer de From toutes les heures est pire).
Le transactionnel séparé (newsletter vs transactionnel) rend le reject moins dangereux : on durcit d’abord le sous-domaine brûlé.
Les pages de phishing sur votre domaine
Le mail Apple pointe souvent vers une URL chez vous. Alors ce n’est plus seulement du spoof : c’est du phishing hébergé. 410, pas redirect home. Chrome trompeur en plus du mail.
Coupez l’URL avant de polir DMARC. Le client qui clique encore sur un vieux message doit tomber sur une ressource morte.
Usurpation pure (lien vers un .ru) : DMARC + comm. Pas de 410 chez vous, sauf si vous avez aussi un kit.
Prévenir les clients Apple (et les autres)
Un SMS / un mail depuis un canal qui passe encore (LinkedIn, téléphone) : nous n’envoyons pas de lien de « mise à jour de compte », vérifiez l’URL, effacez. Pas de PDF « cliquez ici pour vérifier ».
Les clients Apple sont sensibles aux mails « iCloud / Apple ID » à votre nom (mélange). Dites clairement que vous n’êtes pas Apple.
Si des identifiants ont pu être saisis sur votre kit : fuite selon constat.
Après : reject, puis surveillance
Quand RUA montre surtout de l’abus tiers et que vos IP légitimes passent : p=reject. Surveillez les bounces métier une semaine.
Trente jours : un nouveau pic spoof est normal (les listes d’adresses circulent). Reject tient. Un pic d’envoi réel : script revenu, journal.
Créer un espace pour le site / le script. Un infogérant mail pour DMARC si votre zone est un plat de nouilles. Guide emails.