Eigene Sendedomains schützen die Reputation jedes einzelnen Kunden

Wer E-Mails für mehrere Kundenwebsites über denselben Versanddienst verschickt, wie es Agenturen mit Versanddiensten wie Resend, Mailgun oder Mailjet häufig tun, muss für jede Absenderdomain drei DNS-Einträge korrekt setzen. SPF (Sender Policy Framework) listet die Server, die im Namen einer Domain senden dürfen. DKIM (DomainKeys Identified Mail) hängt jeder Nachricht eine kryptografische Signatur an, die belegt, dass sie unverändert von dieser Domain stammt. DMARC (Domain-based Message Authentication, Reporting and Conformance) legt fest, was ein Empfänger mit einer Nachricht tun soll, die eine der beiden Prüfungen nicht besteht, und wohin er darüber berichtet. Fehlt einer dieser drei Einträge oder stimmt er nicht, landen Nachrichten im Spam-Ordner oder werden abgelehnt.

Die eigentliche Weichenstellung betrifft die Frage, über welche Domain die drei Einträge laufen. Senden zwanzig Kunden über eine gemeinsame Absenderdomain wie newsletter@agentur-beispiel.de, teilen sich alle zwanzig auch eine einzige Sender-Reputation bei Gmail, Outlook und Yahoo. Meldet ein einziger Kunde mit einer veralteten oder gekauften Empfängerliste gehäuft Spam-Beschwerden, sinkt die Zustellrate für die anderen neunzehn Kunden auf derselben Domain gleich mit, ganz ohne eigenes Verschulden. Eine eigene Sendedomain je Kunde, etwa kunde-a.mail.agentur-beispiel.de statt der gemeinsamen Hauptdomain, begrenzt diesen Schaden auf genau den einen Kunden.

Systemvoraussetzungen

Vier DNS-Einträge sind für jede Sendedomain nötig, unabhängig davon, ob dahinter ein einzelner Kunde oder die gesamte Agentur steht. Alle vier werden als Eintrag beim DNS-Anbieter der jeweiligen Domain angelegt, meist über dieselbe Oberfläche wie A- oder CNAME-Einträge.

DNS-Eintrag	Typ	Host (Beispiel)	Zweck
SPF	TXT	mail.agentur-beispiel.de	Legt fest, welche Server im Namen dieser Domain senden dürfen
DKIM	TXT	resend._domainkey.mail.agentur-beispiel.de	Veröffentlicht den öffentlichen Schlüssel zur Signaturprüfung
DMARC	TXT	_dmarc.agentur-beispiel.de	Bestimmt die Richtlinie für nicht bestandene Prüfungen und das Ziel der Berichte
MX (Rücklauf)	MX	mail.agentur-beispiel.de	Nimmt Bounce- und Beschwerdemeldungen für die Rücksendeadresse der Subdomain entgegen

Der DMARC-Eintrag steht immer auf der Stammdomain der jeweiligen Sendedomain unter dem festen Präfix _dmarc, auch wenn tatsächlich über eine Subdomain gesendet wird. Eine Agentur mit zehn Kunden und zehn eigenen Sendedomains braucht deshalb zehn separate DMARC-Einträge, einen je Kundendomain, nicht einen gemeinsamen für die Agentur-Hauptdomain.

Systemarchitektur

flowchart TD
    A[Kunde sendet Kampagne ueber kunde-a.mail.agentur-beispiel.de] --> B[Versanddienst signiert die Nachricht mit dem DKIM-Schluessel der Subdomain]
    B --> C[Nachricht erreicht den Mailserver des Empfaengers]
    C --> D[Empfaenger prueft SPF fuer die sendende IP-Adresse]
    C --> E[Empfaenger prueft die DKIM-Signatur gegen den oeffentlichen Schluessel im DNS]
    D --> F[Empfaenger prueft die DMARC-Ausrichtung zwischen SPF, DKIM und der sichtbaren Absenderdomain]
    E --> F
    F --> G{Pruefung bestanden}
    G -->|Ja| H[Zustellung in den Posteingang]
    G -->|Nein, Richtlinie quarantine| I[Zustellung in den Spam-Ordner]
    G -->|Nein, Richtlinie reject| J[Nachricht wird abgelehnt]
    F --> K[Zusammenfassender Bericht geht an die hinterlegte Berichtsadresse]

