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 Eintrag finden Sie außerdem die häufigsten Fehlerquellen und deren Auswirkungen.

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. 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.

Übersicht

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

Eintrag	Wofür er da ist	Was passiert, wenn er fehlt
MX	Legt fest, welcher Mailserver E-Mails für Ihre Domain annimmt.	Sie empfangen gar keine E-Mails.
SPF	Legt fest, welche Mailserver in Ihrem Namen versenden dürfen.	Ihre E-Mails landen beim Empfänger im Spam.
DKIM	Versieht Ihre ausgehenden E-Mails mit einer digitalen Signatur.	Ihre E-Mails landen beim Empfänger im Spam.
DMARC	Legt fest, wie Empfänger mit E-Mails umgehen sollen, die die Prüfung nicht bestehen.	Große Anbieter wie Gmail und Outlook weisen Ihre E-Mails ab.

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 - fehlen sie, werden E-Mails teilweise direkt abgewiesen und erreichen nicht einmal den Spam-Ordner.
• 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.
• Der Name @ steht für Ihre Domain selbst, also beispieldomain.eu. Manche Portale erwarten statt @ ein leeres Feld oder den vollständigen Domainnamen - das bedeutet dasselbe.
• Ä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.

Reihenfolge und Vorbereitung

Arbeiten Sie die Schritte in der angegebenen Reihenfolge ab. Wenn Sie von einem anderen Anbieter zu uns wechseln, beachten Sie zusätzlich:

1. TTL senken. Setzen Sie die TTL Ihrer bestehenden MX-Einträge einige Stunden vor der Umstellung auf 300 (5 Minuten). Die TTL bestimmt, wie lange andere Server einen alten Wert zwischenspeichern. Mit 300 Sekunden greift Ihre Änderung später innerhalb von Minuten statt Stunden - und ein Rückweg ist genauso schnell möglich.
2. Erst SPF, DKIM und DMARC anlegen (Schritt 2 bis 4).
3. Zum Schluss den MX-Eintrag umstellen (Schritt 1).

So ist die Authentifizierung bereits aktiv, wenn die ersten E-Mails eintreffen.

Schritt 1 - MX-Record einrichten

Der MX-Eintrag legt fest, welcher Mailserver E-Mails für Ihre Domain annimmt.

Alle MX-Einträge einer Domain müssen zum selben Mailsystem gehören. Stehen in Ihrer DNS-Verwaltung noch MX-Einträge eines anderen Anbieters, löschen Sie diese.

Tragen Sie folgenden Eintrag ein:

Feld	Wert
Typ	MX
Name / Host	@
Priorität	10
Wert / Ziel	mx.mail-connect.net.
TTL	3600

In der Schreibweise für Zonendateien entspricht das:

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

Hinweis:

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

Fehler am MX-Record

Kein MX-Eintrag vorhanden

Dies führt dazu, dass Sie über das Internet keine E-Mails empfangen können. Ohne MX-Eintrag wissen externe Server nicht, wohin sie E-Mails an Ihre Domain zustellen sollen.

Mögliche Lösungsansätze:

• Tragen Sie den MX-Record aus Schritt 1 ein.

MX-Eintrag zeigt auf einen anderen Anbieter, obwohl in der mail-connect CLOUD noch ein Mailserver besteht

mail-connect kann in manchen Fällen den externen Anbieter (z.B. Microsoft 365) nicht erreichen. Eingehende E-Mails werden dann nicht weitergeleitet und gehen verloren bzw. werden an stillgelegte Konten zugestellt.

Mögliche Lösungsansätze:

• Sie möchten mail-connect nutzen: Entfernen Sie den fremden MX-Eintrag und tragen Sie den Eintrag aus Schritt 1 ein.
• Sie möchten mail-connect nicht nutzen: Kontaktieren Sie uns, damit wir den mail-connect Mailserver für Ihre Domain deaktivieren.

MX-Eintrag zeigt auf die mail-connect CLOUD, für die Domain ist bei uns aber kein Mailserver eingerichtet

Eingehende E-Mails kommen zwar bei uns in der Cloud an, können dort aber nicht zugestellt werden und gehen verloren.

Mögliche Lösungsansätze:

• Sie möchten mail-connect nutzen: Kontaktieren Sie uns, damit wir den Mailserver für Ihre Domain einrichten bzw. aktivieren.
• Sie möchten mail-connect nicht nutzen: Tragen Sie die MX-Records Ihres tatsächlichen Anbieters ein.

Fehlender Punkt am Ende des MX-Ziels

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.

Mögliche Lösungsansätze:

