Absenderdomain authentifizieren: SPF, DKIM und DMARC einrichten

Um eine Absenderdomain zu authentifizieren, veröffentlichen Sie drei DNS-Einträge, die Gmail, Yahoo, Outlook und jedem anderen empfangenden Server belegen, dass Ihre Nachrichten tatsächlich von Ihnen stammen: SPF listet die Server auf, die für Sie senden dürfen, DKIM fügt jeder Nachricht eine kryptografische Signatur hinzu, und DMARC legt fest, was Empfänger tun sollen, wenn diese Prüfungen fehlschlagen. In einem Durchgang dauert das in der Regel etwa 30 Minuten und ist der wirkungsvollste einzelne Schritt für die Zustellung im Posteingang.

Die Kurzfassung

1. Bestehendes prüfen. Rufen Sie Ihre aktuellen SPF-, DKIM- und DMARC-Einträge ab, damit Sie sie bearbeiten, statt Duplikate anzulegen.
2. Einen SPF-Eintrag veröffentlichen. Ein einzelner TXT-Eintrag im Stammbereich Ihrer Domain, der alle Dienste einbindet, die in Ihrem Namen senden.
3. DKIM veröffentlichen. Den Selector-Eintrag aus Ihrem Dashboard, damit jede Nachricht signiert wird.
4. DMARC mit p=none veröffentlichen. Starten Sie im Überwachungsmodus mit einer Adresse für Berichte.
5. Verifizieren. Führen Sie dig aus, senden Sie dann eine Testnachricht und lesen Sie die Header.
6. Durchsetzen. Werten Sie die Berichte aus und wechseln Sie dann zu p=quarantine und p=reject.

Was bedeutet es, eine Absenderdomain zu authentifizieren?

E-Mail wurde ohne Möglichkeit entworfen, den Absender einer Nachricht zu überprüfen. Jeder kann Ihre Adresse in das Feld „From“ eintragen, weshalb Phishing und Spoofing so verbreitet sind. Die Authentifizierung schließt diese Lücke mit drei einander ergänzenden Prüfungen, die jeweils eine andere Frage für den empfangenden Server beantworten:

• Darf dieser Server für diese Domain senden? Das prüft SPF (Sender Policy Framework, definiert in RFC 7208).
• Stammt die Nachricht tatsächlich von dieser Domain und ist sie unverändert? Das prüft DKIM (DomainKeys Identified Mail, RFC 6376).
• Was soll geschehen, wenn eine der Prüfungen fehlschlägt, und wer erhält den Bericht? Das regelt DMARC (RFC 7489).

Empfänger fassen die drei Ergebnisse zu einem Vertrauenssignal zusammen. Nachrichten, die sich authentifizieren und mit Ihrer From-Domain übereinstimmen, bauen mit der Zeit eine stabile Domain-Reputation auf. Nachrichten, bei denen das nicht der Fall ist, werden gefiltert, verzögert oder abgewiesen, und bei größeren Volumina lehnen die großen Mailbox-Anbieter sie inzwischen sogar direkt ab.

SPF, DKIM und DMARC im Überblick

	SPF	DKIM	DMARC
Was es belegt	Der sendende Server ist für die Domain autorisiert	Die Nachricht wurde von der Domain signiert und unterwegs nicht verändert	Die Prüfungen stimmen mit der sichtbaren From-Domain überein, und es legt die Richtlinie fest
Wo es im DNS liegt	TXT-Eintrag im Stammbereich der Domain	TXT oder CNAME unter selector._domainkey	TXT-Eintrag unter _dmarc
Was geprüft wird	Domain des Return-Path (Envelope-Absender) und sendende IP	Signatur im Header DKIM-Signature	Domain im From-Header im Vergleich zu den SPF- und DKIM-Ergebnissen
Übersteht Weiterleitung?	In der Regel nicht	Ja, wenn der Inhalt nicht verändert wird	Besteht, wenn DKIM besteht und übereinstimmt
Häufigste Fehlerursache	Fehlender Absender oder mehr als 10 Abfragen	Falscher Selector oder fehlerhaft kopierter Schlüssel	Alignment-Abweichung

Vorbereitung: Was Sie brauchen

