FAQ

Was ist DNS-Caching?

Beim DNS-Caching wird das Ergebnis einer rekursiven DNS-Namensauflösung für eine definierte Zeit im lokalen Cache (Auf dem PC, beim Einwahlprovider, …) gespeichert. Ziel ist es, weitere identische DNS-Anfragen sofort beantworten zu können, ohne erneut bei den zuständigen Nameservern anfragen zu müssen. Dies sorgt für eine Entlastung der zuständigen Nameserver sowie zu einer Zeitersparnis, da Anfragen schneller aus dem Cache heraus beantwortet werden. Wie lange das Caching erfolgen soll, wird durch den TTL-Wert (engl.: Time to live; dt.: Zeit zu leben) definiert. Festgelegt wird der TTL-Wert durch den autoritativen Nameserver der entsprechenden Zone, der die ursprüngliche Anfrage beantwortet hat.

Welcher TTL-Wert ist standardmäßig hinterlegt?

Die Masse aller Anbieter setzt – wie wir auch – standardmäßig einen TTL-Wert von 86400 Sekunden, was 24 Stunden entspricht. (86.400 Sekunden : 60 Sekunden =  1.440 Minuten : 60 Minuten = 24 Stunden)

Macht es Sinn, einen geringeren TTL-Wert zu hinterlegen?

Ein geringerer TTL-Wert wie z.B. 300 Sekunden (5 Minuten) ist in folgenden Situationen sinnvoll:

• Die Ziele für eine Domain/Subdomain ändern sich in Kürze z.B. beim Wechsel des Servers/Anbieters
• Es werden oft Änderungen an Zielen vorgenommen

Wann wirken sich Änderungen an der DNS-Zone/TTL aus?

Änderungen an einer DNS-Zone (inkl. TTL) wirken sich i.d.R. spätestens nach dem Ablauf der bisherigen TTL aus. Einen genauen Zeitpunkt kann man nicht definieren, da z.B. Einwahlprovider zu einem unterschiedlichen Zeitpunkt die Informationen in ihrem Cache aufnehmen.

Sofern es planbare Änderungen an einer DNS-Zone gibt, empfehlen wir, mindestens 24-48 Stunden vor den geplanten Änderungen die TTL der DNS-Zone auf 5 Minuten zu senken.

Welche Vorteile bietet das DNS-Caching?

DNS-Caching erhöht die Ausfallsicherheit im Domain Name System (DNS). Würden DNS-Zonen nicht gecached werden und der zuständige DNS wäre einmal kurzzeitig nicht erreichbar, könnte das Ziel der Domain nicht mehr aufgelöst werden. Fazit: die Domain wäre ebenfalls nicht mehr erreichbar.

Zusätzlich erspart das Caching von DNS-Information für den Zeitraum der TTL überflüssige Anfragen an die zuständigen DNS.

Welche Nachteile hat DNS-Caching?

Rufen Sie eine Domain auf, ist die Domain (wie oben beschrieben) für den Zeitraum der TTL im DNS-Cache Ihres Einwahlproviders und evtl. zusätzlich auf Ihrem lokalen Rechner gecached. Nehmen Sie nun kurze Zeit später eine Änderung an der DNS-Zone vor, „erfährt“ der Cache-DNS Ihres Einwahlproviders von dieser Änderung nichts. Der Cache-DNS geht nach wie vor davon aus, dass die vorliegende Routinginformation gem. der TTL für 24 Stunden gültig ist.

Sie werden somit für den Zeitraum der TTL, in der Regel also für 24 Stunden, weiterhin auf das alte bisherige Ziel der Domain geleitet. Erst nach Ablauf der TTL wird der Cache-DNS Ihres Einwahlproviders den zuständigen DNS erneut fragen und die geänderte Routing-Information erhalten.

Kann ich meinen lokalen DNS-Auflösungscache leeren?

Ja. Unter Windows-Systemen starten Sie das Programm/die App „Eingabeaufforderung“ und geben Sie den Befehl ipconfig /flushdns ein.

C:\Dokumente und Einstellungen\Benutzer>ipconfig /flushdns
Windows-IP-Konfiguration
Der DNS-Auflösungscache wurde geleert.

Wenn eine E-Mail nicht ordnungsgemäß zugestellt werden kann, nennt der betreffende Mail-Server den Grund dafür in einer Fehlermeldung. Hier möchten wir einige dieser Meldungen erklären.

