Comment est-il possible d'envoyer des e-mails sous notre nom de domaine

Les spammeurs ou quelqu'un envoient des e-mails en utilisant notre domaine.

Les e-mails proviennent d'un utilisateur que nous n'avons pas créé, appelé regeniaberry67a@ourdomain.com.au .
L'e-mail est à regeniaberry@ubtanet.com .
Le contenu de l'e-mail parle d'un stock qui est de 6 cents mais qui ira à 15 cents et que quelqu'un devrait l'acheter. Il contient un lien vers le site Web des finances de Yahoo, mais je ne cliquerai pas dessus, donc je ne sais pas si c'est légitime. Nous connaissons les e-mails parce que nous obtenons des rebonds (le destinataire ne doit pas exister).

Qu'est-ce qui pourrait permettre à quelqu'un / bot d'envoyer un e-mail sous notre nom de domaine? Y a-t-il quelque chose que nous puissions faire pour arrêter cela? Ce dictionnaire est-il un spam?

email domain spam-prevention

— sazr
source

What could allow a someone/bot to send an email under our domain name?- Google SPF, puis configurez-le. C'est à peu près tout ce que vous pouvez faire de façon réaliste.

— Zoredache

Un e-mail peut contenir n'importe quelle adresse de réponse que vous choisissez. Certains serveurs de messagerie renverront des notifications non livrables à l'adresse de réponse, plutôt qu'à l'expéditeur. Les gestionnaires de messagerie en ligne comme Gmail vous obligent à valider toute adresse de réponse que vous utilisez lors de la composition en ligne, mais il n'y a pas de telle restriction lors de l'utilisation d'un client distant avec POP3 / IMAP. Et si vous exécutez votre propre serveur de messagerie, vous pouvez probablement aussi simuler l'adresse de l'expéditeur.

— AFH

Comment les spammeurs usurpent votre adresse e-mail (et comment vous protéger)

— DavidPostill

Le protocole SMTP n'inclut aucun contrôle sur les champs From:et To:dans un e-mail. Ils peuvent être ce que vous voulez, à condition que vous ayez le pouvoir d'envoyer des e-mails à l'aide du serveur SMTP.

Donc, la réponse courte est que rien n'empêche quiconque d'utiliser votre domaine dans les e-mails qu'il envoie. Même les utilisateurs normaux peuvent mettre n'importe quelle adresse e-mail qu'ils souhaitent dans leurs paramètres de messagerie.

Les spammeurs utilisent régulièrement des noms de domaine valides comme adresses d'expéditeur pour éviter d'être bloqués.

Bien que vous ne puissiez pas empêcher quelqu'un d'envoyer des e-mails avec votre nom de domaine, vous pouvez aider les serveurs de messagerie du monde entier à comprendre si les e-mails envoyés à partir de votre nom de domaine proviennent réellement de vous et sont des e-mails légitimes, afin que tout autre puisse être rejeté comme spam.

SPF

Une façon consiste à utiliser SPF. Il s'agit d'un enregistrement qui va dans DNS et permet à Internet de savoir quels serveurs sont autorisés à envoyer des e-mails au nom de votre domaine. Cela ressemble à ceci:

ourdomain.com.au.  IN TXT "v=spf1 mx ip4:123.123.123.123 -all"

Cela signifie que les seules sources d'e-mails valides pour le ourdomain.com.ausont le serveur MX - le serveur défini comme le destinataire des e-mails pour le domaine, et un autre serveur au 123.123.123.123. Les e-mails provenant de tout autre serveur doivent être considérés comme du spam.

La plupart des serveurs de messagerie vérifieront la présence de cet enregistrement DNS et agiront en conséquence.

DKIM

Bien que SPF soit facile à configurer, DKIM demande un peu plus d'efforts et devrait être implémenté par l'administrateur de votre serveur de messagerie. Si vous envoyez votre e-mail via un serveur de messagerie ISP, ils auront souvent des méthodes pour une configuration rapide de DKIM.

DKIM fonctionne de manière similaire aux certificats SSL. Une paire de clés publique / privée est générée. La clé privée n'est connue que du serveur de messagerie et il signera tous les e-mails sortants.

La clé publique est publiée à l'aide de DNS. Ainsi, tout serveur recevant des e-mails marqués comme provenant de votre domaine peut vérifier que l'e-mail a été signé en récupérant la clé publique et en vérifiant la signature dans les e-mails. Si aucune signature n'est présente ou si elle est incorrecte, l'e-mail peut être considéré comme du spam.

— Paul
source

+1, sont-ils bien adoptés?

— chbaker0

Les principaux acteurs les ont utilisés - gmail, etc., ainsi que les principaux panneaux de contrôle comme cPanel. La plupart des serveurs de messagerie ont un moyen de les prendre en charge, donc la couverture nous fait généralement défaut car elle n'est pas mise en œuvre, plutôt que d'être indisponible.

— Paul

J'ai récemment implémenté le SPF et le DKIM, et ils semblent tous les deux fonctionner très bien. Ils ne sont pas magiques, c'est un peu comme robots.txt, Google le respecte, mais ce n'est pas obligatoire.

— Martijn

@Martijn Le choix de respecter ou non le SPF est du côté des récepteurs. Rien ne peut être fait si le destinataire souhaite recevoir du spam ... (Là encore, il existe des scénarios qui rendent l'implémentation de SPF un peu anodin, tels que les redirections internes et les serveurs de messagerie de secours: il faut s'assurer que seul le premier MTA recevant des chekcs SPF)

— Hagen von Eitzen

SPF semble être assez bien adopté à ce stade (il existe depuis longtemps, l'adoption a été un processus lent). DKIM semble être plus aléatoire.

— Brian Knoblauch