• Zugriff zum Bearbeiten des DNS der Domain (Registrar, Cloudflare, cPanel oder Ihr DNS-Anbieter).
• Eine Liste aller Dienste, die E-Mails mit Ihrer Domain als Absender versenden: Ihr MigoSMTP-Konto, Ihre Büro-E-Mail (Google Workspace oder Microsoft 365), Ihr CRM, Abrechnungs- und Support-Tools.
• Ein Postfach für den Empfang von DMARC-Berichten, am besten eine eigene Adresse wie dmarc-reports bei Ihrer Domain.
• Die Werte für das SPF-Include und den DKIM-Eintrag von der Seite „Domains“ in Ihrem MigoSMTP-Dashboard.

Schritt 1: Aktuelle Einträge prüfen

Doppelte Einträge sind der häufigste Grund für fehlgeschlagene Authentifizierung. Sehen Sie nach, was bereits veröffentlicht ist, bevor Sie etwas hinzufügen. Unter macOS oder Linux verwenden Sie dig, unter Windows nslookup.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

# Windows
nslookup -type=TXT example.com

Achten Sie auf jeden TXT-Eintrag, der mit v=spf1 beginnt (SPF), und auf jeden Eintrag unter _dmarc, der mit v=DMARC1 beginnt. Wenn einer von beiden existiert, bearbeiten Sie ihn, statt einen weiteren hinzuzufügen.

Schritt 2: SPF-Eintrag hinzufügen

SPF ist ein einzelner TXT-Eintrag im Stammbereich Ihrer Domain. Er listet die Dienste auf, die E-Mails mit Ihrer Domain als Envelope-Absender (Return-Path) versenden dürfen.

Syntax des SPF-Eintrags

v=spf1 include:YOUR-MIGOSMTP-INCLUDE include:_spf.google.com ~all

Bestandteil	Bedeutung
v=spf1	Erforderlich. Kennzeichnet den Eintrag als SPF Version 1.
include:domain	Autorisiert alles, was der SPF-Eintrag dieser Domain selbst autorisiert. Verwenden Sie den Wert aus Ihrem MigoSMTP-Dashboard.
ip4:203.0.113.10	Autorisiert eine bestimmte IPv4-Adresse oder einen Adressbereich. Für IPv6 gilt ip6:.
a, mx	Autorisiert die IPs der A- bzw. MX-Einträge Ihrer Domain.
~all	Soft Fail: Alles, was nicht aufgeführt ist, gilt als verdächtig, wird aber nicht direkt abgelehnt. Üblich, solange Sie noch Absender ergänzen.
-all	Hard Fail: Alles, was nicht aufgeführt ist, ist nicht autorisiert. Verwenden Sie dies, sobald Sie sicher sind, dass jeder Absender eingetragen ist.

Das Limit von 10 Abfragen

Die SPF-Auswertung darf höchstens 10 DNS-Abfragen auslösen. Jedes include, a, mx, exists und redirect zählt mit, einschließlich der Abfragen innerhalb der eingebundenen Einträge. Wird das Limit überschritten, melden Empfänger einen permanenten Fehler, und SPF schlägt für jede Nachricht fehl. Halten Sie die Anzahl niedrig, indem Sie nicht mehr genutzte Dienste entfernen, a und mx bei stabilen Adressen durch explizite ip4-Bereiche ersetzen und selten genutzte Tools auf eine eigene Subdomain verlagern.

Häufige SPF-Fehler

• Zwei SPF-Einträge unter demselben Namen (fassen Sie sie zu einem zusammen).
• Verwendung von +all, was das gesamte Internet autorisiert.
• Der Include-Wert wird mit zusätzlichen Leerzeichen oder ohne Doppelpunkt eingegeben.
• Ein Absender wie ein Abrechnungssystem oder Helpdesk wird vergessen, sodass dessen E-Mails SPF nicht bestehen.
• SPF wird unter dem falschen Namen veröffentlicht, etwa beim www-Host statt im Stammbereich der Domain.

Schritt 3: DKIM-Eintrag veröffentlichen

DKIM fügt jeder Nachricht eine digitale Signatur hinzu. Ihre Versandplattform signiert ausgehende E-Mails mit einem geheimen privaten Schlüssel, und Sie veröffentlichen den passenden öffentlichen Schlüssel im DNS, damit Empfänger die Signatur überprüfen können.