Temporär – beim Empfang

Wenn beim Versand ein temporärer Fehler zurückgegeben wird, kann die Gegenstelle die Zustellung erneut versuchen, solange kein Timeout erreicht wird.

• 4.1.8 <*@*.*>: Sender address rejected: Domain not found
  Die Domain der Absenderadresse existiert nicht oder wird vorübergehend nicht im DNS gefunden. Möglicherweise wurde kürzlich eine Änderung am DNS der Domain vorgenommen, welche noch nicht vollständig propagiert wurden.
  
  
• 4.5.3 Error: too many recipients
  Du verschickst eine E-Mail an mehr als 300 Empfänger (To, Cc, Bcc).
  
  
• 4.7.1 Docking request denied, first time visit, you have been greylisted, try again later
  Der sendende Server ist uns unbekannt. Da er das erste Mal an uns sendet, wird die Nachricht zunächst abgelehnt. Erst beim erneuten Versuch nach ca. 5 Minuten wird die Nachricht zugestellt. Dies ist eine Spamschutz-Maßnahme.
  
  
• 4.7.25 Client host rejected: cannot find your hostname, [192.168.1.1]
  Eine korrekte Konfiguration erwartet, dass ein PTR-Record des einliefernden Mail-Servers im A-Record wiederum auf dieselbe IP-Adresse verweist. Hier ist das aktuell nicht der Fall und der Betreiber des Mail-Servers ist zu kontaktieren.

Permanent – beim Empfang

Sollte beim Empfang einer E-Mail auf unserem Mail-System eine der permanenten Fehlermeldungenzurück an den Sender gehen, wird in der Regel keine erneute Zustellung versucht, bevor der Grund für diese behoben ist.

• 5.1.1 <*@*.*>: Recipient address rejected: User unknown in virtual alias table
  Die E-Mail-Adresse existiert nicht oder es ist ein Tippfehler vorhanden. Eine weitere mögliche Ursache hierfür sind aktive E-Mail-Adressen bei uns, deren Domain (nach dem @) jedoch einen fremden MX-Record trägt. Die Lösung ist das Löschen aller E-Mail-Adressen (Postfächer dürfen bestehen bleiben) dieser betroffenen Domain.
  
  
• 5.2.2 No space left in mailbox / Der Speicherplatz des Postfachs ist vollständig belegt
  Diese Meldung bedeutet, dass der Postfach-Speicherplatz erweitert werden muss, um weitere E-Mails zu empfangen. Parallel erhält bei uns das betroffene Postfach eine Meldung im Posteingang: Mail quota warning
  
  
• 5.3.4 Message size exceeds fixed limit
  Die Größe der E-Mail liegt über dem Limit von 50 MB. Lies hier mehr darüber.
  
  
• 5.5.2 <*@*>: Sender address rejected: need fully-qualified address
  Bei der E-Mail-Adresse des Absenders ist keine Top-Level-Domain angegeben, es fehlt also ein „.de“ oder „.com“.
  
  
• 5.7.1 <*@*.*>: Relay access denied
  Obwohl die MX-Records der Domain auf power-netz.com zeigen, ist hier aber keine E-Mail-Adresse angelegt.
  
  
• 5.7.1 Spam message rejected
  Eine eingehende E-Mail wird vom Server als Spam abgewiesen.
  
  
• 5.7.27 <*@*.*>: Sender address rejected: Domain example.com does not accept mail (nullMX)
  Ein „Null MX“-Record? untersagt den Versand und Empfang von E-Mails für eine bestimmte Domain (im Beispiel example.com).

Permanent – beim Versand

Auch beim Versand von E-Mails können permanente Fehler zurückgegeben werden. Bevor ein solcher behoben ist, wird kein erneuter Versand möglich sein.

• 5.1.2 <*@*.*>: Recipient address rejected: Domain not found
  Die Domain der Empfängeradresse existiert nicht oder das DNS derselben Domain ist nicht erreichbar.
  
  
• 5.1.8 <*@*.*>: Sender address rejected: Domain not found
  Die Domain der Absenderadresse existiert nicht oder das DNS derselben Domain ist nicht erreichbar.
  
  
• 5.1.10 <*@example.com>: Recipient address rejected: Domain example.com does not accept mail (nullMX)
  Ein „Null MX“-Record? untersagt den Versand und Empfang von E-Mails für eine bestimmte Domain (im Beispiel example.com).
  
  
