E-Mail-Zustellbarkeit: SPF, DKIM, DMARC und PTR richtig setzen

Dein Mailserver läuft, Postfächer sind angelegt – und trotzdem landen deine Mails beim Empfänger im Spam oder werden gleich ganz abgewiesen. Willkommen beim eigentlich schweren Teil des Selbst-Hostens: der Zustellbarkeit. Sie hängt nicht an deiner Server-Software, sondern an vier DNS-Bausteinen, die anderen Servern beweisen, dass deine Mails echt sind. Dieses Tutorial richtet sie ein und testet sie.

Was bauen wir?

Am Ende erkennen große Mailanbieter (Gmail, Outlook, GMX & Co.) deine Mails als authentisch und liefern sie in den Posteingang statt in den Spam. Dafür sorgen vier Mechanismen, die zusammenspielen:

• Reverse DNS (PTR): beweist, dass deine Server-IP zu deinem Mail-Hostnamen gehört – die Grundvoraussetzung, ohne die viele Server gar nicht erst annehmen.
• SPF: legt fest, welche Server im Namen deiner Domain senden dürfen.
• DKIM: signiert jede ausgehende Mail kryptografisch, sodass Manipulation und Fälschung auffliegen.
• DMARC: sagt den Empfängern, was zu tun ist, wenn SPF oder DKIM fehlschlagen – und schickt dir Berichte.