Selectors und wo der Eintrag hingehört

Jeder Schlüssel liegt unter einem Namen, dem sogenannten Selector, in der Form selector._domainkey.yourdomain.com. Mit dem Selector können Sie mehrere Schlüssel gleichzeitig veröffentlichen und ohne Ausfallzeit rotieren. Ihr MigoSMTP-Dashboard zeigt den exakten Namen und Wert für Ihre Domain.

Name:  selector1._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(long public key)

TXT oder CNAME?

Manche Plattformen verlangen, dass Sie den öffentlichen Schlüssel direkt als TXT-Eintrag veröffentlichen. Andere geben Ihnen einen CNAME, der auf einen von ihnen gehosteten Eintrag verweist, sodass sie die Schlüssel für Sie rotieren können. Veröffentlichen Sie genau den Typ, den Ihr Dashboard anzeigt. Wandeln Sie den einen nicht in den anderen um.

Schlüssellänge und Formatierung

• Verwenden Sie 2048-Bit-RSA-Schlüssel, wenn verfügbar. 1024-Bit-Schlüssel werden von vielen Empfängern noch akzeptiert, gelten aber als schwach.
• Ein 2048-Bit-Schlüssel ist länger als 255 Zeichen, und ein einzelner DNS-String darf 255 Zeichen nicht überschreiten. Ihr DNS-Anbieter muss den Wert innerhalb eines TXT-Eintrags auf mehrere Strings in Anführungszeichen aufteilen. Die meisten Dashboards erledigen das automatisch; falls Ihres es nicht tut, teilen Sie den Wert manuell auf.
• Kopieren Sie den Wert ohne zusätzliche Zeilenumbrüche oder typografische Anführungszeichen, und setzen Sie ihn nicht in zusätzliche Anführungszeichen, es sei denn, Ihr DNS-Anbieter verlangt dies.

Rotation

Rotieren Sie DKIM-Schlüssel alle sechs bis zwölf Monate oder sofort, falls ein privater Schlüssel kompromittiert worden sein könnte. Veröffentlichen Sie zuerst den neuen Selector, stellen Sie das Signieren darauf um und löschen Sie den alten Selector erst, wenn alle damit signierten Nachrichten zugestellt wurden.

Schritt 4: DMARC-Eintrag veröffentlichen

DMARC verknüpft SPF und DKIM mit der Domain, die Ihre Empfänger tatsächlich in der From-Zeile sehen, und teilt Empfängern mit, wie sie mit fehlgeschlagenen Nachrichten umgehen sollen. Es ist ein TXT-Eintrag unter _dmarc.yourdomain.com. Beginnen Sie im Überwachungsmodus, damit Sie sehen, wer in Ihrem Namen sendet, bevor Sie etwas durchsetzen.

Name:  _dmarc.example.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

Tag	Funktion	Typischer Wert
v	Version. Muss an erster Stelle stehen.	DMARC1
p	Richtlinie für fehlgeschlagene Nachrichten: none (überwachen), quarantine (Spam-Ordner) oder reject (abweisen).	zunächst none
rua	Ziel für die täglichen Aggregatberichte.	mailto:dmarc-reports@example.com
ruf	Ziel für Fehlerproben. Nur wenige Empfänger senden diese.	Optional
pct	Prozentsatz der fehlgeschlagenen Nachrichten, auf den die Richtlinie angewendet wird; wird beim schrittweisen Rollout genutzt.	25, 50, 100
sp	Richtlinie für Subdomains, falls sie von der übergeordneten Domain abweicht.	Wie p, sofern nicht anders nötig
adkim, aspf	Alignment-Modus: r (relaxed) oder s (strict).	r (relaxed) ist der Standard
fo	Wann Fehlerberichte erzeugt werden.	1

Was „Alignment“ wirklich bedeutet