• 5.5.2 <*@*.*>: Recipient address rejected: need fully-qualified address
  Bei der E-Mail-Adresse des Empfängers ist keine Top-Level-Domain angegeben, es fehlt also ein „.de“ oder „.com“.
  
  
• 5.5.3 <DATA>: Data command rejected: Multi-recipient bounce
  Es wird versucht eine Bounce-Nachricht zu versenden, die mehrere Empfänger enthält. Dabei darf es aber nur einen Empfänger geben.
  
  
• 5.5.4 Unsupported option: SMTPUF8
  Es sind nicht unterstützte Sonderzeichen (wie ä, ö, ü, ß) in der E-Mail-Adresse des Empfängers vorhanden.
  
  
• 5.7.1 Spam message rejected
  Eine ausgehende E-Mail wird vom Server als Spam abgewiesen.
  
  
• 5.7.1 Matched map: SPAMTRAP_BLACKLIST
  Es wird versucht an eine E-Mail-Adresse zu senden, die zwar gültig ist, aber als reine E-Mail-Falle gilt, um Spammer zu identifizieren.
  
  
• 5.7.1 <unknown[192.168.1.1]>: Client host rejected: Bitte nutzen Sie SMTP-Authentifizierung mit Username und Passwort
  Zum E-Mail-Versand sind Benutzername und Passwort notwendig, die sogenannte SMTP-Authentifizierung. Bitte trage diese in deinem E-Mail-Client ein.
  
  
• 5.7.1 <DATA>: Data command rejected: limit of 400 rcpts per 24 hours for client pxxxxxpx reached
  Das Standard-Limit von 400 E-Mails für 24 Stunden ist für den Versand erreicht. Erfahre hier mehr darüber.
  
  
• 5.7.1 <*@*.*>: Recipient address rejected: Domain MX in loopback/ broadcast/ RFC 1918 private network
  Der MX-Record der Domain der Empfänger-Adresse ist auf verschiedene Arten ungültig. Den korrekten MX-Record verkündet stets der E-Mail-Provider.

Bei allen drei Begriffen handelt es sich um Protokolle, mit denen E-Mail-Versand ermöglicht wird. Kurz gesagt: Per SMTP (Simple Mail Transfer Protocol) versendest du E-Mails – per IMAP (Internet Message Access Protocol) und POP3 (Post Office Protocol Version 3) rufst du sie vom Server ab. Aber was ist der Unterschied zwischen IMAP und POP3 und warum ist IMAP meistens die bessere Wahl?

IMAP

IMAP synchronisiert deine E-Mails zwischen Server und den E-Mail-Programmen deines Computers, Tablets oder Smartphones.
So kannst du deine E-Mails überall lesen, bearbeiten oder löschen. Egal, auf welchem Gerät und wer es benutzt: Du bist dann immer auf dem gleichen Stand wie die anderen Geräte. Die Referenz, also was „auf dem Server“ in deinem Postfach liegt und synchronisiert werden kann, bekommst du im webmail zu sehen.

POP3

Mit POP3 lädst du E-Mails nur herunter. Deine E-Mails laden sich als Kopie vom Server auf deinen Computer, dein Tablet oder Smartphone. Dort kannst du diese dann lesen, beantworten oder löschen – aber nur lokal.
POP3 stammt aus der Zeit, wo Server-Speicherplatz knapp war und so werden E-Mail klassischerweise nach einer bestimmten Zeit auf dem Server gelöscht.

Die Nachteile von POP3: Deine anderen Geräte und auch der Server erfahren nichts von diesen Änderungen und unsere Server-Backups umfassen einzig den aktuellen Stand der E-Mails, die noch nicht gelöscht wurden. Auch gesendete E-Mails befinden sich nicht auf dem Server, sondern nur in deinem Client.

Registriert ein Kunde bei Power-Netz eine Domain, so sind wir per Gesetz verpflichtet, diese Angaben zur Registrierung bei der offiziellen Registrierungsstelle (Registry) zu hinterlegen. Diese speichern die Daten in den sogenannten „Whois“-Datenbanken für die jeweilige Domain ab. Die Registrierungsstelle weiß somit, wem welche Domain gehört. Somit wäre es für die Registrierungsstelle jederzeit möglich, sich mit dem Inhaber einer Domain in Verbindung zu setzen.

