DNS-Einstellungen für mail-connect Dienste KI

Dieser Artikel beschreibt Schritt für Schritt, wie Sie die DNS-Einträge Ihrer E-Mail-Domain für die Nutzung der mail-connect CLOUD korrekt einrichten. Zu jedem Schritt finden Sie außerdem die häufigsten Fehlerquellen und deren Auswirkungen.

Betreiben Sie für eine Domain niemals zwei parallel aktive Mailsysteme, also z.B. die mail-connect CLOUD und gleichzeitig einen anderen Anbieter wie Microsoft 365. Zwei parallel aktive Mailsysteme führen dazu, dass E-Mails verloren gehen können und/oder in veralteten Postfächern landen.

In den folgenden Abschnitten wird die Domain "beispieldomain.eu" als Beispiel für die benötigten DNS-Einträge verwendet. Passen Sie die DNS-Einträge so an, dass sie auf Ihren gewünschten Domain-Namen passen.

Übersicht

Für den Betrieb einer E-Mail-Domain in der mail-connect CLOUD sind vier DNS-Einträge erforderlich:

• MX - legt fest, welcher Mailserver E-Mails für Ihre Domain annimmt
• SPF - legt fest, welche Mailserver in Ihrem Namen versenden dürfen
• DKIM - signiert Ihre ausgehenden E-Mails digital
• DMARC - legt fest, wie Empfänger mit E-Mails umgehen sollen, die die SPF- oder DKIM-Prüfung nicht bestehen

Hinweis:

• SPF, DKIM und DMARC schützen Ihre Domain vor Phishing-Angriffen, Spoofing und der Kompromittierung von Geschäfts-E-Mails im Namen Ihrer Domain. Diese Einträge sind für die mail-connect CLOUD verpflichtend. Google, Yahoo und Microsoft verlangen sie inzwischen von jedem Absender, der größere Mengen versendet.
• Die Einträge werden in der DNS-Verwaltung derjenigen Stelle vorgenommen, die den Nameserver Ihrer Domain betreibt. Wird Ihre Domain über all-connect verwaltet, finden Sie die DNS-Verwaltung im Kunden-Portal.
• Die Beispiele sind in der Schreibweise für Zonendateien angegeben. In einem Web-Portal tragen Sie die Bestandteile in die Felder Typ, Name, Wert und Priorität ein - die Anführungszeichen entfallen dort.
• Änderungen im DNS sind je nach TTL nicht sofort weltweit aktiv. Planen Sie bis zu 24 Stunden ein, bevor Sie eine Änderung als wirkungslos bewerten. Wenn Sie von einem anderen Anbieter wechseln, senken Sie die TTL Ihrer bestehenden Einträge einige Stunden vorher auf 300. Dann greift die Umstellung in Minuten statt Stunden und ein Rückweg ist ebenso schnell möglich.

Schritt 1 - MX-Record einrichten

Der MX-Eintrag legt fest, welcher Mailserver E-Mails für Ihre Domain annimmt. Wichtig: Alle MX-Einträge einer Domain müssen zum selben Mailsystem gehören, andernfalls kommt es zu Fehlern.

Tragen Sie folgenden Eintrag ein:

@     IN      MX 10    mx.mail-connect.net.

Hinweis:

• Das o.g. Beispiel erstellt also einen MX-Record für den Hostnamen beispieldomain.eu
• Ein einziger MX-Eintrag genügt, weil hinter unserem Hostnamen mx.mail-connect.net bereits mehrere Mailserver-Adressen redundant hinterlegt sind. Dies ist sinnvoll, damit wir bei Wartungen oder Störungen selbständig das Routing bestimmen können und Sie nicht Ihrerseits DNS-Einstellungen ändern müssen.
• Bitte achten Sie auf den abschließenden Punkt "." nach mx.mail-connect.net.

Häufige Fehler beim MX-Record

• Kein MX-Eintrag vorhanden: Dies führt dazu, dass Sie über das Internet keine E-Mails empfangen können. Ohne MX-Eintrag können externe Server keine E-Mails an Ihre Domain zustellen. Bitte tragen Sie den oben gezeigten MX-Record ein.

• MX-Eintrag zeigt auf einen anderen Anbieter (z.B. Microsoft 365), obwohl in der mail-connect CLOUD noch ein Mailserver besteht: mail-connect kann in manchen Fällen den externen Anbieter nicht erreichen. Eingehende E-Mails werden dann nicht weitergeleitet und gehen verloren bzw. werden an stillgelegte Konten zugestellt. Entfernen Sie entweder den fremden MX-Eintrag, oder kontaktieren Sie uns, damit wir den mail-connect Mailserver für Ihre Domain deaktivieren können.

