Deliverability

SPF vs DKIM vs DMARC: Was ist der Unterschied?

SPF autorisiert sendende Server, DKIM verifiziert signierte Nachrichteninhalte und DMARC prüft die Übereinstimmung mit der sichtbaren From-Domain und veröffentlicht Fehlerrichtlinien sowie Reporting-Einstellungen.

Ein autorisierter Server kann eine unerwünschte Nachricht senden. Eine gültige Signatur kann zu einer anderen Domain gehören als der, die dem Empfänger angezeigt wird. Jede Prüfung beantwortet eine andere Frage zur Nachricht.

Was beweist jede Prüfung?

SPF prüft die sendende IP, DKIM prüft eine Signatur und DMARC verbindet ein bestandenes Ergebnis mit der sichtbaren From-Domain.

PrüfungGeprüfte IdentitätWas ein Pass belegtWas er nicht belegt
SPFEnvelope-From-Domain, üblicherweise für Bounces verwendetDie verbindende IP ist durch die Richtlinie dieser Domain autorisiert.Die sichtbare From-Domain oder die Integrität der Nachricht.
DKIMSignierende Domain im d=-Wert der SignaturDie Signatur lässt sich gegen den veröffentlichten Schlüssel und die signierten Inhalte verifizieren.Dass jeder Teil der Nachricht signiert wurde oder dass Empfänger sie wünschen.
DMARCSichtbare From-DomainMindestens ein bestandenes SPF- oder DKIM-Ergebnis stimmt mit dieser Domain überein.Garantierte Zustellung oder Inbox-Platzierung.

Wie funktioniert SPF?

Der Empfänger vergleicht die IP des verbindenden Servers mit der im DNS veröffentlichten SPF-Richtlinie für die Envelope-From-Domain. Diese Prüfung kann vor dem Empfang des Nachrichtentexts erfolgen, weil SPF den Inhalt nicht untersucht.

  1. Sie veröffentlichen die Server oder Dienste, die zur Nutzung dieser Domain autorisiert sind.
  2. Der Empfänger ruft die Richtlinie ab und wertet ihre Regeln gegen die verbindende IP aus.
  3. Der Empfänger verwendet das Ergebnis zusammen mit seiner eigenen Annahme- und Filterrichtlinie.

Wenn ein Alumni-Postfach eine Nachricht an einen anderen Anbieter weiterleitet, ohne die Envelope-From-Adresse zu ändern, fehlt der weiterleitenden IP möglicherweise die Autorisierung. Eine Mailingliste kann dasselbe Problem verursachen, wenn sie eine Nachricht erneut sendet. Ein Weiterleitungsdienst kann Sender Rewriting Scheme (SRS) verwenden, das die Envelope-From-Adresse auf eine authentifizierbare Domain ändert.

Ein SPF-Record legt autorisierte Absender fest. Verschachtelte Anbieterrichtlinien zählen zum DNS-Lookup-Limit.

Wie funktioniert DKIM?

Ihr sendender Server signiert den Nachrichteninhalt mit einem privaten Schlüssel. Der Empfänger verwendet den zugehörigen öffentlichen Schlüssel im DNS, um die Signatur zu verifizieren.

Die Signatur identifiziert die signierende Domain mit d= und den Schlüsselselektor mit s=. Der Selektor gibt an, welcher DNS-Record den öffentlichen Schlüssel enthält. Der Empfänger ruft den öffentlichen Schlüssel ab und verifiziert die Signatur anhand dieser Domain und dieses Selektors.

Weiterleitung allein macht DKIM nicht ungültig, weil die Prüfung nicht von der IP des weiterleitenden Servers abhängt. Änderungen an signierten Inhalten, etwa das Hinzufügen eines Mailinglisten-Footers, können die Signatur ungültig machen. Die Signatur authentifiziert die Inhalte, die sie abdeckt; sie verschlüsselt die Nachricht nicht.

Wie verbindet DMARC die Identitäten?

DMARC erfordert ein bestandenes SPF- oder DKIM-Ergebnis, dessen Domain mit der sichtbaren From-Domain übereinstimmt. Ein einzelner übereinstimmender Pass genügt.

Beispiel: Eine Nachricht mit From: billing@example.com kann SPF für send.example.com unter entspannter Übereinstimmung bestehen. Eine bestandene DKIM-Signatur mit d=example.com stimmt ebenfalls überein. Authentifizierung für unrelated.example stimmt nicht mit example.com überein, nur weil sie besteht.

Sie veröffentlichen eine DMARC-Richtlinie, um die Behandlung fehlgeschlagener Nachrichten und Authentifizierungsberichte anzufordern. Teilnehmende Empfänger liefern Berichte; deren Fehlen beweist nicht, dass keine Mail Ihre Domain verwendet hat.

Was sollten Sie für Bird konfigurieren?

Sie veröffentlichen DKIM, den Return-Path-CNAME und DMARC für Ihre Sendedomain. Der Return-Path-CNAME verweist auf die Bounce-Infrastruktur von Bird, die SPF-Autorisierung ohne einen zusätzlichen Apex-SPF-Record bereitstellt.

Kopieren Sie die Records aus dns_records. Prüfen Sie capabilities.sending.status auf Sendebereitschaft. Die Werte zeigen, was als Nächstes zu tun ist:

StatusBedeutung und Aktion
pendingDie Verifizierung wurde noch nicht ausgeführt oder läuft gerade; warten Sie auf das Ergebnis.
verifiedDie DNS-Records der Fähigkeit stimmen mit den erwarteten Werten überein.
warningZuvor verifizierte Records stimmen nicht mehr überein; korrigieren Sie sie, bevor die Kulanzfrist endet. Der Versand ist noch nicht betroffen.
failedEin DNS-Wert ist falsch; korrigieren Sie ihn.
temporary_failureEin DNS-Lookup ist vorübergehend fehlgeschlagen; die Verifizierung wird automatisch erneut versucht.
not_configuredDie Fähigkeit ist für diese Domain nicht eingerichtet.

Sie veröffentlichen die Authentifizierungs-Records und verifizieren Ihre Sendedomain.

Welche Prüfungen sollten Sie verwenden?

Verwenden Sie SPF und DKIM zusammen mit DMARC, damit die authentifizierten Identitäten mit der Domain übereinstimmen, die Ihre Empfänger sehen.

  1. Autorisieren Sie die Sendeinfrastruktur der Envelope-From-Domain mit SPF.
  2. Signieren Sie ausgehende Nachrichten mit DKIM und veröffentlichen Sie den Verifizierungsschlüssel.
  3. Veröffentlichen Sie DMARC, prüfen Sie gemeldete Authentifizierungsfehler und korrigieren Sie legitime Absender, bevor Sie Quarantäne oder Ablehnung durchsetzen.

In die Praxis umsetzen.

Weiter mit der Dokumentation, Anleitungen und Beispielen zu diesem Thema. Die Ressourcen sind auf Englisch.

Implementierungs-Briefing erhalten

Bauen Sie auf demselben Netzwerk auf.

Ein Test-API-Schlüssel steht Ihnen sofort zur Verfügung. Der Produktivbetrieb wird freigeschaltet, sobald Sie eine Zahlungsmethode hinzufügen und einen Absender verifizieren.

Ihre nächste Idee.
Bereit zur Verbindung.