Wird SPF für Domains benötigt, die keine E-Mails senden und keinen MX-Eintrag haben?


9

Ich habe einige Domains registriert, die keine Mails senden.

Ich habe den MX-Eintrag für diese Domains in meinem DNS vollständig entfernt .

Ist es immer noch nützlich, einen SPF-Eintrag festzulegen, um zu vermeiden, dass Spammer E-Mails als diese Domänen senden?

Ich habe hier gelesen , dass für Domains, die keine E-Mails senden, die SPF-Datensatzeinstellung immer lautet:

mydomain.it. TXT "v = spf1 -all"

Dies ist der einfachste SPF-Eintrag: Es bedeutet, dass Ihre Domain mydomain.it niemals E-Mails sendet.

Aber muss ich diese noch einstellen, da ich sogar den MX-Datensatz entfernt habe?

Ich befürchte, dass ein Spammer eine dieser Domänen (DomainA) verwendet und Spam sendet, da sich DomainA auf derselben IP-Adresse von DomainB befindet, auf der DO E- Mails sendet . Ich befürchte, ein ISP könnte Spam-Mails verbieten, die von einer solchen IP stammen und deshalb werden auch E-Mails, die auch von domainB kommen, gesperrt .

Vielen Dank!


Zu Ihrer Information: Ich verwende ein cPanel-Konto mit dedizierter IP-Adresse, um Domänen zu hosten, auf denen der Mailserver dieselbe dedizierte IP-Adresse verwendet


UPDATE: Aus den folgenden Antworten ging hervor, dass SPF für diesen speziellen Fall nicht benötigt wird, außer um dem Interventen zu helfen, eine gefälschte E-Mail-Adresse, die eine dieser Domänen verwendet, sofort als Spam zu erkennen. Aber niemand antwortete auf den letzten Teil meiner Frage.

  1. Spammer sendet eine E-Mail, die vorgibt, name@domainA.com zu sein
  2. domainA.com hat keinen MX-Eintrag
  3. ISP erkennt, dass name @ domainA Spam ist, verbietet der ISP die IP von domainA oder nur die domainA ???
  4. Wenn der ISP die IP von DomainA verbietet, wird die schlechte DomainB (mit MX-Eintrag), die DO sendet und sich auf derselben Server-IP befindet, ebenfalls gesperrt, nicht wahr ?

Sollte 4. jemals passieren, wäre es trivial, die Domains anderer Leute zu sperren. Das funktioniert nicht so.
James Ryan

4 ist genau so, wie das Internet funktioniert. Sie sollten sicherstellen, dass Sie nicht dieselbe IP-Adresse mit einem Spammer oder sogar dasselbe Subnetz teilen. Sehr oft wird das gesamte Subnetz von Spamhaus aufgelistet, wenn das Webhosting nicht proaktiv ist. Umstritten und doch sehr effektiv. Aus diesem Grund ist die Auswahl eines seriösen und proaktiven gemeinsam genutzten Hosts wichtig.
Henry Chan

Antworten:


12

Es sind KEINE SPF-Einträge erforderlich, wenn Ihre Domain keine E-Mails sendet

Um jedoch das Risiko zu verringern, dass Spam-Mails von dieser Domain kommen, wird der SPF-Datensatz von festgelegt

"v=spf1 -all"

ist gut, damit SPF-Überprüfungsserver dies sehen und E-Mails von dieser Domain automatisch ablehnen


8

Sie müssen nicht unbedingt brauchen keine SPF - Einträge überhaupt zu veröffentlichen, es ist ein freiwilliges System.

Wenn Sie jedoch einen SPF-Datensatz veröffentlichen, können Sie:

  • Helfen Sie dem Internet insgesamt ein kleines bisschen, weil es Spammern eine Domain weniger zum Parodieren gibt. (Grenznutzen, aber ...)
  • Helfen Sie dabei, den Ruf Ihrer Domain zu erhalten, indem Sie die Wahrscheinlichkeit verringern, dass sie durch Spam gefälscht wird.
  • Zeigen Sie proaktiv, dass Ihre Domain nicht an einem Hack ohne MX-Datensatz beteiligt ist und dennoch (möglicherweise aus Versehen) E-Mails sendet.

