Warum landen meine Mails überhaupt im Spam?
Du verschickst eine ganz normale Mail von deiner eigenen Domain — und beim Empfänger taucht sie im Spam-Ordner auf oder kommt gar nicht erst an. Das liegt fast nie am Inhalt, sondern an der Authentifizierung. Große Anbieter wie Google, Outlook und GMX nehmen seit Anfang 2024 nur noch Mails an, die sich nachweislich der Absender-Domain zuordnen lassen. Fehlt dieser Nachweis, wird einsortiert oder abgewiesen.
Vier Bausteine entscheiden über die Zustellung: SPF, DKIM, DMARC und der PTR-Record (Reverse-DNS). Die ersten drei sind DNS-Einträge in deiner Domain, der vierte gehört zur IP-Adresse deines Mailservers. Stimmen alle vier, ist der Spam-Ordner praktisch kein Thema mehr.
SPF — wer darf für deine Domain senden?
SPF (Sender Policy Framework) ist ein TXT-Eintrag in deiner DNS-Zone, der festlegt, welche Server Mails für deine Domain verschicken dürfen. Der Empfänger gleicht die sendende IP mit dieser Liste ab. Ein typischer Eintrag sieht so aus:
v=spf1 mx a -all
Das mx erlaubt den in deiner Zone hinterlegten Mailservern den Versand, -all weist alles andere hart ab. Wichtig: Pro Domain darf es nur genau einen SPF-Record geben. Hast du zwei, schlägt die Prüfung fehl. Wenn du zusätzlich einen Newsletter-Dienst oder ein Shop-System nutzt, das in deinem Namen sendet, gehört dessen include: in denselben Record — nicht in einen zweiten.
DKIM — die digitale Unterschrift jeder Mail
DKIM (DomainKeys Identified Mail) signiert jede ausgehende Nachricht mit einem privaten Schlüssel, der nur auf deinem Mailserver liegt. Der passende öffentliche Schlüssel steht als TXT-Record in deiner DNS-Zone. Der Empfänger prüft damit zweierlei: Stammt die Mail wirklich von deinem Server, und wurde sie unterwegs nicht manipuliert?
Der DKIM-Record liegt unter einem sogenannten Selektor, zum Beispiel dkim._domainkey.deine-domain.de. Du musst den Schlüssel nicht selbst erzeugen — der Mailserver generiert ihn beim Hinzufügen der Domain. Deine Aufgabe ist nur, den fertigen TXT-Record zu kopieren und in die DNS-Zone einzutragen. Ein häufiger Stolperstein: Manche DNS-Oberflächen kürzen sehr lange Werte oder verlangen, den Schlüssel in mehrere Teilstrings aufzuteilen — hier genau hinschauen, sonst ist die Signatur ungültig.
DMARC — die Spielregel bei Fehlern
SPF und DKIM sagen nur, ob eine Prüfung gelingt. DMARC legt fest, was passieren soll, wenn sie scheitert — und liefert dir nebenbei Reports über jeden Versuch, in deinem Namen zu senden. So startest du:
v=DMARC1; p=none; rua=mailto:dmarc@deine-domain.de
Die Policy p=none bedeutet zunächst: nichts blockieren, nur beobachten. Lass das zwei bis vier Wochen laufen und sieh dir die Reports an, die an die rua-Adresse gehen. Wenn deine legitimen Mails sauber durchlaufen, ziehst du auf p=quarantine (Verdächtiges landet im Spam) und später auf p=reject (Verdächtiges wird komplett abgewiesen). Wer direkt mit p=reject startet, riskiert, dass eine vergessene Versandquelle plötzlich nicht mehr ankommt.
PTR-Record — der unsichtbare vierte Faktor
Der PTR-Record (Reverse-DNS) ist der häufigste Grund, warum trotz korrektem SPF, DKIM und DMARC alles im Outlook-Spam landet. Er löst die IP-Adresse deines Mailservers zurück auf einen Hostnamen auf — quasi die umgekehrte Richtung eines A-Records. Empfänger prüfen, ob dieser Rückwärts-Eintrag existiert und zur sendenden Domain passt.
Der entscheidende Punkt: Den PTR-Record kannst du nicht in deiner Domain-Zone setzen. Er gehört zur IP-Adresse und wird beim Betreiber des Mailservers bzw. Inhaber des IP-Blocks konfiguriert. Wer einen eigenen Mailserver auf einem Root-Server betreibt, muss den PTR also beim Anbieter hinterlegen lassen — und vorher prüfen, ob ausgehender Mailverkehr über Port 25 überhaupt freigeschaltet ist. Auf vielen vServern ist Port 25 aus Spam-Schutz-Gründen standardmäßig gesperrt.
Reputation — Vertrauen muss wachsen
Selbst mit perfekter Technik braucht eine frische Domain oder IP etwas Zeit, bis die Anbieter ihr vertrauen. Diese Reputation baust du dir auf — oder zerstörst sie:
- Langsam anfangen: Nicht am ersten Tag tausende Mails verschicken. Volumen behutsam steigern.
- Saubere Listen: Keine gekauften Adressen, Bounces zeitnah entfernen. Viele unzustellbare Mails kosten Reputation.
- Abmeldung ermöglichen: Bei Newslettern ein funktionierender Abmeldelink, sonst landest du in Beschwerde-Schleifen.
- Konsistenz: Immer von derselben Domain mit denselben Records senden, nicht ständig wechseln.
Selbst testen mit mail-tester
Bevor du dich auf Vermutungen verlässt, miss den Ist-Zustand. Das einfachste Werkzeug ist mail-tester.com: Du bekommst eine zufällige Adresse, schickst eine ganz normale Mail dorthin und erhältst einen Score von 0 bis 10 plus eine Aufschlüsselung, welcher Baustein noch hakt. Ein Wert von 9/10 oder 10/10 ist das Ziel.
Zur gezielten Kontrolle einzelner Einträge hilft auf der Kommandozeile dig: Mit dig TXT deine-domain.de siehst du den SPF-Record, mit dig TXT dkim._domainkey.deine-domain.de den DKIM-Schlüssel und mit dig TXT _dmarc.deine-domain.de die DMARC-Policy. Den PTR prüfst du über dig -x deine-server-ip. So findest du in Minuten heraus, ob ein Eintrag fehlt oder Tippfehler enthält.
Mit Nytrix umsetzen
Den ganzen DNS-Aufwand kannst du dir sparen, wenn der Anbieter die Records gleich richtig setzt. Das E-Mail-Hosting von Nytrix läuft auf einem eigenen Mailcow-Server mit SOGo-Webmail und richtet DKIM, SPF und DMARC automatisch ein — beim Hinzufügen einer Domain bekommst du genau die DNS-Einträge angezeigt, die du übernehmen musst. Der Rspamd-Spamfilter und der korrekt gesetzte PTR-Record sorgen dafür, dass auch ausgehende Mails sauber zugestellt werden. Die Pakete starten bei 1,99 EUR (1 Domain, 3 Postfächer, 5 GB), Standard liegt bei 4,99 EUR (10 Postfächer, 25 GB), Pro bei 14,99 EUR (5 Domains, 50 Postfächer). IMAP, SMTP und POP3 sind dabei, ebenso beliebig viele Aliase und eine Migration bestehender Postfächer per imapsync.
Verwaltest du deine Domain ebenfalls bei Nytrix, trägst du die DNS-Records (A, AAAA, CNAME, MX, TXT, SRV, CAA) direkt im Dashboard ein — inklusive DNSSEC für zusätzliche Sicherheit. Wer lieber einen eigenen Mailserver auf einem vServer betreibt, sollte daran denken, dass Port 25 dort standardmäßig gesperrt ist und für den Mailversand freigeschaltet werden muss. Eine ausführliche Erklärung der Standards findest du auch in unserem Blog.