E-Mail-Authentifizierung besteht aus drei Verfahren – SPF, DKIM und DMARC. Es sind drei Einträge im DNS Ihrer Domain, mit denen Sie beweisen, dass eine E-Mail wirklich von Ihnen stammt. Fehlen sie, kann jeder in Ihrem Namen senden, und Ihre eigenen Nachrichten landen schneller im Spam.
Inhalt
Seit Google und Yahoo (2024) und Microsoft (Mai 2025) ihre Anforderungen an Absender verschärft haben, entscheiden diese drei Verfahren mit darüber, ob Ihre E-Mails im Postfach ankommen. Wir betreuen seit über 30 Jahren KMU aus dem Raum Köln/Bonn – und sehen bei neuen Kunden fast immer denselben Befund: SPF ist halb gesetzt, DKIM fehlt, DMARC gibt es gar nicht. Dieser Artikel erklärt die drei Verfahren einfach, zeigt die Einrichtung mit Microsoft 365 und den Stufenplan für DMARC.
Was E-Mail-Authentifizierung ist – und warum es drei Verfahren braucht
E-Mail wurde in einer Zeit erfunden, in der sich alle vertraut haben. Das Protokoll dahinter prüft bis heute nicht, ob der Absender echt ist. Wer eine E-Mail verschickt, kann jede beliebige Adresse in das „Von“-Feld schreiben – auch Ihre. Genau das nutzen Angreifer beim Spoofing und beim E-Mail-Betrug aus.
E-Mail-Authentifizierung schließt diese Lücke. Sie legt für Ihre Domain fest, wer in Ihrem Namen senden darf und wie ein Empfänger das überprüfen kann. Drei Verfahren arbeiten dabei zusammen, weil jedes eine andere Frage beantwortet.
| Verfahren | Frage, die es beantwortet | Wo es steht |
|---|---|---|
| SPF | Welche Server dürfen für meine Domain senden? | TXT-Eintrag im DNS |
| DKIM | Wurde die Nachricht unterwegs verändert und stammt sie echt von der Domain? | Signatur + Schlüssel im DNS |
| DMARC | Was soll passieren, wenn SPF oder DKIM nicht passen? | TXT-Eintrag im DNS |
SPF und DKIM prüfen also die Absender-Domain, DMARC gibt die Regel für den Ernstfall vor. Erst alle drei Protokolle zusammen ergeben eine belastbare Authentifizierung. Jedes ist ein offener Standard – einzeln bleibt jedes Protokoll löchrig, deshalb verlangen die großen Provider inzwischen alle drei.
SPF: Wer darf im Namen Ihrer Domain senden?
SPF steht für „Sender Policy Framework“ und ist das erste der drei Protokolle. Der SPF-Eintrag ist eine öffentliche Liste: Welche Server und Dienste dürfen E-Mails für Ihre Domain versenden? Diese Liste veröffentlichen Sie als Eintrag vom Typ TXT im DNS Ihrer Domain.
Bekommt ein Empfänger eine Nachricht von Ihnen, schaut sein E-Mail-Server nach: Steht der sendende Server auf der SPF-Liste? Wenn ja, ist der Versand plausibel. Wenn nein, ist die E-Mail verdächtig.
Ein SPF-Eintrag für Microsoft 365 sieht so aus:
„ v=spf1 include:spf.protection.outlook.com -all „
Das include verweist auf die Versand-Server von Microsoft. Das -all am Ende bedeutet: Alles, was nicht auf der Liste steht, ist nicht autorisiert. Wer vorsichtig starten will, setzt übergangsweise ~all (Softfail) und verschärft erst nach Auswertung der ersten DMARC-Reports auf -all. Wichtig ist, dass alle Ihre Versand-Quellen im Eintrag stehen – also auch Newsletter-Tools, Ihr Warenwirtschaftssystem oder ein Drucker, der Rechnungen verschickt. Genau hier passiert der häufigste Fehler: Eine Quelle wird vergessen, und deren Mails fallen durch.
SPF hat eine Schwäche. Wird eine E-Mail weitergeleitet, ändert sich der sendende Server – und SPF schlägt fehl, obwohl die Nachricht echt ist. Deshalb reicht SPF alleine nicht. Es braucht DKIM daneben.
DKIM: Die digitale Unterschrift Ihrer E-Mails
DKIM steht für „DomainKeys Identified Mail“. Das Verfahren gibt jeder E-Mail eine digitale Signatur mit – wie ein Siegel, das beweist, dass die Nachricht wirklich von Ihrer Domain kommt und unterwegs nicht verändert wurde.
Dahinter steckt ein Schlüsselpaar. Ihr E-Mail-Server signiert jede ausgehende Nachricht mit einem privaten Schlüssel, den nur er kennt. Den passenden öffentlichen Schlüssel hinterlegen Sie im DNS. Der Empfänger liest den öffentlichen Schlüssel aus, prüft die Signatur und weiß: echt oder manipuliert.
Ein DKIM-Schlüssel liegt als Eintrag im DNS und beginnt typischerweise so:
„ selector._domainkey.ihre-domain.de TXT "v=DKIM1; k=rsa; p=„
Bei Microsoft 365 müssen Sie den Schlüssel nicht selbst erzeugen. Microsoft stellt zwei fertige CNAME-Einträge bereit, die Sie im DNS eintragen – dazu unten mehr. Der Vorteil von DKIM: Die Signatur bleibt auch bei einer Weiterleitung gültig. Damit deckt DKIM genau den Fall ab, an dem SPF scheitert.
DMARC: Die Regel für gefälschte Absender
DMARC steht für „Domain-based Message Authentication, Reporting and Conformance“ und ist im Standard RFC 7489 definiert. DMARC ist die Klammer über SPF und DKIM. Es beantwortet die Frage: Was soll der Empfänger tun, wenn SPF oder DKIM nicht passen?
Ohne DMARC entscheidet jeder Empfänger-Server selbst, wie er mit einer verdächtigen Nachricht umgeht. Mit DMARC geben Sie die Regel vor – und bekommen zusätzlich Berichte darüber, wer in Ihrem Namen sendet.
Auch DMARC ist ein TXT-Eintrag im DNS, und zwar unter _dmarc vor Ihrer Domain:
„ _dmarc.ihre-domain.de TXT "v=DMARC1; p=none; rua=mailto:dmarc@ihre-domain.de" „
Zwei Teile sind entscheidend. Das p= legt die Richtlinie fest – also was mit nicht authentifizierten Mails passiert (dazu gleich der Stufenplan). Das rua= ist die Adresse, an die tägliche Berichte gehen. Diese RUA-Berichte zeigen, welche Server in Ihrem Namen senden – legitime wie gefälschte.
DMARC funktioniert nur mit einer Zusatzbedingung: dem Alignment. Die Domain im sichtbaren „Von“-Feld muss zur Domain passen, die SPF oder DKIM geprüft hat. Es reicht, wenn eines von beiden ausgerichtet ist. Dieses Alignment ist der Grund, warum Sie SPF und DKIM sauber auf Ihre eigene Domain setzen müssen – nicht auf die eines Dienstleisters.
Warum SPF, DKIM und DMARC jetzt Pflicht sind
Jahrelang galten die drei Protokolle als Kür für Zustellbarkeits-Profis. Das hat sich geändert. Die großen Postfach-Anbieter machen die Authentifizierung nach diesen Standards zur Bedingung für die Zustellung.
Google und Yahoo: der Anfang 2024
Google und Yahoo haben Anfang 2024 gemeinsame Absender-Anforderungen eingeführt. Wer als Massenversender gilt – nach Googles Definition rund 5.000 Nachrichten pro Tag an private Gmail-Konten innerhalb von 24 Stunden – muss seither SPF und DKIM einsetzen und einen DMARC-Eintrag mit mindestens p=none veröffentlichen. Zusätzlich verlangt Google einen Ein-Klick-Abmeldelink (RFC 8058) für Werbemails und eine Spam-Rate unter 0,1 Prozent, die nie 0,3 Prozent erreichen darf.
Microsoft: Outlook zieht 2025 nach
Microsoft ist zum 5. Mai 2025 nachgezogen. Für Absender mit mehr als 5.000 E-Mails pro Tag an die Consumer-Postfächer Outlook.com, Hotmail.com und Live.com gelten dieselben drei Bausteine: SPF und DKIM müssen bestehen, DMARC mindestens mit p=none, und eines der beiden Verfahren muss zur Absender-Domain ausgerichtet sein. Nicht konforme Nachrichten wandern zunächst in den Junk-Ordner – Microsoft hat angekündigt, sie später ganz abzulehnen. Eine abgelehnte Mail bekommt den Fehlercode 550 5.7.515.
Was das für kleinere Versender heißt
Die harte Schwelle liegt bei 5.000 Mails pro Tag. Die meisten KMU liegen darunter. Trotzdem gilt: Authentifizierung ist für jeden Versender zur Baseline geworden – aus zwei Gründen.
Erstens die Zustellbarkeit. Auch unterhalb der Schwelle bewerten die Provider unauthentifizierte Mails schlechter. Ihre Rechnung oder Ihr Angebot landet dann leichter im Spam – und Sie merken es nicht einmal.
Zweitens der Schutz Ihrer Marke. Ohne DMARC kann jeder Ihre Domain in gefälschten Absendern verwenden, etwa für Phishing-Angriffe an Ihre Kunden. DMARC mit einer scharfen Richtlinie unterbindet das. Deshalb lohnt sich die Einrichtung, lange bevor Sie die 5.000er-Grenze erreichen.
So prüfen Sie, ob Ihre E-Mails authentifiziert sind
Sie müssen nicht raten, wie es um Ihre Domain steht. Schicken Sie eine E-Mail an ein eigenes Gmail- oder Outlook-Konto und öffnen Sie die Nachricht. In den Kopfzeilen der E-Mail steht für SPF, DKIM und DMARC jeweils ein Ergebnis – „pass“ oder „fail“. Ein „pass“ bei allen dreien heißt: Ihre Absender-Adresse ist authentifiziert, und der Empfänger kann Ihnen vertrauen.
Schneller geht es mit einem kostenlosen Tool zur E-Mail-Authentifizierung. Sie geben Ihre Domain oder E-Mail-Adresse ein, und das Tool prüft alle Einträge auf einmal. Für jeden Eintrag bekommen Sie ein Ergebnis: Steht der SPF-Eintrag? Ist DKIM aktiv? Gibt es einen DMARC-Eintrag, und mit welcher Richtlinie? Diese Ergebnisse zeigen Ihnen genau, welches der drei Verfahren noch fehlt – und damit den nächsten Schritt.
Für den genauen Blick öffnen Sie in einer empfangenen Nachricht die Kopfzeile „Authentication-Results“. Dort steht direkt hintereinander spf=pass, dkim=pass und dmarc=pass, wenn alle drei Protokolle sauber greifen. Ein fail oder none verrät, an welchem Verfahren es hakt. Wer die Einträge lieber direkt im DNS kontrolliert, fragt sie mit einem einfachen Kommando ab – etwa nslookup -type=txt _dmarc.ihre-domain.de für den DMARC-Eintrag. So sehen Sie, ob der Eintrag wirklich veröffentlicht ist und die richtige Richtlinie enthält. Stimmen SPF, DKIM und DMARC, ist Ihre Domain als Absender sauber authentifiziert – und Ihre E-Mails gewinnen an Zustellbarkeit und Sicherheit.
SPF, DKIM und DMARC in Microsoft 365 einrichten
Die meisten Unternehmen in unserer Region arbeiten mit Microsoft 365 und Exchange Online. Für diese Umgebung ist die Einrichtung überschaubar – drei Schritte im DNS und im Microsoft-Portal. Wenn Sie Ihre Umgebung parallel absichern wollen, hilft unser Leitfaden zu Microsoft 365 sicher betreiben.
Schritt 1: SPF-Eintrag setzen
Legen Sie bei Ihrem DNS-Anbieter einen Eintrag vom Typ TXT mit v=spf1 include:spf.protection.outlook.com -all an. Prüfen Sie vorher, welche weiteren Dienste für Sie senden, und ergänzen Sie deren include in derselben Zeile. Es darf pro Domain nur einen SPF-Eintrag geben.
Schritt 2: DKIM aktivieren
DKIM richten Sie im Microsoft-Defender-Portal ein. Dort finden Sie unter den E-Mail-Authentifizierungs-Einstellungen den Punkt DKIM. Microsoft zeigt Ihnen zwei CNAME-Einträge (selector1 und selector2), die Sie im DNS Ihrer Domain eintragen. Danach schalten Sie im Portal die DKIM-Signierung für Ihre Domain ein. Ab dann trägt jede ausgehende Nachricht ihre Signatur.
Schritt 3: DMARC-Eintrag anlegen
Zum Schluss der DMARC-Eintrag: ein TXT-Eintrag unter _dmarc.ihre-domain.de mit v=DMARC1; p=none; rua=mailto:.... Starten Sie bewusst mit p=none und einer gültigen Report-Adresse – so beobachten Sie erst, bevor Sie schärfer stellen.
In der Praxis ist Schritt 1 der kniffligste. Ein Beispiel aus unserer Arbeit: Ein Lohn- und Steuerbüro mit rund 25 Mitarbeitenden aus dem Raum Siegburg kam zu uns, weil Rechnungs- und Lohn-Mails bei den Mandanten immer öfter im Spam landeten. Ein Mandant meldete sogar eine Mail „von Ihnen“ mit fremder Absenderadresse. Wir haben den SPF-Eintrag korrigiert – es fehlten zwei Versand-Quellen –, DKIM in Microsoft 365 aktiviert und DMARC zunächst auf p=none gesetzt. Nach zwei Wochen Report-Auswertung ging es auf p=quarantine. Seitdem kommen die Mails wieder sauber an, und die gefälschten Absender greifen nicht mehr.
Wenn Sie kein eigenes IT-Team haben, das DNS und Microsoft 365 sicher bedient, übernimmt das eine externe IT-Abteilung. Den Überblick über Ihre gesamte Microsoft-Umgebung gibt unser Microsoft-365-Leitfaden.
Der DMARC-Stufenplan: von p=none zu p=reject
DMARC setzt man nicht in einem Rutsch scharf. Wer sofort auf p=reject geht, riskiert, dass eigene legitime Mails abgelehnt werden – zum Beispiel die des vergessenen Newsletter-Tools. Deshalb gilt: in drei Stufen, jede mit Beobachtung.
| Stufe | Richtlinie | Was passiert | Wann weitergehen |
|---|---|---|---|
| 1 | p=none | Nichts wird blockiert, Sie bekommen nur Berichte | Wenn die Berichte alle legitimen Quellen zeigen |
| 2 | p=quarantine | Nicht authentifizierte Mails landen im Spam | Wenn keine echten Mails mehr fälschlich aussortiert werden |
| 3 | p=reject | Nicht authentifizierte Mails werden abgewiesen | Zielzustand für vollen Schutz |
Der Kern des Stufenplans ist das Monitoring. In der p=none-Phase lesen Sie die RUA-Berichte aus – von Hand oder mit einem DMARC-Tool, das die Berichte lesbar aufbereitet. Erst wenn Sie sicher sind, dass jede legitime Quelle sauber authentifiziert ist, stellen Sie schärfer. So kommen Sie zu vollem Schutz, ohne die eigene Zustellung zu gefährden.
Genau deshalb ist DMARC kein „einmal setzen und vergessen“. Jemand muss die Berichte lesen und auf neue Versand-Quellen reagieren. Bei uns ist das Teil der Managed Services: Die Authentifizierung läuft im Hintergrund mit, die Reports landen nicht in einem toten Postfach, und Ihre Sicherheit beim Versand bleibt dauerhaft belastbar.
Wer DMARC dauerhaft auf p=reject betreibt, kann als nächsten Schritt BIMI ergänzen. Damit erscheint das Logo Ihrer Marke direkt im Postfach des Empfängers – ein sichtbares Vertrauenssignal, das auf einer scharfen DMARC-Richtlinie aufbaut.
So lesen Sie die DMARC-Reports
Der DMARC-Eintrag bringt Ihnen nur dann etwas, wenn jemand die Berichte auch auswertet. Über die rua-Adresse bekommen Sie in der Regel täglich einen aggregierten Bericht – ein maschinenlesbares XML, das jede Versand-Quelle auflistet, die in Ihrem Namen gesendet hat. Für jede Quelle steht darin, ob SPF und DKIM bestanden haben und ob das Alignment passt.
Von Hand ist dieses XML kaum zu lesen. Deshalb kippen Sie die Berichte in ein DMARC-Report-Tool, das die Rohdaten in eine übersichtliche Tabelle übersetzt: Absender-Server, Anzahl der Nachrichten, Ergebnis pro Protokoll für SPF und DKIM. So sehen Sie auf einen Blick, welche Quellen sauber authentifiziert sind – und welche nicht. Solche Tools gibt es als eigenständige Dienste, oft mit einer kostenlosen Einstiegsstufe für kleine Versandmengen.
Der Blick lohnt sich vor allem in der p=none-Phase. Taucht dort ein Server auf, den Sie nicht kennen, ist das entweder eine vergessene legitime Quelle – ein Newsletter-Tool, die Buchhaltung, ein Support-System – oder ein Angreifer, der Ihre Domain missbraucht. Erst wenn alle legitimen Quellen im Bericht grün sind, stellen Sie die Richtlinie auf p=quarantine und später auf p=reject. Die Berichte sind damit kein Selbstzweck, sondern Ihr Steuerinstrument für den Stufenplan – und der Grund, warum Authentifizierung ein laufender Prozess ist und keine einmalige Einrichtung.
Die fünf häufigsten Fehler bei der E-Mail-Authentifizierung
Aus der Praxis sehen wir bei der E-Mail-Sicherheit von Unternehmen immer wieder dieselben Stolperfallen:
- Nur SPF, kein DKIM und DMARC. SPF alleine bricht bei jeder Weiterleitung und schützt nicht vor gefälschten Absendern. Ein häufiger Irrtum: „Wir haben SPF, das reicht.“
- Zwei SPF-Einträge. Pro Domain ist nur ein SPF-Eintrag erlaubt. Ein zweiter macht beide ungültig – ein klassischer Fehler nach dem Wechsel eines Dienstleisters.
- Versand-Quellen vergessen. Newsletter-Tool, Warenwirtschaft, Buchhaltung: Jede Quelle, die nicht im SPF-Eintrag steht, fällt durch. Genau hier landen Rechnungen im Spam.
- DMARC dauerhaft auf p=none. Viele bleiben aus Vorsicht bei
p=nonestehen. Dann gibt es zwar Berichte, aber keinen echten Schutz vor Spoofing – die Richtlinie greift nie. - Reports gehen ins Leere. Eine RUA-Adresse ist gesetzt, aber niemand liest die Berichte. Ohne Auswertung merkt niemand, wenn eine Quelle fehlt oder ein Angreifer die Domain missbraucht.
Wer diese fünf Punkte vermeidet, hat den größten Teil einer belastbaren E-Mail-Authentifizierung erledigt.
Was SPF, DKIM und DMARC nicht leisten
So wichtig die drei Verfahren sind – sie lösen nicht jedes Problem. SPF, DKIM und DMARC beweisen, dass eine Nachricht von Ihrer Domain stammt. Sie verschlüsseln aber weder den Inhalt der E-Mail noch die Anhänge; dafür sorgt die Transportverschlüsselung. Und sie schützen nur Ihre eigene Domain: Schreibt ein Angreifer von einer täuschend ähnlichen Adresse – etwa mit vertauschten Buchstaben –, greift kein DMARC, weil es eine fremde Domain ist. Auch die klassische Spam-Filterung ersetzt die Authentifizierung nicht; sie ergänzt sie. Die drei Protokolle sind also ein starkes Fundament der E-Mail-Sicherheit, aber kein Rundumschutz. Wer sie sauber einrichtet, hat die Absender-Identität abgesichert – der Rest gehört in ein durchdachtes Sicherheitskonzept, das auch Angriffe über Fremd-Domains und schädliche Anhänge abfängt. Und weil täuschend ähnliche Absender-Domains technisch nicht abzufangen sind, bleibt der geschulte Blick der Mitarbeitenden entscheidend — wie ihn ein Security Awareness Training aufbaut.
Die wichtigsten Begriffe kurz erklärt
Rund um die drei Standards SPF, DKIM und DMARC tauchen einige Fachbegriffe immer wieder auf. Die wichtigsten in Kurzform:
- Alignment (Ausrichtung): Die Bedingung, dass die sichtbare Absender-Domain zur geprüften SPF- oder DKIM-Domain passt. Ohne Alignment besteht die DMARC-Prüfung nicht.
- Envelope-From: Die technische Absenderadresse im „Umschlag“ der Nachricht, die SPF prüft – nicht zu verwechseln mit der sichtbaren „Von“-Adresse, die der Empfänger liest.
- Selector: Der Name, unter dem der öffentliche DKIM-Schlüssel im DNS liegt (bei Microsoft 365 sind das
selector1undselector2). Über den Selector findet der Empfänger den passenden Schlüssel. - Softfail (
~all): Die vorsichtige SPF-Variante, die unbekannte Server nicht hart ablehnt, sondern nur markiert – nützlich für den Einstieg, bevor Sie auf-allverschärfen. - RUA-Bericht: Der aggregierte DMARC-Report an Ihre
rua-Adresse, der zeigt, welche Server in Ihrem Namen senden und ob ihre Nachrichten die Authentifizierung bestehen.
Fazit
SPF, DKIM und DMARC sind keine Kür mehr. Die drei Protokolle sind der Beweis, dass Ihre E-Mails von Ihnen stammen – und die Bedingung dafür, dass sie zuverlässig ankommen. SPF sagt, wer senden darf. DKIM signiert die Nachricht. DMARC gibt die Regel vor und liefert die Berichte. Für ein Unternehmen mit Microsoft 365 ist diese Authentifizierung in drei DNS-Schritten erledigt, kein Großprojekt.
Die Einrichtung ist das eine, der Betrieb das andere: Jemand muss die DMARC-Berichte lesen und auf neue Versand-Quellen reagieren. Sonst bleibt der Schutz auf halber Strecke stehen. Wie E-Mail-Sicherheit in ein durchdachtes IT-Sicherheitskonzept passt und wie Sie den Versand zusätzlich datenschutzkonform absichern, zeigt unser Artikel zum E-Mail-Datenschutz. Einen breiteren Überblick über die Bausteine gibt unser Sicherheits-Ratgeber.
Sie wissen nicht, ob Ihre Mails sauber authentifiziert sind – oder ob jemand in Ihrem Namen sendet? Wir sehen uns das gemeinsam an. Jetzt unverbindliches Beratungsgespräch vereinbaren – Termin nach Ihrem Kalender.
Häufige Fragen zu SPF, DKIM und DMARC
Brauche ich als kleines Unternehmen wirklich SPF, DKIM und DMARC?
Ja. Die formale Pflicht gilt zwar erst ab 5.000 Mails pro Tag an private Postfächer. Praktisch ist die Authentifizierung aber für jeden Versender zur Grundlage geworden: Ohne sie werten die Provider Ihre Mails schlechter, und ohne DMARC kann jeder Ihre Domain für gefälschte Absender verwenden.
Was ist der Unterschied zwischen SPF, DKIM und DMARC?
SPF legt fest, welche Server für Ihre Domain senden dürfen. DKIM gibt jeder Nachricht eine digitale Signatur, die Echtheit und Unverändertheit beweist. DMARC verbindet beide und gibt die Regel vor, was mit nicht authentifizierten Mails passiert – plus Berichte über den Versand in Ihrem Namen.
Was bedeutet p=none, p=quarantine und p=reject bei DMARC?
Das ist die DMARC-Richtlinie. p=none blockiert nichts und liefert nur Berichte – der Startpunkt. p=quarantine schiebt nicht authentifizierte Mails in den Spam. p=reject weist sie ganz ab – der Zielzustand. Man geht schrittweise vor, um keine legitimen Mails zu verlieren.
Wie richte ich SPF, DKIM und DMARC in Microsoft 365 ein?
In drei Schritten: einen SPF-Eintrag mit dem Microsoft-include im DNS setzen, DKIM im Microsoft-Defender-Portal über die zwei bereitgestellten CNAME-Einträge aktivieren und einen DMARC-Eintrag unter _dmarc mit p=none und einer Report-Adresse anlegen. Danach den DMARC-Stufenplan durchlaufen.
Was passiert, wenn meine E-Mails nicht authentifiziert sind?
Sie landen häufiger im Spam, und bei den großen Providern werden sie zunehmend ganz abgelehnt – Microsoft etwa mit dem Fehlercode 550 5.7.515. Zusätzlich kann Ihre Domain ungeschützt für Spoofing missbraucht werden, weil kein DMARC den Missbrauch stoppt.
Reicht SPF alleine aus?
Nein. SPF bricht bei jeder Weiterleitung und sagt nichts darüber, ob eine Nachricht unterwegs verändert wurde. Erst DKIM und DMARC schließen diese Lücken. Die Provider verlangen deshalb ausdrücklich alle drei Verfahren zusammen.