Update nach OP-Update: OK, also zunächst einmal klingt es ein bisschen falsch, dass es "viele" Domains auf dieser IP gibt und das Hinzufügen von SPF für alle schwierig ist - Sie sollten keine Domains haben, die Sie nicht zumutbar benötigen zum.

In Bezug auf das Blacklisting: Im Allgemeinen werden die meisten IPs niemanden für "kleinere" Spam-Volumes auf die Blacklist setzen. Es gibt keine Möglichkeit zu sagen, nach welchen Kriterien ein ISP auf die schwarze Liste gesetzt werden könnte, da es viele verschiedene ISPs gibt und jeder zu seiner eigenen Meinung berechtigt ist. Das heißt, wenn es darum ging, für Sie auf die schwarze Liste zu setzen (unwahrscheinlich), dann sind die wahrscheinlichsten Ziele MX-Einträge und Bereiche von IP-Adressen.


SPF-Datensatz ist nicht vorhanden, nicht wahr, ich würde nichts brauchen, um den Datensatz hinzuzufügen mydomain.it. TXT "v=spf1 -all", da ich viele Domänen habe. Gute Idee zur Wahrung der Domain-Reputation, aber was ist mit anderen Domains mit derselben IP? (Bitte siehe meine Frage Update).
Marco Demaio

@ Jasper Mrtensen: Danke für das Update, was Sie sagen, you shouldn't have domains you don't have a reasonable need forich brauche diese Domains, weil ich Kunden habe, die sie wollen.
Marco Demaio

6

Wenn Sie nicht beabsichtigen, E-Mails von dieser Domain aus zu senden, lassen Sie sie dann von anderen Personen nach Belieben verwenden. Aber die Dinge haben sich geändert, seit diese Frage vor acht Jahren gestellt wurde. SPF kann Ihre Domain nur vor der Verwendung als Umschlagsender schützenFrom: , SPF kann den Header jedoch nicht schützen .

Ich würde noch weiter gehen, indem ich eine DMARC-Ausrichtung hinzufüge.

@       IN      TXT     "v=spf1 -all"
_dmarc  IN      TXT     "v=DMARC1; p=reject; aspf=s; adkim=s;"

Alle Subdomains erben die DMARC-Richtlinie, SPF wird jedoch nicht von den Subdomains geerbt. Daher müssen Sie für jeden ADatensatz, den Sie haben, auch einen entsprechenden SPF-Datensatz hinzufügen .

Es ist nicht erforderlich, DKIM-Datensätze zu veröffentlichen, da ohnehin niemand die Nachrichten signiert.

Ich habe das nicht hinzugefügt rua=und ruf=weil in dieser Situation keine Fehlalarme behoben werden sollten. Wenn Sie neugierig genug sind, Daten darüber zu sammeln, wie oft diese Domain für Spoofing verwendet wird, können Sie z

rua=mailto:dmarc-report@example.com; ruf=mailto:dmarc-report@example.com; fo=0:d;

5

Sie können diese SPF-Einträge hinzufügen, um einige Ihrer Bedenken zu vermeiden. SPF ist immer optional, aber nett zu tun.

AKTUALISIEREN

Was den zweiten Teil Ihrer Frage betrifft, scheint es wirklich darum zu gehen, wie E-Mails funktionieren und wie "Verbot" funktioniert.

  1. OK
  2. OK
  3. Es prallt die Nachricht ab. Das ist anders als ein Verbot. Es gibt einen separaten Prozess, der dazu führen kann, dass die fehlerhafte IP-Adresse, nicht von domainA, sondern die Netzwerk-IP-Adresse des Absenders und möglicherweise IP-Adressen auch im selben Netzwerk, in einer Blacklist aufgeführt wird.
  4. Siehe oben.

Das Verbot erfolgt nicht nur nach Domain. Vielmehr ist das beleidigende Netzwerk der Ort, an dem die Schlacht am häufigsten ausgetragen wird. Es handelt sich im Allgemeinen um einen DNS-Mechanismus, es gibt jedoch auch andere Methoden.

Ihre Angst, legitime E-Mails von einer anderen Domain zu beeinflussen, hängt wirklich davon ab, wie sich dieses IP-Netzwerk verhält und ob es im Allgemeinen Spam ist oder nicht. Sogar ein Verbot ist normalerweise eine vorübergehende Sache. Sie werden auf eine schwarze Liste gesetzt und sie werden schließlich entfernt.

