web-dev-qa-db-fra.com

Comment envoyer des e-mails et éviter qu'ils soient classés comme spam?

Il s'agit d'une question canonique sur la façon de gérer les e-mails envoyés à partir de votre serveur qui sont mal classés comme spam. Pour plus d'informations, vous trouverez peut-être ces questions similaires utiles:

Parfois, je veux envoyer des newsletters à mes clients. Le problème est que certains des e-mails sont pris comme des spams. Surtout par Outlook chez le client (même dans mon propre Outlook 2007).

Maintenant, je veux savoir ce qui devrait être fait pour créer de "bons" courriels. Je connais la recherche inversée, etc., mais (par exemple), qu'en est-il d'un lien de désabonnement avec un identifiant unique? Est-ce que cela augmente la cote de spam?

emailspamspam-filter
84
kcode

Assurez-vous que vos e-mails ne ressemblent pas à des e-mails de spam typiques: n'insérez pas uniquement une grande image; vérifiez que le jeu de caractères est correctement défini; n'insérez pas de liens "adresse IP uniquement". Écrivez votre communication comme vous le feriez pour un e-mail normal. Facilitez-vous vraiment la désinscription ou la désinscription. Sinon, vos utilisateurs se désinscrireont en appuyant sur le bouton "spam", ce qui affectera votre réputation.

Sur le plan technique: si vous pouvez choisir votre serveur SMTP, assurez-vous qu'il s'agit d'un serveur SMTP "propre". Les adresses IP des serveurs SMTP de spam sont souvent mises sur liste noire par d'autres fournisseurs. Si vous ne connaissez pas vos serveurs SMTP à l'avance, il est recommandé de fournir des options de configuration dans votre application pour contrôler la taille des lots et le délai entre les lots. Certains serveurs de messagerie n'acceptent pas les lots d'envoi volumineux ou l'activité continue.

Utilisez des méthodes d'authentification des e-mails, telles que SPF et Clés de domaine pour prouver que vos e-mails et votre nom de domaine appartiennent ensemble. L'effet secondaire Nice est que vous aidez à empêcher que votre domaine de messagerie soit usurpé. Aussi cochez votre DNS inversé pour vous assurer que l'adresse IP de votre serveur de messagerie pointe vers le nom de domaine que vous utilisez pour envoyer du courrier.

Assurez-vous que l'adresse de réponse de vos e-mails est une adresse existante valide. Utilisez le vrai nom complet du destinataire dans le champ À, pas seulement l'adresse e-mail (par exemple "John Doe" <[email protected]>) et surveillez vos comptes d'abus, tels que [email protected] et [email protected] .

83
splattne

Désabonnez automatiquement les destinataires de votre message dont les adresses e-mail rebondissent et établissez des boucles de retour d'informations avec les principaux fournisseurs de messagerie et désabonnez automatiquement les destinataires qui signalent votre message comme spam/courrier indésirable. Cela contribuera grandement à améliorer votre réputation et votre délivrabilité.

22
wg

Cette question mentionne que les bases sont en place, mais comme nous en signalons d'autres comme une question canonique, je veux juste être sûr que nous couvrons nos bases.

Ces minimums sont essentiellement requis de nos jours:

  1. Assurez-vous que les DNS avant et arrière sont correctement configurés. Un serveur de messagerie doit s'identifier dans un échange HELO/EHLO, ce nom doit rechercher l'IP que le serveur utilise. De même, la recherche inversée de cette IP doit retourner le nom.

  2. Assurez-vous que votre serveur envoie réellement le nom d'hôte dans cette poignée de main. Votre serveur ne doit pas envoyer d'adresse IP.

  3. Assurez-vous que votre adresse IP ne figure sur aucune DNSRBL (listes noires). Si c'est le cas, prenez-en soin.

  4. Vérifiez la réputation de votre IP avec les services de réputation les plus populaires (SenderScore est un gros problème en ce moment, mais cela pourrait ne pas durer avec le temps). Ces services ont généralement des directives pour améliorer votre réputation, mais ne sont pas un "go/no-go" pur et simple comme les RBL.

  5. Ne faussez pas les en-têtes, ne mentez pas dans les en-têtes et assurez-vous d'inclure le minimum d'en-têtes dans les messages (Date et From sont requis, il devrait y avoir un Subject, Sender, Reply-To et To/Cc/Bcc [le cas échéant]). Il s'agit de l'un de mes plus gros peves avec des newsletters valides que je souhaite recevoir se retrouvant dans Junk car ils simulent un en-tête Outlook Express, omettent la date ou quelque chose de similaire.