Aufgrund der Datenschutzgrundverordnung (DSGVO) sind die Whois-Datenbanken i.d.R. nicht mehr öffentlich einsehbar. Jedoch bieten einige Vergabestelle die Veröffentlichung der Daten an. Standardmäßig verbieten wir die Anzeige der Daten im öffentlichen Whois – sofern dies möglich ist- um Ihre Daten zu schützen.

Wir nutzen diese Daten nur zur Vertragserfüllung. Darüber hinaus werden die Daten nicht an Dritte weitergeleitet.

Täglich landen viele E-Mails in dem Posteingang eines E-Mail Kontos. Neben normalen E-Mails und nervigen Spam E-Mails können auch Phishing E-Mails dabei sein. Diese können potentiell sehr gefährlich sein – wenn man nicht richtig aufpasst.

Was ist Phishing?

Unter Phishing (von engl. fishing = angeln) versteht man gefälschte E-Mails bzw. gefälschte Webseiten über die versucht wird, an vertrauliche Daten wie z.B. Kennwörter oder Bankverbindungen zu kommen.

Häufig werden hier z.B. Banken wie die Sparkasse, die Volksbank oder andere große Banken nachgeahmt. In den Mails geht es dann z.B. darum, dass sich ein Prozess / ein Verfahren geändert hat und dass der Empfänger seine Bankdaten aktualisieren soll.

Nachfolgend sehen Sie ein Beispiel einer solchen E-Mail:

Woran erkenne ich Phishing E-Mails?

Ein sehr häufiges Indiz für eine Phishing E-Mail ist der Link, der zu einem Button in der Mail hinterlegt ist. Hierbei handelt es sich in der Regel um kryptische Links, welche Sie auf eine nachgeahmte Webseite weiterleiten. Dort werden Sie dann aufgefordert, Ihre vertraulichen Daten (in diesem Fall Bankdaten) anzugeben.

Wenn Sie Ihren Mauszeiger auf den Button bewegen, zeigt Ihnen der Browser unten links an, auf welchen Link Sie dieser Button führt:

Oft sind auf solchen Webseiten auch Viren eingebaut, welche nach dem Klick auf den Link auf Ihren Computer eingeschleust werden. Klicken Sie daher also niemals auf einen solchen Link, um solche potentiellen Gefahren zu vermeiden.

Ein weiteres häufiges Indiz für eine Phishing E-Mail ist der Absender der E-Mail. Im obigen Beispiel wurde die E-Mail von der E-Mail Adresse pasapicowiba@capriolaw.com versendet – diese hat offensichtlich nichts mit der Volksbank zu tun.

Dabei ist allerdings Vorsicht geboten: Bei solchen E-Mails kann es auch vorkommen, dass im E-Mail Client eine augenscheinlich korrekte E-Mail Adresse wie z.B. info@vr.de verwendet wird. Hier wird die im E-Mail Client angezeigte Absender E-Mail Adresse ebenfalls gefälscht.

Um festzustellen ob es sich bei der E-Mail um eine Phishing E-Mail handelt sollte man also am besten immer prüfen, welche Webseiten bei den angezeigten Buttons hinterlegt sind.

Um sich abzusichern kann man neben der Prüfung der Links zusätzlich Kontakt zu dem jeweiligen Unternehmen (in diesem Fall zu der Volksbank) Kontakt aufnehmen und erfragen, ob es hier wirklich Änderungen an Prozessen / Verfahren gegeben hat.

Wie kann ich mich vor solchen E-Mails schützen?

Das Wichtigste bei dem Schutz vor solchen gefälschten E-Mails ist, die Inhalte der E-Mails mit höchster Aufmerksamkeit und Vorsicht zu prüfen:

• Wirkt der Inhalt der E-Mail und die Aktion, zu der man aufgefordert wird, plausibel?
• Bin ich überhaupt Kunde bei dem Unternehmen, von dem diese E-Mail zu kommen scheint?
• Von welcher Absender E-Mail Adresse kommt die E-Mail?
• Sehen die Links in der gesetzten E-Mail komisch aus?

Die erste E-Mail des Absender-Servers wird von dem empfangenden Servers abgewiesen. Der Absender-Server wird anschließend nach einem bestimmten Zeitintervall erneut versuchen, die E-Mail zuzustellen. Diese E-Mail wird dann auch vom empfangenden Server angenommen. Diese Funktion dient zum Schutz vor Spam. Bei Spammails erfolgt in den meisten Fällen kein erneuter Zustellversuch der E-Mails.