• Ergänzen Sie den Punkt: mx.mail-connect.net.
• Manche Portale ergänzen den Punkt automatisch. Prüfen Sie das Ergebnis nach dem Speichern.

MX-Eintrag zeigt auf einen CNAME

Das ist laut Standard nicht zulässig. Manche Server verweigern dann die Zustellung an Ihre Domain.

Mögliche Lösungsansätze:

• Das Ziel eines MX-Eintrags muss ein Hostname mit direkter IP-Adresse sein. Tragen Sie mx.mail-connect.net. ein, dieser Hostname erfüllt die Anforderung.

Schritt 2 - SPF-Record einrichten

Der SPF-Eintrag ist eine öffentliche Liste der Server, die E-Mails im Namen Ihrer Domain versenden dürfen. Empfängt jemand eine E-Mail von Ihnen, kann sein Mailserver anhand dieser Liste prüfen, ob der absendende Server dazu berechtigt war. So lässt sich erkennen, ob jemand Fremdes Ihre Domain für Spam- oder Phishing-Mails missbraucht.

Tragen Sie mindestens folgenden Eintrag ein:

Feld	Wert
Typ	TXT
Name / Host	@
Wert	v=spf1 include:_spf.mail-connect.net ~all
TTL	3600

In der Schreibweise für Zonendateien entspricht das:

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

Hinweis:

• Eine Domain darf nur einen einzigen SPF-Eintrag besitzen. Alle Anbieter werden gemeinsam in diesem einen Eintrag aufgeführt.
• Weiterführende Informationen zu SPF erhalten Sie unter https://de.wikipedia.org/wiki/Sender_Policy_Framework

Die Endung des SPF-Eintrags

Der letzte Teil des Eintrags legt fest, wie streng nicht gelistete Absender behandelt werden sollen:

Endung	Bedeutung	Empfehlung
~all	SoftFail - als verdächtig behandeln	Standard. Guter Kompromiss aus Schutzwirkung und Sicherheit gegen Fehlkonfiguration.
-all	Fail - abweisen	Stärkster Schutz. Stellen Sie erst darauf um, wenn Sie über die DMARC-Berichte sicher sind, dass alle Ihre Versandwege erfasst sind.
?all	Neutral - keine Aussage	Bietet keinen Schutz vor Missbrauch Ihrer Domain, da Empfänger den Eintrag dann behandeln, als gäbe es gar keinen. Nur als kurzfristige Übergangslösung während einer Migration sinnvoll.

Wenn Sie weitere Dienste nutzen

Versenden Sie zusätzlich über Newsletter-Tools, ein CRM oder ein Ticketsystem, müssen diese ebenfalls im SPF-Eintrag stehen. Ergänzen Sie dazu nur den include:-Teil des anderen Anbieters in demselben Eintrag:

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

Hinweis:

• Falsch ist es, den kompletten Eintrag des anderen Anbieters anzuhängen. Ein zweites v=spf1 oder ein zweites all innerhalb eines Eintrags funktioniert nicht.
• Richtig ist genau ein Eintrag, der mit v=spf1 beginnt, alle include: nacheinander auflistet und mit genau einem ~all endet.

Maximal 10 Nachschlagevorgänge: Jedes include:, a, mx und exists in Ihrem SPF-Eintrag löst beim Empfänger eine DNS-Abfrage aus - auch diejenigen, die in den Einträgen Ihrer Anbieter versteckt sind. Zusammen dürfen es höchstens 10 sein. Werden es mehr, bricht die SPF-Prüfung komplett ab und gilt als fehlgeschlagen. Dieser Fehler ist tückisch, weil der Eintrag im DNS völlig korrekt aussieht. Er tritt typischerweise ab dem dritten oder vierten angebundenen Dienst auf. Entfernen Sie deshalb auch include:-Verweise auf Dienste, die Sie nicht mehr nutzen.

Fehler am 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.

Mögliche Lösungsansätze:

• Sie nutzen ausschließlich die mail-connect CLOUD: Tragen Sie den SPF-Eintrag aus Schritt 2 ein.
• Sie nutzen zusätzlich weitere Anbieter (z.B. für Newsletter): Ergänzen Sie deren include: im selben Eintrag, siehe Wenn Sie weitere Dienste nutzen.

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. Dies kann dazu führen, dass Ihre E-Mails beim Empfänger im Spam-Ordner landen oder vollständig abgewiesen werden.

Mögliche Lösungsansätze:

• Sie möchten mail-connect nutzen: Ergänzen Sie include:_spf.mail-connect.net im bestehenden Eintrag.
• Sie möchten mail-connect nicht nutzen: 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. Eine Domain darf nur einen einzigen SPF-Eintrag haben. Bei zweien schlägt die SPF-Prüfung beim Empfänger komplett fehl - E-Mails werden ggf. abgewiesen oder als Spam eingestuft.