• MX-Eintrag zeigt auf die mail-connect CLOUD, für die Domain ist bei uns aber kein Mailserver eingerichtet oder aktiviert: Eingehende E-Mails kommen zwar bei uns in der Cloud an, können dort aber nicht zugestellt werden und gehen verloren. Kontaktieren Sie uns, damit wir den Mailserver für Ihre Domain einrichten bzw. aktivieren, oder tragen Sie die MX-Records Ihres externen Anbieters ein.

• Fehlender Punkt am Ende: Ohne den abschließenden Punkt interpretieren viele Nameserver den Wert als relativ und hängen Ihre eigene Domain an, der Eintrag zeigt dann auf mx.mail-connect.net.beispieldomain.eu und ist wirkungslos. Manche Portale ergänzen den Punkt automatisch - bitte prüfen Sie das Ergebnis nach dem Speichern.

• MX-Eintrag zeigt auf einen CNAME: Das Ziel eines MX-Eintrags muss ein Hostname mit direktem A- bzw. AAAA-Record sein. Ein CNAME als Ziel ist nicht zulässig, manche Server verweigern dann die Zustellung. Tragen Sie mx.mail-connect.net. ein, dieser Hostname erfüllt die Anforderung.

Schritt 2 - SPF-Record einrichten

Der SPF-Eintrag legt fest, welche Mailserver berechtigt sind, E-Mails im Namen Ihrer Domain zu verschicken. So kann der empfangende Mailserver überprüfen, ob eine E-Mail über einen von Ihnen autorisierten Server versendet wurde oder ob möglicherweise jemand Fremdes Ihre Domain missbraucht (Spam oder Phishing Mails).

Tragen Sie mindestens folgenden Eintrag ein:

@     IN      TXT      "v=spf1 include:_spf.mail-connect.net ~all"

Hinweis:

• Das o.g. Beispiel erstellt also einen TXT-Record für den Hostnamen beispieldomain.eu
• Eine Domain darf nur einen einzigen SPF-Eintrag besitzen. Weitere Anbieter (z.B. für Newsletter oder ein Ticketsystem) werden als zusätzliches include: in denselben Eintrag aufgenommen:

@     IN      TXT      "v=spf1 include:_spf.mail-connect.net include:_spf.anbieter-b.net ~all"

• Die Endung legt fest, wie streng nicht gelistete Absender behandelt werden sollen. ~all (SoftFail) ist die empfohlene Standardeinstellung. -all (Fail) bietet den stärksten Schutz, sollte aber erst gesetzt werden, wenn die DMARC-Berichte zeigen, dass alle Ihre Versandwege erfasst sind. ?all (Neutral) bietet keinen Schutz, da Empfänger den Eintrag dann behandeln, als wäre keiner vorhanden.
• Alle include:, a, mx und exists zusammen dürfen höchstens 10 DNS-Abfragen auslösen - einschließlich derer, die in den Einträgen Ihrer Anbieter enthalten sind. Wird das Limit überschritten, schlägt die Prüfung fehl.
• Weiterführende Informationen zu SPF erhalten Sie unter https://de.wikipedia.org/wiki/Sender_Policy_Framework

Häufige Fehler beim SPF-Record

• Kein SPF-Eintrag vorhanden: Dies führt dazu, dass der Versand über die mail-connect CLOUD von vielen Empfängern als unsicher eingestuft wird und Ihre E-Mails möglicherweise im Spam-Ordner beim Empfänger landen bzw. abgewiesen werden. Bitte tragen Sie den oben gezeigten SPF-Record ein.

• SPF-Eintrag enthält nur einen Fremdanbieter, während die mail-connect CLOUD noch aktiv ist: Solange mail-connect noch aktiv ist und E-Mails über unsere Server versendet werden, erkennen empfangende Mailserver diese E-Mails als nicht autorisiert - da unsere Server nicht im SPF-Eintrag stehen. Ihre E-Mails landen dann im Spam-Ordner oder werden abgewiesen. Ergänzen Sie include:_spf.mail-connect.net im bestehenden Eintrag, oder kontaktieren Sie uns, damit wir den mail-connect Dienst für Ihre Domain deaktivieren.

• Es existieren zwei separate TXT-Einträge für SPF: Betrifft Domains, für die zwei TXT-Einträge mit v=spf1 hinterlegt sind. Dies führt dazu, dass die SPF-Prüfung beim Empfänger komplett fehlschlägt - E-Mails werden ggf. abgewiesen oder als Spam eingestuft. Fassen Sie beide Einträge zu einem einzigen zusammen (siehe oben) oder löschen Sie den nicht benötigten. Übernehmen Sie beim Zusammenfassen nur den include:-Teil des anderen Anbieters - ein zweites v=spf1 oder ein zweites all innerhalb eines Eintrags funktioniert nicht.