Was bedeutet DKIM?

DKIM steht für „Domain Keys Identified Mail“. DKIM ist ein auf asymmetrischer Verschlüsselung und Signaturen basierendes Verfahren, mit dem sich die Authentizität der versendenden Domain einer E-Mail sicherstellen lässt. Empfangene Mailserver, welche das Verfahren unterstützen, können gefälschte E-Mail-Absender erkennen und somit vor Spam- und Phishing-Mails schützen.

Wie funktioniert DKIM (einfach erklärt)?

Bei DKIM wird die Zone einer Domain um spezielle TXT Einträge erweitert. Mit Hilfe dieser TXT Einträge (in denen der DKIM-Key definiert wird), kann der empfangene Mailserver prüfen, ob die empfangene E-Mail tatsächlich vom Mailserver des Absenders stammt.

Sofern der empfangende Mailserver eine DKIM Prüfung durchführt, wird in der DNS-Zone der absendenden Domain geprüft, ob der absendende Mailserver einen DKIM Key enthält. Ist dies der Fall, wird geprüft, ob der DKIM-Key mit der Signatur überstimmt. Fällt die Prüfung positiv aus, wird wird die E-Mail zugestellt. Fällt diese negativ aus, wird die Mail abgelehnt.

Was muss ich bei der Verwendung von externen Mailservern/Maildiensten beachten?

Legen Sie in diesem Fall ebenfalls DKIM-Records mit den erforderlichen DKIM-Keys des jeweiligen Anbieters an. Bei Mailversendediensten (z.B. mailchimp.com/cleverreach.com/mailgun.com/…) findet man die entsprechenden Informationen in deren FAQs. Außerdem wird i.d.R. bereits bei der Anmeldung des Dienstes auf die Einrichtung eines DKIM-Records hingewiesen.

Was bedeutet SPF?

SPF steht für „Sender Policy Framework“ und ist eine Technik zur Vermeidung von eingehenden Spam- oder Virenmails mit gefälschtem Absender.

Wie funktioniert SPF (einfach erklärt)?

Bei SPF wird die Zone einer Domain um einen speziellen TXT Eintrag erweitert. Mit Hilfe dieses TXT Eintrages, in dem die erlaubten Versandmailserver definiert werden, wird verhindert, dass Unbefugte eine E-Mail-Manipulationen vornehmen können.

v=spf1 mx include:spf1.x-mailer.de include:spf2.x-mailer.de -all

Sofern der empfangende Mailserver eine SPF Prüfung durchführt, wird in der DNS-Zone der absendenden Domain geprüft, ob der absendende Mailserver gem. Mailheader berechtigt ist, die Mail zu versenden. Fällt die Prüfung positiv aus, wird die Mail zugestellt. Fällt diese negativ aus, wird die Mail abgelehnt.

Populäre Freemailer (Google, T-Online, …) lehnen zunehmend eingehende Mails ohne SPF-Record ab. Weitere Informationen finden Sie in unserem Artikel Warum werden E-Mails von Freemailern (z.B. Google, T-Online, usw.) abgelehnt?

SPF hilft Ihnen jedoch nicht, wenn Ihr Mailkonto gehackt und dann missbraucht wird. Hier hilft Ihnen nur ein sicheres Kennwort.

Was muss ich bei der Verwendung von externen Mailservern/Maildiensten beachten?

Erweitern Sie in diesem Fall den SPF-Record um die Domain oder IP. Bei Mailversendediensten (z.B. mailchimp.com/cleverreach.com/mailgun.com/…) findet man die entsprechenden Informationen in den FAQs. Außerdem wird i.d.R. bereits bei der Anmeldung des Dienstes auf die Einrichtung eines SPF-Records hingewiesen.

Was gibt es bei Weiterleitungen zu beachten?

Bitte beachten Sie, dass es bei der Weiterleitung von E-Mails Probleme geben kann, wenn der Empfänger Mails auf SPF-Records prüft. Aus diesem Grund empfiehlt sich der Einsatz von SRS (Sender Rewriting Scheme), welches die E-Mail Adresse des Absenders so umschreibt, dass sie vom SPF-Record akzeptiert wird.

Seitens Plesk ist SRS von Haus aus aktiv. Die Weiterleitung von E-Mails bei aktivem SPF-Record ist also möglich. Weitere Informationen finden Sie hierzu in der Plesk Dokumentation.