DMARC besteht, wenn SPF oder DKIM besteht und die bestandene Domain mit der From-Domain übereinstimmt. Beim relaxed Alignment gilt eine Subdomain der From-Domain als übereinstimmend; ein Return-Path von bounce.example.com passt also zu einem From von news@example.com. Beim strict Alignment müssen die Domains exakt identisch sein. Die häufigste Ursache für „SPF besteht, aber DMARC schlägt fehl“ ist ein Return-Path oder eine DKIM-Domain, die Ihrer Versandplattform gehört statt Ihnen. Aktivieren Sie einen benutzerdefinierten Return-Path und Ihre eigene DKIM-Signaturdomain, um das zu beheben.

Schritt 5: Prüfen, ob alles funktioniert

Einträge im DNS prüfen

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Jeder Befehl sollte den von Ihnen veröffentlichten Eintrag zurückgeben. Wenn nichts zurückkommt, liegt der Eintrag unter dem falschen Namen oder ist noch nicht propagiert. Warten Sie, bis die TTL abgelaufen ist, und testen Sie erneut.

Testnachricht senden und Header lesen

1. Senden Sie eine Nachricht von Ihrer authentifizierten Domain an eine Gmail-Adresse, die Sie kontrollieren.
2. Öffnen Sie die Nachricht, wählen Sie das Drei-Punkte-Menü und klicken Sie auf Original anzeigen.
3. Oben sehen Sie SPF, DKIM und DMARC mit jeweils PASS oder FAIL.
4. Prüfen Sie, ob die neben jedem PASS angezeigte Domain mit Ihrer From-Domain übereinstimmt.

DMARC sicher ausrollen: von p=none zu p=reject

Das Ziel ist p=reject, denn nur diese Richtlinie verhindert, dass andere Ihre Domain fälschen. Wer aber blind dorthin springt, kann legitime E-Mails von Tools blockieren, die er vergessen hat. Gehen Sie in Stufen vor und lassen Sie sich von den Berichten leiten.

Stufe	Richtlinie	Dauer	Was zu tun ist
1. Überwachen	p=none	2 bis 4 Wochen	Aggregatberichte lesen. Alle Quellen auflisten, die in Ihrem Namen senden, und jede legitime korrigieren oder autorisieren.
2. Teilweise Quarantäne	p=quarantine; pct=25	1 bis 2 Wochen	Fehlgeschlagene E-Mails von 25 Prozent des Datenverkehrs landen im Spam. Achten Sie auf Beschwerden über fehlende E-Mails.
3. Volle Quarantäne	p=quarantine	2 Wochen	pct auf 100 erhöhen, sobald die Berichte zeigen, dass nur nicht autorisierte Quellen fehlschlagen.
4. Reject	p=reject	Dauerhaft	Auf reject umstellen, optional mit schrittweiser Erhöhung von pct. Berichte weiterhin monatlich auswerten.

DMARC-Aggregatberichte kommen als komprimierte XML-Dateien an und sind nicht zum manuellen Lesen gedacht. Verwenden Sie einen kostenlosen oder kostenpflichtigen DMARC-Berichtsanalysator, um sie in eine Tabelle mit Absenderquellen, Volumen und Ergebnissen (bestanden oder fehlgeschlagen) zu verwandeln.

Anforderungen von Gmail, Yahoo und Microsoft an Bulk-Sender

Seit Februar 2024 setzen Gmail und Yahoo Authentifizierungs- und Abmelderegeln für alle durch, die in größeren Mengen senden, und Microsoft wendet seit Mai 2025 vergleichbare Anforderungen auf Outlook.com-Verbraucherpostfächer an. Zusammengefasst:

Anforderung	Alle Absender	Bulk-Sender (etwa 5.000+ Nachrichten pro Tag an den Anbieter)
SPF oder DKIM	Erforderlich	Beides erforderlich
DMARC-Eintrag	Empfohlen	Erforderlich, mindestens p=none, mit From abgestimmt
Ein-Klick-Abmeldung	Für Transaktions-E-Mails nicht erforderlich	Erforderlich für Marketing- und abonnierte E-Mails (RFC-8058-Header); Anfragen innerhalb von zwei Tagen bearbeiten
Spam-Beschwerderate	Niedrig halten	Unter 0,10 Prozent bleiben und nie 0,30 Prozent erreichen (Google Postmaster Tools)
Gültiges Forward- und Reverse-DNS, TLS	Erforderlich	Erforderlich