• Zu viele DNS-Abfragen im SPF-Eintrag: Der Eintrag überschreitet das Limit von 10 Nachschlagevorgängen. Die Prüfung bricht beim Empfänger ab und gilt als fehlgeschlagen, obwohl der Eintrag im DNS korrekt aussieht. Dieser Fehler tritt typischerweise ab dem dritten oder vierten angebundenen Dienst auf. Entfernen Sie include:-Verweise auf nicht mehr genutzte Dienste oder lagern Sie einzelne Versandwege auf eine Subdomain mit eigenem SPF-Eintrag aus.

Schritt 3 - DKIM-Record einrichten

DKIM versieht Ihre ausgehenden E-Mails mit einer digitalen Signatur. Empfangende Mailserver können anhand des im DNS hinterlegten öffentlichen Schlüssels prüfen, ob die Nachricht unterwegs verändert wurde und ob sie über Ihre Domain autorisiert wurde. Anders als SPF überlebt DKIM auch Weiterleitungen.

Tragen Sie folgenden Eintrag ein:

mail-connect._domainkey     IN      TXT      "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCdG1MYcrYYxCb3fcCSfgs6GyprlkaKNJ1qCsru1B0/ndQD7iLFECzU2UPGXlSsevM56HxvAQNodjA0zvyrPbAKKdStEeLj1IbySxUoqRjCQOviLS4SI8duVtTd53kum1ugvQtGd7byj6THGkIvJEpI22QzhF2uMfh9ijCiesjAQIDAQAB"

Hinweis:

• Das o.g. Beispiel erstellt also einen TXT-Record für den Hostnamen mail-connect._domainkey.beispieldomain.eu. Tragen Sie im Namensfeld nur mail-connect._domainkey ein, ohne Ihre Domain - viele Portale ergänzen diese automatisch.
• Bitte beachten Sie, dass Sie die o.g. graue Zeile in Ihrem Nameserver nur als eine einzige Zeile ohne Zeilenumbruch eintragen. Ein einziges zusätzliches Zeichen macht die Signaturprüfung ungültig.
• Die Anführungszeichen gehören in einer Zonendatei zwingend dazu, weil die Semikolons sonst als Kommentarzeichen gewertet werden und der Schlüssel verloren geht. In einem Web-Portal entfallen sie.
• Es können mehrere DKIM-Records parallel in Ihrer Zone existieren. Für mail-connect wird zur Zeit nur dieser Eintrag verwendet.
• Weiterführende Informationen zu DKIM erhalten Sie unter https://de.wikipedia.org/wiki/DomainKeys_Identified_Mail

Häufige Fehler beim DKIM-Record

• DKIM-Eintrag fehlt komplett: Dies führt dazu, dass empfangende Mailserver nicht verifizieren können, ob E-Mails legitim über die mail-connect CLOUD versendet werden - E-Mails können als Spam eingestuft oder abgewiesen werden und die Reputation der mail-connect CLOUD kann beeinträchtigt werden. Tragen Sie den oben gezeigten DKIM-Record ein, oder kontaktieren Sie uns, damit wir den mail-connect Dienst für Ihre Domain deaktivieren.

• DKIM-Eintrag vorhanden, aber Schlüssel falsch oder verändert: Dies führt dazu, dass die Signaturprüfung fehlschlägt. Die Auswirkungen sind identisch mit einem fehlenden DKIM-Eintrag. Häufigste Ursachen sind Zeilenumbrüche oder Leerzeichen, die beim Kopieren in den Schlüssel geraten sind. Ersetzen Sie den vorhandenen Eintrag durch den korrekten Schlüssel (s.o.).

• DKIM-Eintrag wird nicht gefunden: Wurde im Namensfeld zusätzlich die eigene Domain eingetragen, steht der Eintrag anschließend auf mail-connect._domainkey.beispieldomain.eu.beispieldomain.eu und ist wirkungslos. Tragen Sie im Namensfeld ausschließlich mail-connect._domainkey ein.

Schritt 4 - DMARC-Record einrichten

Domain-based Message Authentication, Reporting and Conformance (DMARC) ist ein E-Mail-Validierungssystem, um Ihre Domain vor Missbrauch durch Spoofing, Phishing-Betrug und andere Cyberkriminalität zu schützen. DMARC baut auf SPF und DKIM auf und stellt eine Richtlinie dar, die dem Mail-Empfänger zeigt, was mit E-Mails passieren soll, die scheinbar von Ihrer Domain gesendet wurden, tatsächlich aber von einer fremden Person stammen.