Ein empfangender Mailserver prüft eine eingehende Nachricht in dieser Reihenfolge, sobald sie ankommt. Zuerst prüft er SPF: Er liest die Absenderdomain aus dem unsichtbaren Envelope-From, dem technischen Rücksendepfad einer Nachricht, und vergleicht die sendende IP-Adresse mit der Liste im SPF-Eintrag dieser Domain. SPF prüft dabei nicht die sichtbare Absenderadresse im From-Feld des Postfachs, sondern ausschließlich diese unsichtbare Envelope-Adresse, ein Punkt, an dem viele Einrichtungen scheitern. Parallel dazu prüft der Server die DKIM-Signatur: Er liest den Selektor aus dem Signatur-Header der Nachricht, holt sich den passenden öffentlichen Schlüssel unter selektor._domainkey.domain.de aus dem DNS und rechnet damit nach, ob der signierte Hash noch zum tatsächlichen Nachrichteninhalt passt.

Erst danach kommt DMARC ins Spiel. DMARC prüft die Ausrichtung (Alignment) zwischen der Domain, die SPF oder DKIM bestätigt hat, und der Domain, die im sichtbaren From-Feld steht. Aligned signing bedeutet, dass die im DKIM-Signatur-Header angegebene Domain (d=) mit der sichtbaren Absenderdomain übereinstimmt. Der Tag adkim steuert, wie genau diese Übereinstimmung sein muss: adkim=r (relaxed, der Normalfall) genügt eine Übereinstimmung auf Ebene der organisatorischen Domain, sodass mail.agentur-beispiel.de zu agentur-beispiel.de passt; adkim=s (strict) verlangt exakt dieselbe Domain. Der Tag aspf regelt dieselbe Frage für SPF. Erst wenn mindestens eine der beiden Prüfungen ausgerichtet ist, gilt DMARC insgesamt als bestanden, und der Empfänger liefert die Nachricht gemäß der hinterlegten Richtlinie zu, verschiebt sie in den Spam-Ordner oder weist sie zurück.

Schritt-für-Schritt-Umsetzung

Der Aufbau einer eigenen Sendedomain für einen einzelnen Kunden läuft in der folgenden Reihenfolge ab, unabhängig davon, ob der Versanddienst Resend, Mailgun oder Mailjet heißt. Die Dashboards unterscheiden sich, die verlangten DNS-Einträge sind sich in Struktur sehr ähnlich.

1. Eine eigene Subdomain für den Kunden festlegen, zum Beispiel kunde-a.mail.agentur-beispiel.de.
2. Diese Subdomain beim Versanddienst als neue Absenderdomain anlegen und die dort angezeigten Einträge übernehmen.
3. SPF-, DKIM- und MX-Eintrag für die Subdomain im DNS des Kunden oder der Agentur veröffentlichen.
4. Eine eigene DMARC-Richtlinie für diese Subdomain setzen, zunächst mit der Richtlinie none zur reinen Beobachtung.
5. Nach zwei bis vier Wochen ohne auffällige Berichte die Richtlinie auf quarantine oder reject verschärfen.

Sendedomain beim Versanddienst anlegen

Im Dashboard des Versanddienstes wird die neue Subdomain als Absenderdomain hinterlegt, nicht die Hauptdomain der Agentur. Resend etwa verwendet dafür standardmäßig eine Subdomain nach dem Muster send.domain.de und rät ausdrücklich dazu, für den eigentlichen Versand eine Subdomain statt der Root-Domain zu nutzen. Nach dem Anlegen zeigt das Dashboard die drei bis vier konkreten DNS-Einträge an, die im nächsten Schritt veröffentlicht werden.

SPF-Eintrag für die Subdomain veröffentlichen

Der SPF-Eintrag steht als TXT-Eintrag direkt auf der Sendedomain und verweist per include-Mechanismus auf die Infrastruktur des Versanddienstes, hier am Beispiel eines auf Amazon SES aufsetzenden Versanddienstes:

Host: mail.agentur-beispiel.de
Typ: TXT
Wert: v=spf1 include:amazonses.com ~all

Der Qualifizierer ~all am Ende steht für Softfail: Eine Nachricht von einem nicht gelisteten Server wird trotzdem angenommen, aber mit einer niedrigeren Vertrauensstufe versehen. Der schärfere Qualifizierer -all (Hardfail) erlaubt dem Empfänger, eine solche Nachricht direkt abzulehnen. Für eine frisch eingerichtete Sendedomain ist ~all die vorsichtigere Wahl, weil ein zunächst übersehener, aber legitimer Versandweg die Zustellung nicht sofort blockiert; nach einer Beobachtungsphase ohne Fehlversand lässt sich auf -all verschärfen.

DKIM-Selektor im DNS veröffentlichen