Der Nutzen ist doppelt: Deine eigenen Mails kommen zuverlässig an – und niemand kann in deinem Namen fälschen. Ohne diese Records kann jeder Angreifer Mails mit deiner Absenderdomain verschicken („Spoofing") und damit Phishing in deinem Namen betreiben. SPF, DKIM und DMARC machen genau das unmöglich: Sie verwandeln deine Domain von einem offen missbrauchbaren Absender in einen nachweisbar echten. Gerade wenn Kund:innen oder Kolleg:innen Mails von dir erwarten, ist dieser Schutz mindestens so wichtig wie die Zustellbarkeit selbst.

Diese vier Records sind unabhängig von deiner Server-Software. Ob du Mailcow oder Stalwart betreibst, ist egal – die Zustellbarkeit konfigurierst du im DNS und beim Provider.

Voraussetzungen

• Ein laufender Mailserver unter deiner Domain (z. B. aus dem Mailcow- oder Stalwart-Tutorial).

• Voller Zugriff auf die DNS-Zone deiner Domain (siehe Domain mit dem Server verbinden).

• Zugriff auf das Provider-Panel, um den Reverse-DNS-Eintrag der Server-IP zu setzen (bei netcup im SCP).

• Das Werkzeug dig zum Prüfen der Records:

  Terminal

  sudo apt install -y bind9-dnsutils

Schritt für Schritt

Schritt 1: Reverse DNS (PTR) setzen – das Fundament

Der wichtigste und am häufigsten vergessene Eintrag. Während ein normaler DNS-Eintrag einen Namen in eine IP auflöst, macht der PTR-Eintrag das Gegenteil: Er löst deine Server-IP zurück in einen Namen auf. Empfänger prüfen, ob dieser Name zu deinem Mail-Hostnamen passt. Fehlt der PTR oder zeigt er auf einen generischen Provider-Namen, gilt dein Server als verdächtig.

Den PTR-Eintrag setzt du nicht in deiner DNS-Zone, sondern beim Provider, dem die IP gehört. Bei netcup gehst du dazu ins Server Control Panel (SCP) → Netzwerk / Reverse DNS und trägst für deine IP den Wert mail.DEINE_DOMAIN ein. Nach der Propagierung prüfst du:

dig +short -x DEINE_SERVER_IP

mail.deine-domain.de.

Kommt hier mail.DEINE_DOMAIN zurück, stimmt der PTR. Zeigt er noch auf etwas wie vXXXXXXXXX.example-provider.net, ist er noch nicht gesetzt oder nicht propagiert.

Schritt 2: SPF – wer darf in deinem Namen senden?

Der SPF-Record ist ein TXT-Eintrag in deiner DNS-Zone. Er listet die IPs bzw. Hostnamen, die Mails für deine Domain versenden dürfen. Für einen einzelnen Mailserver genügt:

DEINE_DOMAIN.   TXT   "v=spf1 a:mail.DEINE_DOMAIN -all"

Zerlegt:

• v=spf1 – die SPF-Version.
• a:mail.DEINE_DOMAIN – der Server hinter diesem A-Record darf senden. Alternativ direkt die IP mit ip4:DEINE_SERVER_IP (und ip6:… bei IPv6).
• -all – alle anderen Server sind nicht autorisiert („hard fail"). Das ist die strenge, empfohlene Variante. Ein ~all („soft fail") ist nachsichtiger, aber weniger wirksam.

Prüfen – und zwar mit Filter:

dig +short TXT DEINE_DOMAIN | grep spf1

"v=spf1 a:mail.deine-domain.de -all"

Das grep ist kein Luxus: dig +short TXT gibt alle TXT-Einträge deiner Zone aus, und dort sammeln sich mit der Zeit Verifikations-Token von Google, Microsoft & Co. an. Real nachgemessen – google.com antwortet mit 16 TXT-Einträgen, microsoft.com mit 61. Ohne Filter suchst du deinen SPF-Record von Hand heraus. Kommt gar nichts zurück, existiert kein SPF-Record. Kommen zwei Zeilen zurück, hast du zwei SPF-Records – und das ist ein Fehler, siehe „Wenn es nicht funktioniert".

Versendest du zusätzlich über Dritte – etwa einen Newsletter-Dienst oder das Transaktionsmail- Gateway einer App – gehören deren Server ebenfalls autorisiert. Das machst du über include:, und zwar in einem einzigen Record:

DEINE_DOMAIN.   TXT   "v=spf1 a:mail.DEINE_DOMAIN include:_spf.dienstleister.de -all"

Schritt 3: DKIM – jede Mail kryptografisch signieren

DKIM signiert jede ausgehende Mail mit einem privaten Schlüssel; den passenden öffentlichen Schlüssel legst du als DNS-Record ab. Empfänger prüfen damit, dass die Mail wirklich von dir kommt und unterwegs nicht verändert wurde.

So läuft es ab: Beim Versand berechnet dein Server aus wichtigen Kopfzeilen und dem Nachrichtentext eine Signatur und hängt sie als DKIM-Signature-Header an. Der Empfänger holt sich deinen öffentlichen Schlüssel aus dem DNS und prüft die Signatur. Passt sie, ist bewiesen: Die Mail stammt von einem Server mit deinem privaten Schlüssel und wurde nicht verändert. Nimm 2048-Bit-Schlüssel – 1024 Bit gelten als zu schwach, und die meisten DNS-Anbieter kommen mit der Schlüssellänge inzwischen problemlos zurecht.

Den Schlüssel erzeugt dein Mailserver – du musst nur den DNS-Record veröffentlichen:

• In Mailcow: Konfiguration → ARC/DKIM-Schlüssel, Domain auswählen, Schlüssel erzeugen (2048 Bit). Mailcow zeigt dir den fertigen DNS-Record an.
• In Stalwart: Die Schlüssel entstehen im Einrichtungs-Assistenten; den Record findest du in der Konsole unter der jeweiligen Domain.

Der Record hat einen Selector (einen frei gewählten Namen, z. B. dkim oder default) und sieht so aus:

dkim._domainkey.DEINE_DOMAIN.   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq...LANGER_PUBLIC_KEY...AQAB"

Übernimm den Wert exakt so, wie dein Mailserver ihn ausgibt. Prüfen:

dig +short TXT dkim._domainkey.DEINE_DOMAIN

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…ERSTER_TEIL" "ZWEITER_TEIL…AQAB"

Wundere dich nicht über die zwei Blöcke in Anführungszeichen: Eine einzelne Zeichenkette in einem TXT-Eintrag darf höchstens 255 Bytes tragen, ein 2048-Bit-Schlüssel ist länger. Er steht im DNS deshalb zwangsläufig als zwei aneinandergehängte Zeichenketten, und dig zeigt genau das. Das ist kein abgeschnittener Schlüssel – Empfänger setzen die Teile beim Prüfen wieder zusammen. Die meisten DNS-Panels übernehmen die Aufteilung automatisch; verlangt deines den Wert am Stück, trägst du ihn ohne Anführungszeichen und ohne Zeilenumbrüche ein.

Kommt der v=DKIM1; …-Wert zurück, ist der öffentliche Schlüssel veröffentlicht.

Schritt 4: DMARC – Regeln und Berichte

DMARC verbindet SPF und DKIM: Es sagt Empfängern, wie sie mit Mails umgehen sollen, die die Prüfung nicht bestehen, und lässt dir Berichte über die Nutzung deiner Domain schicken. Ein guter Einstiegs-Record:

_dmarc.DEINE_DOMAIN.   TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@DEINE_DOMAIN; adkim=s; aspf=s"

Zerlegt:

• p=quarantine – nicht bestandene Mails sollen in den Spam wandern. Zum Start empfiehlt sich p=none (nur beobachten, nichts aussortieren), damit du erst die Berichte auswertest, bevor du scharf schaltest. Später gehst du auf quarantine und schließlich p=reject.
• rua=mailto:dmarc@DEINE_DOMAIN – an diese Adresse kommen die aggregierten Berichte (lege das Postfach vorher an).
• adkim=s / aspf=s – strenge Ausrichtung (der signierende bzw. sendende Absender muss exakt zur Domain passen). Der Standard laut Spezifikation ist r (relaxed) – dann genügt dieselbe Organisationsdomain, mail.DEINE_DOMAIN und DEINE_DOMAIN gelten also als ausgerichtet. Für einen einzelnen Mailserver, der alles unter derselben Domain versendet, ist s die schärfere und passende Wahl; sobald Dienste auf Subdomains mitsenden, setzt du auf r zurück.

Prüfen:

dig +short TXT _dmarc.DEINE_DOMAIN

"v=DMARC1; p=quarantine; rua=mailto:dmarc@deine-domain.de; adkim=s; aspf=s"

Schritt 5: Alles zusammen testen

Jetzt der Realitätscheck. Drei Werkzeuge – vom Gesamtbild bis zum Einzel-Record:

1. mail-tester.com: Der holistische Test. Öffne die Seite, sie zeigt dir eine Zufalls-Adresse. Schick von deinem neuen Postfach eine ganz normale Mail dorthin und klick auf „Then check your score". Du bekommst eine Wertung von 10/10 aufgeschlüsselt nach SPF, DKIM, DMARC, Reverse DNS, Inhalt und Blocklisten. Alles unter 10 zeigt dir konkret, woran es hakt.

2. Einzel-Validatoren pro Record. Zum gezielten Debuggen prüfst du jeden Baustein separat online: Du gibst deine Domain ein (bei DKIM zusätzlich den Selector, z. B. dkim) und bekommst Syntax, aufgelöste Werte und Warnungen angezeigt:

   • SPF: MXToolbox SPF-Check – zeigt auch, ob du das 10-Lookup-Limit reißt.
   • DKIM: MXToolbox DKIM-Check – Domain und Selector angeben.
   • DMARC: MXToolbox DMARC-Check – prüft Syntax und Policy; der dmarcian DMARC-Inspector zeigt die Policy besonders anschaulich.

3. Gegenprobe per dig: Prüfe alle vier Bausteine noch einmal in einem Rutsch:

   Terminal

   dig +short -x DEINE_SERVER_IP                  # PTR
   dig +short TXT DEINE_DOMAIN | grep spf1        # SPF
   dig +short TXT dkim._domainkey.DEINE_DOMAIN    # DKIM
   dig +short TXT _dmarc.DEINE_DOMAIN             # DMARC

Ein besonders guter Praxistest: Schick eine Mail an ein Gmail-Konto, öffne dort die Mail, und über „Original anzeigen" siehst du direkt SPF: PASS, DKIM: PASS und DMARC: PASS. Erst wenn alle drei auf PASS stehen, bist du auf der sicheren Seite.

Schritt 6: DMARC-Berichte auswerten und scharf schalten

An deine rua-Adresse trudeln nach ein bis zwei Tagen die ersten DMARC-Berichte ein – XML-Dateien von den Empfänger-Servern, die zeigen, welche Quellen unter deiner Domain gesendet haben und ob SPF/DKIM bestanden. Sie sind roh schwer lesbar; ein kostenloser Report-Analyzer macht sie verständlich. Sobald du in den Berichten siehst, dass deine eigenen Mails durchgehend bestehen und keine fremden Quellen auftauchen, erhöhst du die DMARC-Policy schrittweise von p=none über p=quarantine bis p=reject.

Schritt 7: Was Gmail, Yahoo und Outlook.com konkret verlangen

Du musst nicht raten, was „gut genug" ist – die großen Anbieter haben ihre Anforderungen schriftlich festgehalten.

Google und Yahoo, verbindlich seit dem 1. Februar 2024. Für jeden Absender gilt: SPF oder DKIM eingerichtet, gültige Vorwärts- und Rückwärts-DNS-Einträge, TLS beim Transport und eine Spam-Beschwerderate unter 0,3 %. Wer 5.000 Mails oder mehr pro Tag an Gmail- bzw. Yahoo-Konten schickt, muss zusätzlich SPF und DKIM setzen, einen DMARC-Record veröffentlichen (p=none genügt), die From:-Domain mit der SPF- oder der DKIM-Domain ausrichten und bei Werbe- und Abo-Mails eine One-Click-Abmeldung per List-Unsubscribe-Header anbieten.

Microsoft, verbindlich seit dem 5. Mai 2025. Für Outlook.com, Hotmail, Live und MSN gilt dieselbe Schwelle von 5.000 Mails pro Tag: SPF und DKIM müssen bestehen, ein DMARC-Record mit mindestens p=none muss existieren, und die Ausrichtung muss über SPF und/oder DKIM passen. Nicht konforme Mails landeten zunächst im Junk-Ordner; inzwischen weist Microsoft sie direkt im SMTP-Dialog ab:

550 5.7.515 Access denied, sending domain DEINE_DOMAIN does not meet the required authentication level

Ein Detail, das gern übersehen wird: Die Schwelle ist klebrig. Hat eine Domain sie einmal überschritten, gelten die Anforderungen dauerhaft – auch wenn du später wieder deutlich weniger versendest.

Als Selbsthoster wirst du die 5.000er-Marke selten reißen. Trotzdem ist genau das die Messlatte, an der du dich orientieren solltest – und die gute Nachricht: Die Anforderungen sind exakt das, was du in den Schritten 1 bis 4 gebaut hast. Wer PTR, SPF, DKIM und DMARC sauber gesetzt hat, erfüllt die Regeln der drei größten Anbieter, ohne noch einmal nachlegen zu müssen.

Schritt 8: Die IP-Reputation aufwärmen

Perfekte DNS-Records sind die Eintrittskarte – aber große Anbieter vertrauen einer frischen Server-IP trotzdem nicht sofort. Sie beobachten dein Sendeverhalten und bauen über Tage bis Wochen ein Reputationsbild auf. Zwei Dinge helfen entscheidend:

• Klein anfangen, regelmäßig senden. Ein neuer Server, der aus dem Stand hunderte Mails verschickt, sieht aus wie eine Spam-Schleuder. Sende anfangs wenige, echte Mails und steigere langsam. Kontinuität schlägt Menge.
• Nur an existierende Adressen senden. Jede Mail an ein nicht existierendes Postfach (ein „bounce") verschlechtert deine Reputation. Halte deine Empfängerlisten sauber.

Ein Sonderfall ist Microsoft (Outlook, Hotmail, Live): Deren Filter sind bei neuen IPs besonders misstrauisch, selbst bei tadellosen Records. Die Authentifizierung aus Schritt 7 ist dort die Eintrittskarte, ersetzt aber keine Reputation. Hier hilft nur Geduld – und, falls nötig, die Anmeldung zu Microsofts Absender-Programmen (SNDS/JMRP), über die du Einblick und einen Draht zur Reputationsbewertung bekommst.

Wenn es nicht funktioniert

Wartung & Backups

Zustellbarkeit ist Dauerpflege, keine Einmalaktion:

• DMARC-Berichte beobachten. Ein regelmäßiger Blick zeigt sofort, wenn jemand deine Domain missbraucht oder ein eigener Dienst plötzlich durchfällt.
• DKIM-Schlüssel rotieren. Alle ein bis zwei Jahre einen neuen Schlüssel erzeugen (neuer Selector, alten noch eine Weile stehen lassen), um die Sicherheit hochzuhalten.
• Reputation im Blick behalten. Prüfe gelegentlich Blocklisten und das Sendevolumen. Ein plötzlicher Anstieg ausgehender Mails ist fast immer das Zeichen eines gekaperten Kontos.
• Records sichern. SPF-, DKIM- und DMARC-Records gehören in deine Doku bzw. dein Backup – gehen die DKIM-Schlüssel auf dem Server verloren, musst du ohnehin neue erzeugen und den DNS-Record ersetzen (siehe die Backup-Abschnitte der Mailserver-Tutorials).

Sind alle vier Bausteine gesetzt und getestet, hast du die halbe Miete des seriösen Mail-Selbsthostens – den Rest macht ein sauber betriebener, nicht als Spam-Schleuder missbrauchter Server.