DMARC einrichten: SPF, DKIM und der _dmarc-Eintrag

_dmarc.beispiel.de.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de"

Das ist der ganze DMARC-Eintrag, mit dem man anfängt: ein TXT-Eintrag unter _dmarc, Richtlinie none, eine Berichtsadresse. Veröffentlicht wird er erst, wenn SPF und DKIM für jede Versandquelle stehen. Auf quarantine kommt er erst, wenn die Berichte zeigen, dass nichts Legitimes durchfällt. Der Rest dieses Beitrags ist der Weg dorthin, in sieben Schritten, mit den Tags nach RFC, den Klickwegen bei Microsoft 365, Google Workspace, STRATO und ALL-INKL und einer Messung, wie es um 149 Tiroler Domains steht.

Vorweg der Grund, warum SPF allein nicht reicht: SPF prüft eine Adresse, die im Postfach nie erscheint. Wer nur SPF gesetzt hat, hat den ersten von drei Schritten gemacht. Gefälschte Absender, also E-Mail-Spoofing, verhindert erst DMARC.

Die zwei Absender, von denen nur einer sichtbar ist#

Eine E-Mail trägt zwei Absenderangaben.

Die eine steht im SMTP-Umschlag (MAIL FROM) und dient der Zustellung; dort landen Unzustellbarkeitsmeldungen. Die andere steht im Kopf der Nachricht (From:) und ist das, was das Mailprogramm anzeigt.

SPF prüft den Umschlag. RFC 7208 schreibt vor, dass ein Prüfer die MAIL FROM-Identität prüft, und empfiehlt zusätzlich die HELO-Angabe. Der From:-Header kommt darin nicht vor.

Damit ist die Lücke beschrieben: Ein Absender kann im Umschlag eine eigene Domain führen, für die sein SPF-Eintrag sauber gilt, und im sichtbaren From: deine Domain eintragen. SPF sagt „bestanden“, und der Empfänger liest deinen Namen. RFC 7489 benennt das ohne Umschweife: Die beiden Domains „können verschieden sein, und sie sind für den Endnutzer typischerweise nicht sichtbar“.

DKIM löst eine andere Frage. Der versendende Server signiert Kopfzeilen und Text kryptografisch; der öffentliche Schlüssel liegt im DNS unter <selector>._domainkey.<domain>. Damit kann die signierende Domain laut RFC 6376 „einen Teil der Verantwortung“ für die Nachricht übernehmen. DKIM sagt nicht, dass die Nachricht echt ist. Es sagt, wer für sie geradesteht. Und weil Relais den Inhalt laut Standard in der Regel nicht wesentlich ändern, bleibt die Signatur auf dem Weg erhalten.

DMARC bringt beides mit der sichtbaren Adresse zusammen. Eine Nachricht besteht die Prüfung, wenn mindestens eines der Verfahren „pass“ liefert und die dabei geprüfte Domain zur From:-Domain passt (auf Englisch Identifier Alignment). Im Standardmodus „relaxed“ genügt dieselbe Organisationsdomain, mail.beispiel.de passt also zu beispiel.de; im Modus „strict“ muss die Domain exakt übereinstimmen.

Dazu kommt die zweite Hälfte: DMARC sagt dem Empfänger, was er im Fehlerfall tun soll, und lässt dir Berichte schicken, wer in deinem Namen versendet.

Der Weg in sieben Schritten#

Wie lange der Weg dauert, hängt an Schritt 5, und den bestimmt dein Versandrhythmus, nicht der Kalender: RFC 9989 hält fest, dass es je nach Rhythmus „viele Monate“ Berichte brauchen kann, bis ein Domaininhaber sicher ist, dass seine gesamte Post authentifiziert ist.

1. Versandquellen erfassen. Alles aufschreiben, was mit @deinedomain.de im From: verschickt: das Postfach selbst, Newsletter-Werkzeug, Ticketsystem, Buchhaltung, Kontaktformular der Website, Onlineshop. Diese Liste wird in Schritt 5 gegen die Berichte gelegt. RFC 9989 begründet den ganzen Ablauf genau damit, dass man außer in trivialen Fällen „hier einen Server übersieht oder dort eine Versandvereinbarung mit Dritten nicht kennt“.