Mögliche Lösungsansätze:

• Sie möchten beide Anbieter nutzen: Fassen Sie beide SPF-Einträge zu einem einzigen TXT-Eintrag zusammen, z.B.

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

• Sie möchten nur einen Anbieter nutzen: Löschen Sie den nicht benötigten SPF-Eintrag, sodass nur noch ein TXT-Eintrag vorhanden ist.

Zu viele DNS-Abfragen im SPF-Eintrag

Der SPF-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.

Mögliche Lösungsansätze:

• Entfernen Sie include:-Verweise auf Dienste, die Sie nicht mehr nutzen.
• Fassen Sie Anbieter zusammen oder lagern Sie einzelne Versandwege auf eine Subdomain mit eigenem SPF-Eintrag aus.

Schritt 3 - DKIM-Record einrichten

DKIM versieht jede Ihrer ausgehenden E-Mails mit einer digitalen Signatur. Der empfangende Mailserver holt sich den passenden öffentlichen Schlüssel aus Ihrem DNS und kann damit zwei Dinge belegen: dass die Nachricht unterwegs nicht verändert wurde und dass sie tatsächlich von Ihrer Domain autorisiert wurde.

Anders als SPF überlebt DKIM auch Weiterleitungen. Der Eintrag ist deshalb auch dann wichtig, wenn Ihr SPF-Eintrag bereits korrekt ist.

Tragen Sie folgenden Eintrag ein:

Feld	Wert
Typ	TXT
Name / Host	mail-connect._domainkey
Wert	siehe graue Zeile unten
TTL	3600

In der Schreibweise für Zonendateien entspricht das:

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

Hinweis:

• 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.
• Tragen Sie im Namensfeld nur mail-connect._domainkey ein, ohne Ihre Domain. Viele Portale ergänzen die Domain automatisch.
• Falls Ihnen im Kunden-Portal ein individueller DKIM-Schlüssel angezeigt wird, verwenden Sie diesen anstelle des Werts oben.

Fehler am 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.

Mögliche Lösungsansätze:

• Sie möchten mail-connect nutzen: Tragen Sie den DKIM-Eintrag aus Schritt 3 ein.
• Sie möchten mail-connect nicht nutzen: 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.

Mögliche Lösungsansätze:

• Sie möchten mail-connect nutzen: Ersetzen Sie den vorhandenen Eintrag durch den korrekten Schlüssel aus Schritt 3.
• Sie möchten mail-connect nicht nutzen: Kontaktieren Sie uns, damit wir den mail-connect Dienst für Ihre Domain deaktivieren.

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.

Mögliche Lösungsansätze:

• Tragen Sie im Namensfeld ausschließlich mail-connect._domainkey ein.

Schritt 4 - DMARC-Record einrichten

Domain-based Message Authentication, Reporting and Conformance (DMARC) schützt Ihre Domain vor Missbrauch durch Spoofing, Phishing und andere Formen der Cyberkriminalität. DMARC baut direkt auf SPF und DKIM auf und ergänzt zwei entscheidende Punkte:

• Es schützt die sichtbare Absenderadresse. SPF prüft technisch nur die Adresse aus dem Hintergrund-Protokoll, nicht die Adresse, die Ihre Empfänger im Postfach sehen. Erst DMARC verlangt, dass die durch SPF oder DKIM bestätigte Domain zur angezeigten Absenderadresse passt.
• Es legt eine Richtlinie fest. Sie bestimmen selbst, was ein Empfänger mit einer E-Mail tun soll, die diese Prüfung nicht besteht: nur melden, in den Spam-Ordner verschieben oder abweisen.

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

Tragen Sie folgenden Eintrag ein:

Feld	Wert
Typ	TXT
Name / Host	_dmarc
Wert	v=DMARC1; p=none; rua=mailto:dmarc@beispieldomain.eu
TTL	3600

In der Schreibweise für Zonendateien entspricht das:

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

Hinweis:

• Das o.g. Beispiel erstellt einen TXT-Record für den Hostnamen _dmarc.beispieldomain.eu. Tragen Sie im Namensfeld ausschließlich _dmarc ein, ohne Ihre Domain.
• Ersetzen Sie beispieldomain.eu durch Ihren eigenen Domain-Namen - auch in der Adresse hinter rua=.
• Verwenden Sie hinter rua= ein Postfach, das tatsächlich regelmäßig abgerufen wird. Dorthin senden Empfänger täglich Berichte im XML-Format.
• Weiterführende Informationen zu DMARC erhalten Sie unter https://de.wikipedia.org/wiki/DMARC