Zusätzlich erhalten Sie Berichte darüber, wer in Ihrem Namen E-Mails versendet - auch unberechtigt.

Tragen Sie folgenden Eintrag ein:

_dmarc     IN      TXT      "v=DMARC1; p=none; rua=mailto:dmarc@beispieldomain.eu"

Hinweis:

• Das o.g. Beispiel erstellt also einen TXT-Record für den Hostnamen _dmarc.beispieldomain.eu
• Bitte verwenden Sie anstatt beispieldomain.eu Ihren eigenen Domain-Namen. Auch in der Mail-Adresse hinter rua=
• Hinter rua= werden die täglichen Sammelberichte im XML-Format angefordert. Verwenden Sie ein Postfach, das tatsächlich abgerufen wird.
• Beginnen Sie immer mit p=none. In dieser Phase wird nichts blockiert, Sie sammeln nur Berichte. Erst wenn diese über etwa zwei bis vier Wochen zeigen, dass alle Ihre Versandwege die Prüfung bestehen, erhöhen Sie auf p=quarantine (Zustellung in den Spam-Ordner) und anschließend auf p=reject (Abweisung).
• Weiterführende Informationen zu DMARC erhalten Sie unter https://de.wikipedia.org/wiki/DMARC

Häufige Fehler beim DMARC-Record

• Kein DMARC-Eintrag vorhanden: Große Anbieter wie Google, Yahoo und Microsoft stufen Sie als nicht regelkonformen Absender ein. Ab bestimmten Versandmengen werden Ihre E-Mails abgewiesen, ohne dass sie den Spam-Ordner erreichen. Bitte tragen Sie den oben gezeigten DMARC-Record ein.

• Direkt mit p=quarantine oder p=reject gestartet: Ist auch nur ein Versandweg noch nicht vollständig in SPF oder DKIM erfasst, werden Ihre eigenen E-Mails ab sofort in den Spam-Ordner verschoben oder abgewiesen. Betroffen sind in der Praxis häufig Newsletter-Tools, Webshops oder Ticketsysteme, an die zunächst niemand denkt. Stellen Sie vorübergehend auf p=none zurück, werten Sie die Berichte aus und erhöhen Sie erst dann schrittweise.

• ruf= statt rua= verwendet: Hinter ruf= werden Forensic Reports angefordert. Diese enthalten personenbezogene Daten und werden von den großen Anbietern wie Google, Microsoft und Yahoo deshalb nicht mehr versendet. Sie erhalten dadurch keine auswertbaren Berichte und können nicht beurteilen, ob eine Erhöhung der Richtlinie gefahrlos möglich ist. Verwenden Sie rua= - nur darüber werden die täglichen Sammelberichte angefordert.

• Berichtsadresse liegt auf einer anderen Domain: Soll rua= auf ein Postfach einer fremden Domain zeigen, muss diese Domain der Berichterstattung ausdrücklich zustimmen. Fehlt diese Zustimmung, ignorieren meldende Server die Adresse und es werden gar keine Berichte versendet. Verwenden Sie ein Postfach Ihrer eigenen Domain, oder lassen Sie auf der fremden Domain einen TXT-Eintrag beispieldomain.eu._report._dmarc mit dem Wert v=DMARC1 anlegen.

• Berichtsadresse existiert nicht oder wird nicht gelesen: Die Berichte können nicht zugestellt werden oder wertet niemand aus. Sie bemerken dadurch nicht, wenn ein Versandweg fehlschlägt oder Ihre Domain missbraucht wird. Verwenden Sie eine Adresse, die tatsächlich existiert und regelmäßig abgerufen wird.

• Nicht alle versendenden Systeme berücksichtigt: Systeme, die weder im SPF-Eintrag stehen noch per DKIM signieren, bestehen die DMARC-Prüfung nicht. Ab p=quarantine werden deren E-Mails aussortiert oder abgewiesen. Prüfen Sie, ob alle Dienste, die mit Ihrer Domain versenden, entweder im SPF-Eintrag stehen oder per DKIM signieren - für DMARC genügt eines von beidem, aber mindestens eines muss zutreffen. Die Berichte aus der Phase p=none zeigen Ihnen, welche Systeme betroffen sind.

• DMARC-Eintrag wird nicht gefunden: Wurde im Namensfeld zusätzlich die eigene Domain eingetragen, steht der Eintrag anschließend auf _dmarc.beispieldomain.eu.beispieldomain.eu und ist wirkungslos. Tragen Sie im Namensfeld ausschließlich _dmarc ein.