Vous pouvez éventuellement envisager de configurer SPF, DKIM et DMARC. Ceux-ci contribuent à la délivrabilité, mais ne sont pas requis (pas par la grande majorité des serveurs de messagerie).

15
Chris S

Malheureusement, il existe de nombreuses techniques de filtrage différentes et certains grands fournisseurs de messagerie ne publieront pas ce qu'ils utilisent et/ou quels poids sont accordés à divers tests/filtres, il est donc difficile de savoir comment passer. Fondamentalement, le spam a conduit les FAI et les utilisateurs dans une situation où il est parfois difficile de faire passer ces messages légitimes (en particulier les messages en masse tels que votre newsletter). Je ne considère plus le courrier électronique comme le moyen de transport à mi-chemin qu'il était autrefois.

Pour être un peu moins négatif et plus utile ... Comme vous rencontrez des problèmes spécifiques avec un client particulier, le programme peut vous révéler certaines choses. Je ne connais pas spécifiquement Outlook car je ne l'utilise nulle part moi-même, mais de nombreux filtres de messagerie injectent des en-têtes dans les messages pour répertorier les filtres utilisés, le résultat et la pondération attribuée à ce filtre. Donc, si vous regardez la source complète des messages qu'ils ont déplacés vers des dossiers indésirables, vous pouvez trouver des indices utiles. Par exemple, les filtres basés sur SpamAssassin injectent des en-têtes de la forme suivante:

X-Spam-Flag: YES
X-Spam-Score: 13.371
X-Spam-Level: *************
X-Spam-Status: Yes, score=13.371 tagged_above=-10 required=5.4
    tests=[BAYES_99=3.5, FB_GET_MEDS=0.803, RCVD_IN_SORBS_WEB=0.619,
    RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=1.86,
    URIBL_BLACK=1.955, URIBL_JP_SURBL=1.501]