2. SPF auf einen Eintrag bringen. Eine Domain darf nur einen SPF-Eintrag haben, und alle Quellen aus Schritt 1, die im Umschlag deine Domain verwenden, gehören hinein. Wie das geht, steht in SPF-Eintrag erstellen:

beispiel.de.  TXT  "v=spf1 mx include:_spf.mailanbieter.example ~all"

3. DKIM beim Anbieter aktivieren. Der Anbieter erzeugt den Schlüssel, du veröffentlichst den öffentlichen Teil, je nach Anbieter als TXT oder als CNAME (siehe unten). Ein eigener TXT-Schlüssel hat nach RFC 6376 diese Form:

selector1._domainkey.beispiel.de.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

4. Berichtspostfach anlegen und _dmarc mit p=none veröffentlichen. RFC 9989 beschreibt genau diese Reihenfolge: erst SPF, DKIM und das Postfach, dann der Eintrag mit p=none und rua. Der Standard nennt das „Monitoring Mode“.

_dmarc.beispiel.de.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de"

Liegt die Berichtsadresse auf einer anderen Domain als der geprüften, muss diese Zieldomain den Empfang bestätigen; RFC 7489 fragt dafür einen Eintrag unter beispiel.de._report._dmarc.<zieldomain> ab. Den Eintrag mit Richtlinie, Berichtsadresse und Syntaxprüfung erzeugt der DMARC-Generator. So sieht er am 03.10.2026 mit den Werten dieses Schritts aus (Screenshot des eigenen Werkzeugs):

5. Berichte lesen und Quellen nachziehen. Jede legitime Quelle, die im Bericht mit fail auftaucht, bekommt SPF oder DKIM mit passender Domain. RFC 9989 macht das zur Pflicht: Solche Mängel „MÜSSEN“ behoben sein, bevor eine durchsetzende Richtlinie veröffentlicht wird. Die Bedingung für den nächsten Schritt ist deshalb keine Wochenzahl, sondern: Alle Quellen aus Schritt 1 bestehen im Bericht.

6. Auf quarantine stellen. Empfänger sollen durchgefallene Mails als verdächtig behandeln; RFC 7489 nennt als Beispiele Spam-Ordner, genauere Prüfung oder eine Markierung.

_dmarc.beispiel.de.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@beispiel.de"

7. reject nur unter Bedingungen. RFC 9989 knüpft die letzte Stufe in Abschnitt 7.4 an Voraussetzungen. Wer p=reject veröffentlicht, darf sich nicht allein auf SPF verlassen und muss seine Mails mit DKIM signieren, weil weitergeleitete Post SPF nicht besteht. Domains, deren Nutzer auf Mailinglisten schreiben, sollen p=reject gar nicht veröffentlichen; wer es trotzdem will, soll vorher mindestens einen Monat p=none und ebenso lange p=quarantine veröffentlichen und die Berichte vergleichen. Für eine Domain, deren Mitarbeitende auf Mailinglisten schreiben, ist quarantine damit die Endstufe. Wer reject setzt: Die Ablehnung soll laut RFC 7489 schon während der SMTP-Verbindung passieren, der Absender erfährt es also sofort.

_dmarc.beispiel.de.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de"

Mit p=reject anzufangen ist der teuerste Fehler in dieser Sache. Jede Quelle aus Schritt 1, die nicht ausgerichtet ist, wird ab dem ersten Tag abgewiesen, und ohne Berichte weiß niemand, welche.

Wie funktioniert DMARC? Grundlagen einfach erklärt! – E-Mail Security 03 – Video abspielen (lädt YouTube)

Die Tags im DMARC-Eintrag#

Die Tabelle folgt RFC 7489, Abschnitt 6.3. Seit Mai 2026 gibt es mit RFC 9989 einen Nachfolger im Standards Track, der RFC 7489 ersetzt; was sich dort ändert, steht in der rechten Spalte.

Zwei weitere Tags aus RFC 7489, rf (Format der Einzelberichte, Standard afrf) und ri (Berichtsabstand in Sekunden, Standard 86400), führt RFC 9989 ausdrücklich unter „Tags Removed“. Neu ist dort außerdem psd für Betreiber öffentlicher Suffixe, das eine normale Firmendomain nicht braucht.