Anbieter können Schwellenwerte ändern, prüfen Sie daher deren aktuelle Absenderrichtlinien. Die Links finden Sie in der Quellenliste am Ende dieser Anleitung.

Marketing- und Transaktions-E-Mails über Subdomains trennen

Die Reputation wird pro sendender Domain und IP erfasst. Wenn eine Werbekampagne Beschwerden auslöst, sollen Ihre Passwort-Rücksetzungs-E-Mails nicht im Spam landen. Üblich ist eine Subdomain pro Strom:

Strom	Beispiel-From-Adresse	Warum getrennt
Transaktional	noreply@mail.example.com	Muss immer schnell ankommen. Geringes Volumen und hohe Interaktion halten die Reputation hoch.
Marketing	hello@news.example.com	Höheres Volumen und mehr Beschwerden. Probleme bleiben begrenzt.
Unternehmens-E-Mail	name@example.com	Die Postfächer Ihrer Mitarbeitenden bleiben vom Risiko des Massenversands unberührt.

Jede Subdomain benötigt eigene SPF- und DKIM-Einträge. Ein DMARC-Eintrag auf der übergeordneten Domain schützt Subdomains standardmäßig; fügen Sie ein sp=-Tag oder einen separaten Eintrag auf der Subdomain hinzu, wenn Sie eine andere Richtlinie benötigen.

Häufige Authentifizierungsfehler und ihre Behebung

Symptom	Wahrscheinliche Ursache	Lösung
SPF permerror oder „too many DNS lookups“	Mehr als 10 Abfragen oder ein Syntaxfehler	Nicht benötigte Includes entfernen, stabile Bereiche zu ip4 auflösen, selten genutzte Absender auf eine Subdomain verlagern.
Multiple SPF records found	Zwei TXT-Einträge beginnen mit v=spf1	Zu einem einzigen Eintrag zusammenführen.
DKIM: no key for signature	Selector-Name falsch oder Eintrag nicht veröffentlicht	Selector im Header DKIM-Signature prüfen und mit Ihrem DNS-Namen vergleichen.
DKIM: body hash did not verify	Nachricht wurde nach dem Signieren verändert (Fußzeilen, Link-Umschreibung durch ein anderes System)	Den verändernden Schritt deaktivieren oder vor das Signieren verlegen.
DMARC fail bei SPF pass	Return-Path-Domain stimmt nicht mit From überein	Einen benutzerdefinierten Return-Path auf Ihrer eigenen Domain verwenden.
DMARC fail bei DKIM pass	DKIM-d=-Domain stimmt nicht mit From überein	Mit Ihrer eigenen Domain signieren, nicht mit der Plattform-Standarddomain.
Record not found	Falscher Hostname, ein abschließender Punkt oder die Domain wird von Ihrem DNS-Panel doppelt angehängt	Viele Panels hängen die Domain automatisch an. Geben Sie nur den Teil davor ein, zum Beispiel selector1._domainkey.
Einträge werden nicht aktualisiert	Alter Eintrag im Cache	Warten, bis die TTL abgelaufen ist. Die TTL vor geplanten Änderungen senken.

Checkliste zur Authentifizierung

• Ein SPF-Eintrag im Stammbereich der Domain, unter 10 Abfragen, endend auf ~all oder -all.
• DKIM-Selector-Eintrag veröffentlicht, 2048 Bit, sofern Ihr DNS-Anbieter es zulässt.
• DMARC-Eintrag unter _dmarc mit p=none und einer funktionierenden rua-Adresse.
• Benutzerdefinierter Return-Path und DKIM-Domain, sodass beide mit Ihrer From-Domain übereinstimmen.
• Die Testnachricht zeigt SPF, DKIM und DMARC als PASS.
• DMARC-Berichte werden während des Rollouts wöchentlich ausgewertet.
• Marketing- und Transaktions-E-Mails sind per Subdomain getrennt.
• Kalendererinnerung zum Rotieren der DKIM-Schlüssel.

Weiterführende Lektüre und Quellen

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC)
• RFC 8058: Signaling One-Click Functionality for List Email Headers
• Google: Email sender guidelines
• Yahoo: Sender best practices
• Verwandte Anleitungen: Anleitung zum E-Mail-Warm-up und SMTP-Bounce-Codes erklärt.