(cet exemple a été extrait d'un véritable spam dans ma pile de courrier indésirable)

Ce n'est pas certain, car le filtrage bayésien et d'autres méthodes qui impliquent la formation des utilisateurs sont courants - donc ce que vos filtres réussissent et échouent peut différer sensiblement de ceux des autres, même si le client a été configuré de manière identique dès le départ. Vous devrez peut-être envisager un autre débouché pour vos nouvelles (de nombreuses personnes essaient d'utiliser des protocoles de réseautage social pour cela, avec différents degrés de succès).

11
David Spillett

Comme d'autres l'ont dit, vous voulez éviter de "ressembler" à un spam lors de l'envoi de l'e-mail, mais vous ne pouvez pas nécessairement dire ce qui vous fera ou ne ressemblera pas à du spam car les techniques varient.

Une chose que vous voudrez peut-être envisager est d'envoyer un e-mail en texte brut à vos clients pour chaque newsletter qui contient en fait une description/message d'accueil rapide suivi d'un "cliquez ici pour consulter notre dernière newsletter!" message; De cette façon, vous pouvez héberger votre message sur un serveur Web, vous réduisez la taille des e-mails (et chargez-les sur votre serveur de messagerie) et en prime, vous pouvez consulter les journaux sur votre serveur Web pour obtenir des commentaires sur le nombre de clients. lire vos messages ou les supprimer.

9
Bart Silverstrim

Solution détaillée pour éviter que les e-mails soient identifiés comme spam et/ou ne parviennent pas aux destinataires

Exemple de situation: vous disposez d'un serveur exécutant un site Web PHP pour example.com Qui doit envoyer des e-mails Et vous remarquez que vos e-mails ne sont pas toujours envoyés (gros problème si vous êtes propriétaire d'un magasin et que les clients ne reçoivent pas les e-mails après un achat!).

Si vous suivez toutes les étapes suivantes, cela devrait résoudre 99,9% des problèmes. (J'ai d'abord pensé qu'il était possible de n'en faire que quelques-uns, et de sauter DKIM par exemple, mais finalement tous étaient nécessaires pour résoudre tous les problèmes que j'avais).

  1. Tout d'abord, qui envoie des e-mails?

    Lorsque votre code PHP envoie des emails, c'est souvent avec la fameuse PHP fonction mail(...). Mais que fait cette fonction, sous le capot) ? Lançons une page test.php Contenant <?php echo ini_get('sendmail_path'); ?>. Vous obtiendrez par exemple: /usr/sbin/sendmail -t -i. Bonne nouvelle, nous savons maintenant quel programme gère vraiment les emails!
    Maintenant une info délicate: le nom sendmail peut être divers programmes . Même si vous voyez sendmail à l'étape précédente, vous pourriez avoir sendmail ou postfix ou exim , ou qmail, etc. installée. Faisons dpkg -S /usr/sbin/sendmail. La réponse est postfix: /usr/sbin/sendmail, Ok cela signifie que nous avons postfix installé .

  2. Regardez dans le fichier journal /var/mail/www-data Pour savoir quels courriels n'ont pas été correctement envoyés et pourquoi. Cela pourrait être utile pour les prochaines étapes.

  3. Comme mentionné sur le blog de Jeff Atwood , il est temps de regarder les enregistrements PTR inversés. (Plus de détails à ajouter ici).

  4. Ajoutez la ligne suivante dans le fichier de configuration postfixe /etc/postfix/main.cf:

    inet_protocols=ipv4

    Redémarrez ensuite postfix avec service restart postfix. Pourquoi? Parce que j'ai eu des problèmes comme ça quand le destinataire est gmail:

    Notre système a détecté que ce message ne répond pas aux directives d'envoi IPv6 550-5.7.1 concernant les enregistrements PTR et l'authentification 550-5.7.1. Veuillez consulter 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error pour plus d'informations sur 550 5.7.1.

    La solution la plus simple consistait alors à passer de postfix à ipv4 uniquement, d'où cette étape 4 (qui pourrait vous être inutile?).

  5. Enregistrements DNS SPF . Afin de prouver que vous êtes autorisé à envoyer des e-mails à partir de @example.com, Vous pouvez ajouter un enregistrement SPF dans les enregistrements DNS du domaine example.com. J'ai trouvé quelque part que The DNS record type 99 (SPF) has been deprecated, nous utilisons donc un enregistrement TXT à la place. Ajoutons cela comme un enregistrement TXT DNS) (voir aussi note 1):

    v=spf1 a mx include:_spf.google.com include:sendgrid.net ~all

    Pourquoi cela inclut-il? Parce que mon serveur ne sera pas le seul à envoyer des emails depuis @ example.com! J'ai configuré Gmail pour Envoyer le courrier en tant que [email protected] ( voir la capture d'écran ici ), en utilisant le fournisseur SMTP de confiance Sendgrid . Si je n'ajoute pas ces include:, Gmail ne serait pas autorisé à envoyer des e-mails à partir de @example.com.

  6. [~ # ~] dkim [~ # ~] signature numérique. Comme mentionné ici , l'objectif de DKIM est de s'assurer que le contenu du courrier n'a pas été altéré pendant la transmission. Voici le processus d'installation dans Ubuntu (guide utile ici aussi):

    • apt-get install opendkim opendkim-tools

    • Créez les clés (vous pouvez également générer des clés et le DNS approprié TXT enregistrement avec http://dkimcore.org/tools/ ):

      mkdir /etc/opendkim
cd /etc/opendkim
opendkim-genkey -t -s mail -d example.com

    • Mettons cela dans /etc/opendkim.conf:

      Syslog                 yes
Domain                 *
KeyFile                /etc/opendkim/mail.private
Selector               mail
AutoRestart            yes
Background             yes
Canonicalization       relaxed/relaxed
DNSTimeout             5
Mode                   sv
SubDomains             no

      ceci dans /etc/default/opendkim:

      SOCKET="inet:8891@localhost" # Ubuntu default - listen on loopback on port 8891

      et enfin ajoutez ceci à la fin du fichier de configuration de postfix /etc/postfix/main.cf:

      # DKIM
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

    • Ajoutons maintenant la clé publique (trouvée dans /etc/opendkim/mail.txt) Aux enregistrements DNS de votre domaine:

      mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=OqYHd...waPaQAX"

      Voici à quoi cela ressemble avec mon registraire Namelynx:

    • Dernière étape pour DKIM: redémarrez les services de messagerie avec service restart opendkim ; service restart postfix.

  7. Testez si tout fonctionne. La méthode la plus simple consiste à envoyer un e-mail via PHP to [email protected] ( cet outil très utile est mis à disposition par Port25 Solutions):

    $emailfrom = "Example <[email protected]>";
$headers  = "MIME-Version: 1.0 \n";
$headers .= "Content-Transfer-Encoding: 8bit \n";
$headers .= "Content-type: text/plain; charset=utf-8\n";
$headers .= "Reply-To: " . $emailfrom . "\n";
$headers .= "From: " . $emailfrom . "\n";
$headers .= "Bcc: [email protected]\n";
mail("[email protected]", "Hello", "Hello!", $headers);

    Ensuite, voyez la réponse de cet outil, il devrait ressembler à ceci:

    ==========================================================
Summary of Results
==========================================================
SPF check:          pass
DKIM check:         pass
SpamAssassin check: ham

    Le service mail-tester.com est également utile.

  8. (Facultatif) Essayez postmaster.google.com. Je l'ai utilisé mais je ne me souviens pas si cela a aidé ou non.

  9. Si cela ne fonctionne toujours pas , une solution pourrait être d'externaliser le courrier électronique avec une solution professionnelle, pour éviter des jours et des nuits de débogage (infructueux). Ici est un bon article à ce sujet. Voici une citation: "L'envoi d'e-mails à partir de votre application peut s ***. La moitié du temps, les messages qui sont envoyés à partir de votre propre serveur sont simplement vidés dans le dossier indésirable du destinataire." que je malheureusement découvert vrai, après des semaines de peaufinage.

Notes complémentaires:

(1)

-all : Fail: All mail servers not listed in the SPF record are explicitly not authorized to send mail using the sender’s domain.
~all : Soft Fail: All mail servers not listed in the SPF record are not authorized to send mail using the sender’s domain, but the owner of the domain is unwilling to make a strong assertion to that effect.
?all : Neutral: The domain controller cannot or does not want to assert whether or not all mail servers not listed in the SPF record are authorized to send mail using the sender’s domain.
+all : Pass: All mail servers are authorized to send mail on behalf of the sender’s domain.
7
Basj

Mon entreprise en ligne avait des problèmes avec les e-mails de confirmation de commande envoyés au spam ou même pas livrés (évités via les serveurs de messagerie). Il s'agissait de simples e-mails "voici un résumé de votre commande" avec un lien vers le domaine de notre site. Nous avons fini par acheter quelques comptes Google Apps pour mon entreprise. Vous pouvez configurer l'un d'entre eux pour agir comme votre serveur SMTP. Le fait d'avoir Google comme expéditeur de courrier a mis fin à tous ces problèmes.

En ce qui concerne les newsletters par e-mail, utilisez certainement un service qui gère l'opt-in /-out pour vous. Utiliser quelqu'un d'autre qu'un service pour envoyer du courrier en vrac vous fera probablement bannir.

6
Chris K

Un nouveau guide a été publié sur la boîte de réception par e-mail

Le plus complet que j'ai jamais vu. Une liste de contrôle de 43 points différents qui couvrent tous les robinets sur la façon d'éviter d'être marqué comme spam. C'est constamment mis à jour.

De la configuration du DNS, de la configuration de l'authentification, de la configuration de la surveillance de la réputation, de la réduction de votre taux de rebond, du test de votre contenu de messagerie, etc.

Couverture de la tête aux queues de tout par ZeroBounce.NET

https://www.zerobounce.net/guide-to-improve-inbox-and-delivery.html

1
Henry