fo im Detail: 0 fordert einen Bericht, wenn alle Verfahren kein ausgerichtetes „pass“ liefern; 1, wenn irgendeines keins liefert; d bei jeder fehlgeschlagenen DKIM-Signatur, s bei jedem SPF-Fehlschlag, jeweils unabhängig von der Ausrichtung.

DKIM beim Anbieter aktivieren#

Bei Microsoft 365 signiert Microsoft ausgehende Mails für die Startdomain *.onmicrosoft.com automatisch. Für eine eigene Domain geht es im Defender-Portal unter Email & collaboration > Policies & rules > Threat policies > Email authentication settings, Reiter DKIM. Microsoft zeigt dort zwei CNAME-Einträge an, die bei der Domainverwaltung angelegt werden:

selector1._domainkey.beispiel.de.  CNAME  selector1-beispiel-de._domainkey.<Präfix der Startdomain>.<Zeichen>-v1.dkim.mail.microsoft
selector2._domainkey.beispiel.de.  CNAME  selector2-beispiel-de._domainkey.<Präfix der Startdomain>.<Zeichen>-v1.dkim.mail.microsoft

Die Hostnamen sind laut Microsoft für alle Organisationen gleich, die Ziele nicht; die echten Werte stehen im Portal oder in der Ausgabe von Get-DkimSigningConfig. Bis Microsoft die Einträge erkennt, dauert es laut Dokumentation „ein paar Minuten (oder möglicherweise länger)“; danach den Schalter Sign messages for this domain with DKIM signatures umlegen. Wer per PowerShell mit New-DkimSigningConfig anlegt, bekommt ohne Angabe eine Schlüssellänge von 1024 Bit.

Bei Google Workspace erzeugt man den DKIM-Schlüssel in der Admin-Konsole unter Apps > Google Workspace > Gmail. Der Standardselektor ist google, der TXT-Eintrag liegt also unter google._domainkey. Google bietet 2048 Bit an und 1024 Bit für Domainverwaltungen, die keine 2048-Bit-Schlüssel annehmen. Nach dem Eintragen kann es laut Google bis zu 48 Stunden dauern, bis die DKIM-Authentifizierung greift.

Bei STRATO muss nichts tun, wer ausschließlich über smtp.strato.de versendet: STRATO signiert nach eigener Aussage „bereits seit Jahren alle ausgehenden E-Mails mit DKIM“. Eigene DKIM-Einträge braucht es erst für einen externen Versanddienst; sie kommen im Kunden-Login unter Domainverwaltung > Einstellungen > DNS > TXT- und CNAME-Records.

Bei ALL-INKL legt der Hoster die DNS-Einträge für SPF und DKIM zum eigenen Mailserver laut Hilfe standardmäßig an. Den DMARC-Eintrag setzt man im KAS unter Tools > DNS-Einstellungen als TXT-Record mit dem Namen _dmarc.

Was Google und Yahoo seit Februar 2024 verlangen#

Seit dem 1. Februar 2024 gelten bei Gmail Anforderungen für alle Absender: SPF oder DKIM, TLS, Nachrichten nach RFC 5322 und eine in den Postmaster Tools gemeldete Spamrate unter 0,3 %. Wer mehr als 5.000 Nachrichten pro Tag an Gmail-Konten schickt, braucht zusätzlich DMARC (die Richtlinie darf laut Google none sein), und die From:-Domain muss zur SPF- oder DKIM-Domain passen. Werbe- und abonnierte Mails brauchen dann eine Ein-Klick-Abmeldung.

Yahoo setzt die Regeln ebenfalls ab Februar 2024 durch, nennt auf seiner Seite aber keine Mengenschwelle für Massenversender. Für sie verlangt Yahoo SPF und DKIM, einen gültigen DMARC-Eintrag „mit mindestens p=none“, bestandenes DMARC, Ausrichtung der From:-Domain und eine funktionierende List-Unsubscribe-Kopfzeile mit Ein-Klick-Abmeldung.

p=none erfüllt beide Anforderungen, schützt aber vor keiner einzigen gefälschten Mail. Den Schutz liefert erst quarantine oder reject.