Ein DKIM-Selektor ist der Name, unter dem ein bestimmter öffentlicher Schlüssel im DNS zu finden ist; ein und dieselbe Domain kann mehrere Selektoren gleichzeitig führen, etwa weil mehrere Versanddienste parallel senden oder weil ein Schlüssel gerade rotiert wird. Der Selektor steht als eigenes Wort vor dem festen Anteil _domainkey in der Host-Angabe:

Host: resend._domainkey.mail.agentur-beispiel.de
Typ: TXT
Wert: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7... (vom Versanddienst erzeugt, ungekuerzt einfuegen)

Der Wert hinter p= ist der öffentliche Schlüssel im Base64-Format; er wird vom Versanddienst erzeugt und muss unverändert und vollständig übernommen werden, weil bereits ein fehlendes Zeichen die Signaturprüfung scheitern lässt. Der Name vor _domainkey, hier resend, ist der eigentliche Selektor und steht so im DKIM-Signatur-Header jeder ausgehenden Nachricht.

DMARC-Richtlinie mit Berichtsadresse einrichten

Host: _dmarc.agentur-beispiel.de
Typ: TXT
Wert: v=DMARC1; p=quarantine; rua=mailto:dmarc-berichte@agentur-beispiel.de; adkim=r; aspf=r; pct=100

Die Richtlinie p=quarantine weist Empfänger an, eine nicht ausgerichtete Nachricht in den Spam- oder Junk-Ordner zu verschieben statt sie normal zuzustellen oder ganz abzulehnen. p=none verlangt gar keine Reaktion und eignet sich nur für die anfängliche Beobachtungsphase; p=reject weist den Empfänger an, die Nachricht komplett zurückzuweisen, und ist die Zielstufe für eine eingespielte Sendedomain. Die rua-Adresse ist das Postfach oder der Dienst, an das große Mailbox-Anbieter täglich einen zusammengefassten Bericht über alle SPF- und DKIM-Ergebnisse schicken, die sie für Nachrichten von dieser Domain gesehen haben. pct=100 legt fest, dass die Richtlinie auf alle Nachrichten angewendet wird; während der Einführung senken manche Teams diesen Wert schrittweise, um das Risiko eines Fehlversands zu begrenzen.

Häufige Fehlerquellen

• Alle Kunden senden trotz getrennter Absicht über dieselbe Hauptdomain, weil die Subdomain nur im Anzeigenamen, nicht aber in der tatsächlichen Absenderadresse gesetzt wurde. Symptom: Eine Spam-Meldung bei einem Kunden senkt sichtbar die Zustellrate aller anderen Kunden gleichzeitig. Fix: jeden Kunden auf eine eigene Subdomain mit eigenem SPF-, DKIM- und DMARC-Eintrag umziehen.
• Der DKIM-Selektor im DNS weicht vom Selektor ab, den der Versanddienst tatsächlich in den Signatur-Header schreibt, oft nach einem Anbieterwechsel. Symptom: DMARC-Berichte zeigen für sämtliche Nachrichten DKIM=fail, obwohl im DNS ein gültiger Eintrag liegt. Fix: den exakten Selektor-Namen im Dashboard des aktuellen Versanddienstes nachsehen und den DNS-Eintrag darauf angleichen.
• Für dieselbe Domain existieren zwei SPF-TXT-Einträge, weil ein alter Eintrag beim Anbieterwechsel nicht gelöscht wurde. Symptom: SPF liefert einen Permerror, weil pro Domain nur genau ein SPF-Eintrag zulässig ist. Fix: beide Mechanismen in einem einzigen Eintrag mit einem gemeinsamen include zusammenführen.
• Der DMARC-Eintrag hat keine rua-Adresse hinterlegt. Symptom: Ein gebrochenes DKIM oder ein falsch konfiguriertes SPF fällt erst auf, wenn Kunden sich über ausbleibende E-Mails beschweren, nicht schon Tage vorher im Bericht. Fix: rua immer mit einer überwachten Adresse setzen, auch während der Richtlinie none.
• Die DMARC-Richtlinie wird direkt mit p=reject und adkim=s/aspf=s scharf geschaltet, bevor die Ausrichtung geprüft wurde. Symptom: Legitime Nachrichten aus Zusatzsystemen, etwa einer Support-Software, die im Namen derselben Domain sendet, werden plötzlich abgelehnt. Fix: mit p=none beginnen, zwei bis vier Wochen Berichte auswerten, erst danach schrittweise auf quarantine und reject verschärfen.
• Der lange DKIM-Schlüssel wurde beim Kopieren in mehrere DNS-Textzeilen zerlegt, aber mit falschen Anführungszeichen oder zusätzlichen Leerzeichen zwischen den Teilen. Symptom: Der öffentliche Schlüssel lässt sich nicht mehr zu einem gültigen Base64-Wert zusammensetzen, jede Signaturprüfung schlägt fehl. Fix: den Wert exakt so einfügen, wie ihn das Dashboard des Versanddienstes anzeigt, ohne manuelle Zeilenumbrüche.