Bleiben Sie über alle Missbrauchs-E-Mails Ihres Internetdienstanbieters auf dem Laufenden. Dies ist ein Zeichen dafür, dass Sie jemand wegen Spam meldet und Sie möglicherweise Probleme haben.


Für viele Domains ist es zeitaufwändig.
Marco Demaio

1

Es wird empfohlen, auf jedem Host innerhalb einer Domain, die ansonsten keinen anderen SPF-Datensatz hat, einen SPF-Eintrag "dh sendet nicht" (dh "v = spf1 -all") zu haben - sowie für die Domain selbst plus alle Nicht-Host-Labels in der Domäne, die MX- oder SMTP-Service-SRV-Einträge enthalten. Die Idee ist, die Erkennung zu ermöglichen, dass der Host-Teil eines sendenden Postfachs gefälscht ist, und für diejenigen Idioten, die die SPF-Datensätze anderer nicht überprüfen, dass Sie alle möglichen Labels in Ihrer Domain geschützt haben, die Backscatter-Ziele sein könnten.

Ist es optional? Nicht wirklich, wenn Sie verhindern möchten, dass Ihre Domain (s) missbraucht werden.


0

Nein, du brauchst es nicht. Wenn Sie keinen SMTP-Server betreiben, kann kein Spammer Ihren Server kontaktieren. Sie können es jedoch verlassen, damit andere Ihre Domain-Einträge überprüfen können, wenn sie entscheiden, ob sie mit Spam umgehen.


Und was ist mit anderen Domänen, die E-Mails auf derselben Server-IP senden? (Bitte siehe meine Frage Update).
Marco Demaio

Um Ihren Ruf zu schützen, möchte ich daran erinnern, dass diese Meinung etwas veraltet ist. :)
Esa Jokinen

@ EsaJokinen: Sie haben wahrscheinlich Recht :)
Sven

Ich hatte "v=spf1 -all"+ DMARC "v=DMARC1; p=reject; aspf=s; adkim=s;"für Domains, die nur für einige Weiterleitungen oder statische Webseiten bestimmt waren und nie für E-Mails gedacht waren, und teilte dies hier als neue Antwort mit. (In meinen Setups gibt es MXServer, die normalerweise auf jede RCPT TOAdresse mit Ablehnung der Verbindungsphase antworten und die vom Menschen lesbare Meldung "Kontaktinformationen finden auf der Website" erhalten. Dies ist jedoch nur ein guter Kundenservice und zu weit von den Fragen entfernt. ))
Esa Jokinen

0

Wenn Sie Zeit haben, ist es am besten, SPF-Einträge in allen Ihren Domänen zu haben, auch wenn es sich nur um den Fail-All-Eintrag handelt. Wenn Sie dies nicht tun, fügen Sie einen SPF-Eintrag nur zu den Domänen hinzu, von denen Sie E-Mails senden.

Wenn ein Spammer Ihre Domain oder IP fälscht, hilft der SPF-Eintrag dabei, den Schaden zu minimieren - und das Signieren mit DKIM wäre noch besser -, aber es gibt derzeit nichts, was eine Schädigung Ihrer Domain-Reputation vollständig verhindern könnte. Sie müssen nur bereit sein, das Problem zu beheben, indem Sie sich an ISPs wenden, die möglicherweise Ihre E-Mails blockieren. Dies ist sehr unwahrscheinlich, es sei denn, jemand zielt speziell auf Sie ab. (Es gibt Lieferberater, die auch bei der Reparatur helfen können.)

Obwohl die Reputation von Domains immer wichtiger wird, blockieren viele ISPs E-Mails basierend auf IP-Adressen. Sie blockieren auch E-Mails mit Domains (nicht nur von, sondern haben die Domain irgendwo in der E-Mail) mit schlechtem Ruf. Die Antwort lautet also: Ja, wenn DomainA blockiert ist, kann sich dies auf DomainB auswirken, wenn sie über dieselbe IP-Adresse senden oder DomainA in E-Mails enthalten ist, die von DomainB gesendet werden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.