Einen DMARC-Sammelbericht lesen#

Die Berichte an rua sind XML-Dateien, die laut RFC 7489 mit GZIP komprimiert werden sollen. RFC 9989 empfiehlt, sie maschinell auszuwerten, weil sie dafür gebaut sind. Das Prinzip versteht man trotzdem an einem einzigen Datensatz.

Das folgende Stück ist ein erfundenes Beispiel nach dem Schema in Anhang C von RFC 7489, mit einer IP aus dem Dokumentationsbereich nach RFC 5737:

<record>
  <row>
    <source_ip>192.0.2.25</source_ip>
    <count>214</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>beispiel.de</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>newsletter-dienst.example</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.newsletter-dienst.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

So liest man ihn:

• source_ip und count: 214 Mails kamen von 192.0.2.25.
• header_from: Sie trugen beispiel.de im sichtbaren Absender.
• auth_results: DKIM und SPF haben bestanden, aber für newsletter-dienst.example, nicht für beispiel.de.
• policy_evaluated: Deshalb steht dort zweimal fail. Unter DMARC zählt nur ein Ergebnis mit passender Domain.
• disposition ist none, weil die Richtlinie noch auf none steht. Unter reject wären diese 214 Mails abgewiesen worden.

Genau so sieht eine vergessene Versandquelle aus: technisch sauber, aber für die falsche Domain. Die Lösung liegt beim Newsletter-Dienst: dort eine eigene Absenderdomain einrichten, damit er mit d=beispiel.de signiert oder eine Umschlagadresse unter beispiel.de verwendet. Steht dagegen bei auth_results gar nichts Bestandenes und die IP gehört zu keiner Quelle aus Schritt 1, ist es genau der Missbrauch, den quarantine und reject abfangen sollen.

Durchgerechnet an cyberscale.io#

In eigener Sache: Das ist die Domain dieses Magazins, abgefragt am 15.09.2026 und noch einmal am 03.10.2026, mit demselben Ergebnis.

_dmarc.cyberscale.io.             TXT  "v=DMARC1; p=quarantine;"
cyberscale.io.                    TXT  "v=spf1 mx include:_spf.meinehp.at ~all"
default._domainkey.cyberscale.io. TXT  "v=DKIM1; h=sha256; t=s; p=MIIBIjANBgkq..."

Was stimmt: Es gibt genau einen SPF-Eintrag, und die DMARC-Richtlinie steht auf quarantine. Da pct fehlt, gilt nach RFC 7489 der Standardwert 100, die Richtlinie wirkt also auf jede durchgefallene Mail. adkim und aspf fehlen ebenfalls, damit gilt „relaxed“. Unter dem Selector default liegt ein DKIM-Schlüssel: RSA mit 2048 Bit, das verrät der Anfang MIIBIjAN des kodierten Schlüssels. h=sha256 lässt nur SHA-256 als Hashverfahren zu, t=s verlangt, dass die Domain in der Signatur (i=) exakt zur signierenden Domain (d=) passt, also keine Subdomain.

Was fehlt: rua. Ohne Berichtsadresse schickt kein Empfänger einen Sammelbericht. Welche Quellen im Namen von cyberscale.io versenden, ob eine legitime davon gerade im Spam-Ordner landet und ob jemand die Domain fälscht, ist so nicht sichtbar. Das ist der Fehler aus dem Abschnitt unten, Schritt 6 ohne Schritt 4 und 5. Der offene Punkt ist seit dem 15.09. derselbe, und er ist eine Zeile:

_dmarc.cyberscale.io.  TXT  "v=DMARC1; p=quarantine; rua=mailto:<berichtsadresse>"

Dasselbe Bild liefert der eigene E-Mail-Check am 03.10.2026: SPF, DKIM und DMARC grün, bei DMARC mit dem Hinweis auf die fehlende Berichtsadresse, und die Website-Header gelb, weil die Content-Security-Policy 'unsafe-inline' erlaubt.

Denselben Eintrag nimmt auch der Prüfteil des DMARC-Generators auseinander und nennt die fehlende Berichtsadresse als Warnung:

Wie es draußen steht: 149 Tiroler Domains#

In eigener Sache, zweiter Teil: Ich habe die DNS-Einträge von 149 Tiroler Domains passiv abgefragt, über DNS-over-HTTPS, ohne eine Mail zu schicken und ohne einen Server anzufassen. 34 davon sind die Hauptdomains aller Tiroler Tourismusverbände (gemessen am 29.09.2026, wiederholt am 02.10. und 03.10., bei DMARC ohne Änderung). 115 sind Betriebe aus meiner Akquise-Liste: Hotels, Arzt- und Zahnarztpraxen, Kanzleien, Handwerk, Agenturen, Stadtwerke, überwiegend aus Innsbruck und dem Zillertal (gemessen am 27.09.2026). Namen nenne ich nicht, auch keine positiven, weil sich die übrigen sonst per Ausschluss ermitteln ließen.

Zwei Dinge fallen auf. Die Lücke liegt nicht beim ersten Schritt: Alle 34 Verbände und 101 von 115 Betrieben haben SPF. Es fehlt der Teil, der die sichtbare Adresse schützt. Und wer DMARC hat, beobachtet meist nur: 65 Domains stehen auf p=none, und 48 der 80 Einträge haben nicht einmal eine Berichtsadresse. Das ist Schritt 4 ohne Schritt 5 und 6, als Dauerzustand. Wer sich in der Tabelle wiedererkennt: Der Weg von none zu quarantine steht oben, und er beginnt mit rua.

Nachprüfen#

Ob der Eintrag veröffentlicht ist, zeigt eine DNS-Abfrage. Unter Linux und macOS:

dig TXT _dmarc.beispiel.de +short

Unter Windows:

nslookup -type=TXT _dmarc.beispiel.de

Kommt nichts zurück, ist kein Eintrag veröffentlicht.

Ob DMARC bei einer echten Mail greift, zeigt der Kopf einer empfangenen Nachricht. Die Kopfzeile Authentication-Results ist in RFC 8601 festgelegt; RFC 7489 trägt dort das Verfahren dmarc mit den Ergebnissen pass und fail ein. Eine Testmail an ein fremdes Postfach schicken, im Mailprogramm den vollständigen Nachrichtenkopf öffnen und nach dieser Zeile suchen (Beispiel, Werte gekürzt):

Authentication-Results: mx.empfaenger.example;
  dkim=pass header.d=beispiel.de;
  spf=pass smtp.mailfrom=beispiel.de;
  dmarc=pass header.from=beispiel.de

Entscheidend ist dmarc=pass, und dass header.d oder smtp.mailfrom zu header.from passt. Steht dort dkim=pass mit einer fremden Domain, ist das der Fall aus dem Beispielbericht.

Schneller für die öffentliche Seite ist der Security-Scan. Er meldet, ob ein SPF-Eintrag vorhanden ist, ob DMARC fehlt, und stuft p=none ausdrücklich als „vorhanden, aber ohne Wirkung“ ein. Bei Subdomains ohne eigenen Eintrag schaut er bei der übergeordneten Domain nach und nennt, von wo das DMARC geerbt wird; nach RFC 7489 fragt auch der Empfänger bei fehlendem Eintrag die Organisationsdomain ab. Ob rua gesetzt ist, prüft der Scan nicht. Das tut der DMARC-Check: Er liest p, sp, pct und rua, zählt die DNS-Abfragen im SPF-Eintrag und sucht unter gängigen Selektoren nach einem DKIM-Schlüssel. Die typischen Fehler auf der SPF-Seite erklärt SPF-Eintrag erstellen und prüfen.

Sechs Abkürzungen, die nicht funktionieren#

Ein zweiter SPF-Eintrag verdoppelt nichts. RFC 7208 verbietet mehrere Einträge, die bei der Prüfung zugleich in Frage kämen; zwei davon sind ein Fehler, kein doppelter Schutz.

Alles auf einmal einzurichten rächt sich. SPF, DKIM und DMARC greifen ineinander, und wer drei Änderungen zugleich veröffentlicht und danach Zustellprobleme hat, weiß nicht, welche es war.