Häufig gestellte Fragen

Was bedeutet der SPF-Qualifizierer ~all im Unterschied zu -all?

Der SPF-Qualifizierer ~all markiert nicht gelistete Server als Softfail, während -all sie als Hardfail einstuft. Bei ~all nimmt der empfangende Mailserver eine Nachricht von einem nicht autorisierten Server trotzdem an, versieht sie aber mit einer niedrigeren Vertrauensstufe und häufig mit zusätzlichen Spam-Punkten. Bei -all darf der Empfänger die Nachricht direkt ablehnen, weil die Domain ausdrücklich erklärt hat, dass kein anderer Server in ihrem Namen senden darf. Für eine neu eingerichtete Sendedomain ist ~all deshalb die vorsichtigere Startposition, bevor nach einer Beobachtungsphase auf -all verschärft wird.

Wie schützt eine eigene Subdomain pro Kunde vor einer schlechten Absenderreputation?

Eine eigene Subdomain pro Kunde schützt vor einer schlechten Absenderreputation, weil Mailbox-Anbieter die Zustellhistorie einer Subdomain getrennt von der Stammdomain und von anderen Subdomains derselben Agentur führen, sofern DKIM auch tatsächlich mit dem Schlüssel dieser Subdomain signiert. Verschickt ein Kunde an eine veraltete oder gekaufte Empfängerliste und häufen sich Spam-Meldungen, bleibt der Schaden auf dessen eigene Subdomain begrenzt. Die übrigen Kunden senden über ihre eigenen Subdomains unverändert weiter, weil ihre Zustellhistorie eine andere ist. Eine gemeinsame Domain für alle Kunden hätte denselben Vorfall stattdessen auf die Zustellrate sämtlicher Kunden durchschlagen lassen.

Welche Anforderungen stellen Google und Yahoo seit 2024 an Massenversender?

Google und Yahoo verlangen seit Februar 2024 von jedem Absender, der an einem Tag etwa 5.000 oder mehr Nachrichten an private Gmail- beziehungsweise Yahoo-Adressen schickt, gültige SPF- und DKIM-Einträge sowie eine DMARC-Richtlinie von mindestens p=none. Dazu kommt eine feste Obergrenze für die Beschwerdequote von 0,3 Prozent; wird sie überschritten, drohen Zurückweisungen oder eine dauerhafte Einstufung als Spam. Marketing- und Massen-Nachrichten brauchen zusätzlich eine Ein-Klick-Abmeldung nach RFC 8058, deren Anfragen innerhalb von 48 Stunden bei Google und innerhalb von zwei Tagen bei Yahoo umgesetzt werden müssen. Läuft der Versand für mehrere Kunden über eine gemeinsame Domain, zählt deren Gesamtvolumen für diese Schwelle zusammen, sodass eine geteilte Domain die Grenze oft früher erreicht als jeder einzelne Kunde für sich.

Wie erkennt man anhand eines DMARC-Berichts eine fehlerhafte DKIM-Signatur?

Eine fehlerhafte DKIM-Signatur zeigt sich in einem DMARC-Aggregatbericht daran, dass die aufgeführten sendenden IP-Adressen in der Spalte für DKIM durchgängig fail statt pass melden, während SPF für dieselben Nachrichten weiterhin besteht. Die Berichte werden von großen Mailbox-Anbietern regelmäßig als XML-Datei an die im DMARC-Eintrag hinterlegte rua-Adresse geschickt und listen je Absender-IP die Anzahl der Nachrichten sowie das Ergebnis von SPF- und DKIM-Prüfung auf. Ein durchgängiger DKIM-Fail bei gleichzeitigem SPF-Pass deutet meist auf einen veralteten oder falschen Selektor, einen unvollständig kopierten Schlüssel oder eine Nachricht hin, die nach der Signatur noch verändert wurde. In der Praxis zeigt sich ein gebrochenes DKIM häufig zuerst dadurch, dass Nachrichten vermehrt im Spam-Ordner landen oder von Gmail mit dem Fehlercode 5.7.26 zurückgewiesen werden, bevor der Bericht die genaue Ursache bestätigt.