DMARC schrittweise einführen

{{{1}}}

Phase	Wert für p=	Dauer	Wirkung
1. Beobachten	p=none	2-4 Wochen	Nichts wird blockiert. Sie sammeln ausschließlich Berichte.
2. Aussortieren	p=quarantine	2-4 Wochen	Nicht bestandene E-Mails landen beim Empfänger im Spam-Ordner.
3. Abweisen	p=reject	dauerhaft	Nicht bestandene E-Mails werden abgewiesen. Voller Schutz.

Gehen Sie erst dann in die nächste Phase, wenn in den Berichten alle Ihre legitimen Versandwege erfolgreich geprüft werden. Für die Auswertung der XML-Berichte gibt es kostenlose Online-Werkzeuge - oder Sie sprechen uns an.

Fehler am 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.

Mögliche Lösungsansätze:

• Tragen Sie den DMARC-Record aus Schritt 4 ein.

Direkt mit p=quarantine oder p=reject gestartet

Legitime E-Mails über noch nicht erfasste Versandwege werden sofort in Quarantäne verschoben oder abgewiesen. Das betrifft in der Praxis häufig Newsletter-Tools, CRM- oder Ticketsysteme, an die zunächst niemand denkt.

Mögliche Lösungsansätze:

• Stellen Sie den Eintrag vorübergehend auf p=none zurück.
• Werten Sie die Berichte aus und erhöhen Sie erst dann schrittweise, siehe DMARC schrittweise einführen.

ruf= statt rua= verwendet

Hinter ruf= stehen sogenannte Forensic Reports. Diese werden von den großen Anbietern wie Google, Microsoft und Yahoo aus Datenschutzgründen praktisch nicht mehr versendet. Sie erhalten dadurch gar keine auswertbaren Berichte und können nicht beurteilen, ob eine Erhöhung der Richtlinie gefahrlos möglich ist.

Mögliche Lösungsansätze:

• Verwenden Sie rua= anstelle von ruf=. Nur darüber werden die täglichen Sammelberichte angefordert.

Berichtsadresse hinter rua= existiert nicht oder wird nicht gelesen

Die Berichte können nicht zugestellt werden oder werden von niemandem ausgewertet. Sie merken dadurch nicht, wenn ein Versandweg fehlschlägt oder Ihre Domain missbraucht wird.

Mögliche Lösungsansätze:

• 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 Phase 2 werden deren E-Mails aussortiert oder abgewiesen.

Mögliche Lösungsansätze:

• Prüfen Sie vor dem Wechsel auf p=quarantine, ob wirklich alle Dienste, die mit Ihrer Domain versenden, entweder im SPF-Eintrag stehen oder Ihre E-Mails per DKIM signieren. Für DMARC genügt eines von beidem - aber mindestens eines muss zutreffen.
• Die DMARC-Berichte aus Phase 1 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.

Mögliche Lösungsansätze:

• Tragen Sie im Namensfeld ausschließlich _dmarc ein.

Schritt 5 - Ergebnis prüfen

Einträge kontrollieren

Öffnen Sie unter Windows die PowerShell und führen Sie folgende Befehle aus. Ersetzen Sie dabei beispieldomain.eu durch Ihre Domain:

Resolve-DnsName beispieldomain.eu -Type MX
Resolve-DnsName beispieldomain.eu -Type TXT
Resolve-DnsName mail-connect._domainkey.beispieldomain.eu -Type TXT
Resolve-DnsName _dmarc.beispieldomain.eu -Type TXT

Vergleichen Sie die Ausgabe mit den Werten aus dieser Anleitung.

Praxistest mit einer echten E-Mail

Der aussagekräftigste Test:

1. Senden Sie eine E-Mail von Ihrer Domain an ein Gmail-Konto.
2. Öffnen Sie die E-Mail dort und wählen Sie im Menü "Original anzeigen".
3. Ganz oben müssen alle drei Zeilen PASS zeigen:

SPF:    PASS
DKIM:   PASS
DMARC:  PASS

Steht dort FAIL oder SOFTFAIL, prüfen Sie den entsprechenden Eintrag noch einmal.

Geduld beim Warten

Änderungen im DNS sind nicht sofort weltweit aktiv. Planen Sie je nach TTL bis zu 24 Stunden ein, bevor Sie eine Änderung als wirkungslos bewerten. Haben Sie die TTL vorab wie oben empfohlen gesenkt, greifen Änderungen meist innerhalb weniger Minuten.

Sie kommen nicht weiter?

Unser Support hilft Ihnen bei der Einrichtung und prüft Ihre DNS-Einträge auf Wunsch gemeinsam mit Ihnen.