Die Berichte wegzulassen oder nie anzusehen führt in dieselbe Sackgasse. Ein DMARC-Eintrag ohne rua wirkt, aber blind; ein rua-Postfach, das niemand auswertet, ist dasselbe mit vollem Postfach.

pct taugt nicht zum langsamen Hochfahren. RFC 9989 hat das Tag gestrichen, weil es in der Praxis außer bei 0 und 100 „meist nicht genau angewendet“ wurde. Wer schrittweise verschärfen will, geht über die Stufen, nicht über Prozente.

Ein DKIM-„bestanden“ für eine fremde Domain sagt nichts. Signiert ein Dienst mit seiner eigenen Domain statt mit deiner, ergibt das dkim=pass im Header und trotzdem fail bei DMARC, weil die Ausrichtung fehlt.

Und auf p=none stehenzubleiben ist der stillste dieser Fehler. Die Stufe erfüllt die Vorgaben von Google und Yahoo und beobachtet, schützt aber nicht. Der Aufwand ist getragen, der Nutzen nicht abgeholt.

Die Reihenfolge, noch einmal#

DMARC einzurichten ist ein Eintrag im DNS; DMARC wirksam zu machen ist die Arbeit mit den Berichten davor. Die Reihenfolge (Quellen, SPF, DKIM, p=none mit rua, dann verschärfen) steht so im Standard selbst, weil nur sie verhindert, dass eigene Mails verschwinden. Wer mit SPF anfängt, findet in SPF-Eintrag erstellen den ersten Schritt; wer wissen will, wohin eingehende Post für die Domain überhaupt geht, liest MX-Eintrag, weil der mx-Mechanismus im SPF genau diese Server erlaubt.

Häufige Fragen#

Die weiteren Beiträge zur E-Mail-Sicherheit#

Dieser Leitfaden ist der Ausgangspunkt; die Einzelheiten stehen in zehn Beiträgen, hier in der Reihenfolge, in der man sie beim Einrichten braucht. Jeder verweist zurück hierher und auf den E-Mail-Check, der SPF, DKIM, DMARC und die Security-Header einer Domain in einem Lauf prüft.

Vor dem Einrichten

• E-Mail-Spoofing: gefälschte Absender erkennen und stoppen: was ohne die drei Einträge passiert, woran man eine Fälschung im Header sieht, und die Messung der 34 Tiroler Tourismusverbände.
• MX-Eintrag: Priorität und typische Fehler: welcher Server Post für die Domain annimmt; der mx-Mechanismus im SPF erlaubt genau diese Server.

Die drei Einträge

• SPF-Eintrag erstellen und prüfen: Versandwege sammeln, den Eintrag bauen, ~all oder -all, dann auslesen und die zehn DNS-Abfragen nachzählen.
• DKIM-Selector finden und DKIM-Schlüssel prüfen: den Selector im Header oder beim Anbieter finden, den Schlüssel abfragen, dkim=fail einordnen.
• DMARC-Policy: none, quarantine oder reject: was Gmail und Microsoft 365 aus jeder Stufe machen und woran man den Zeitpunkt zum Umstellen erkennt.

Wenn etwas nicht ankommt

• Warum landen meine Mails im Spam?: vier Ursachen in Prüfreihenfolge, mit den Regeln von Gmail und Yahoo.
• E-Mail abgelehnt: 550 5.7.1 und 554 5.7.1: was der Code im Rückläufer bedeutet und wer ihn beheben muss.
• E-Mail-Header lesen: Received von unten nach oben, Authentication-Results, und welchen Zeilen man trauen kann.

Wenn jemand deinen Namen benutzt

• CEO-Fraud: Chef-Betrug per Mail erkennen und abwehren: die vier Varianten, was DMARC, Outlook und Gmail dagegen tun, und welcher Ablauf im Betrieb eine Überweisung stoppt.

Wer das Einrichten abgeben will: das Paket E-Mail-Schutz macht genau diese Schritte beim bestehenden Anbieter, mit vier Wochen Auswertung der Berichte.

Stand 05.10.2026: Abschnitt mit den weiteren Beiträgen ergänzt. Quellen abgerufen, eigener Eintrag nachgemessen und die DNS-Messung der Verbände am 03.10.2026 wiederholt.