DMARCbis-Abdeckungsdaten (DMARC2)
Verfolgen Sie die Abdeckung von DMARCbis bei den wichtigsten E-Mail-Anbietern
DMARCbis ist jetzt ein offizieller IETF-Standards-Track-Standard, der im Mai 2026 als RFC 9989 (zusammen mit RFC 9990 und RFC 9991) veröffentlicht wurde und RFC 7489 ersetzt. Sehen Sie, wie E-Mail-Anbieter den neuen Standard übernehmen.
RFC 9989 (DMARCbis) • RFC 9990 (Aggregate Reporting) • RFC 9991 (Failure Reporting)
Wöchentlicher Nutzungsstrend
Zuletzt aktualisiert: 02. August 2026 um 05:20 UTC
Zeitraum: Montag, 28. Juli 2025 bis Sonntag, 02. August 2026
0.6%
DMARCbis-Adoptionsrate
28
DMARCbis-Berichtsanbieter
4.526
DMARC-Berichtsanbieter gesamt
Adoption nach Top-DMARC-Berichtsanbietern
| DMARC-Berichtsanbieter | DMARCbis-Rate | Erster DMARCbis-Bericht | Letzter DMARCbis-Bericht |
|---|---|---|---|
| GMX | 100.0% | 27. Jul 2024 10:39 UTC | 02. Aug 2026 04:56 UTC |
| WEB.DE | 100.0% | 27. Jul 2024 10:38 UTC | 02. Aug 2026 04:52 UTC |
| mail.com | 100.0% | 27. Jul 2024 10:39 UTC | 02. Aug 2026 04:53 UTC |
| DmarcDkim.com | 93.5% | 19. Jul 2026 16:07 UTC | 01. Aug 2026 23:08 UTC |
| eccentric.dk | 14.3% | 07. Jul 2026 05:59 UTC | 01. Aug 2026 06:54 UTC |
| woodpower.pl | 80.0% | 16. Jul 2026 13:03 UTC | 30. Jul 2026 13:55 UTC |
| splidex.com | 46.2% | 18. Jul 2026 16:28 UTC | 01. Aug 2026 21:49 UTC |
| asche.co | 18.2% | 15. Jul 2026 15:43 UTC | 01. Aug 2026 15:44 UTC |
| chmurka.email | 50.0% | 29. Jul 2026 11:14 UTC | 31. Jul 2026 14:47 UTC |
| mordjunior.com | 66.7% | 13. Jul 2026 20:13 UTC | 28. Jul 2026 07:01 UTC |
| vr.org | 100.0% | 15. Jul 2026 17:49 UTC | 31. Jul 2026 20:47 UTC |
| autopilot-business.com | 100.0% | 14. Jul 2026 09:26 UTC | 22. Jul 2026 13:09 UTC |
| teakettle.de | 100.0% | 27. Jul 2026 08:11 UTC | 01. Aug 2026 16:45 UTC |
| boldhaus.de | 100.0% | 18. Jul 2026 14:42 UTC | 31. Jul 2026 23:35 UTC |
| wedos.org | 100.0% | 28. Jul 2026 14:13 UTC | 29. Jul 2026 14:01 UTC |
| tomlab.cz | 4.3% | 23. Jul 2026 08:49 UTC | 23. Jul 2026 08:49 UTC |
| friendz.email | 25.0% | 29. Jul 2026 04:37 UTC | 29. Jul 2026 04:37 UTC |
| datenschutz-ist-voll-doof.de | 33.3% | 16. Jul 2026 02:39 UTC | 16. Jul 2026 02:39 UTC |
| migration.bertha-online.de | 33.3% | 16. Jul 2026 16:26 UTC | 16. Jul 2026 16:26 UTC |
| caseof.de | 50.0% | 20. Jul 2026 13:29 UTC | 20. Jul 2026 13:29 UTC |
DMARCbis in der Praxis: t, psd und np verstehen
DMARCbis führt neue Tags ein, die Domain-Inhabern und E-Mail-Dienstanbietern helfen, die Prüfung und Durchsetzung von Authentifizierungsrichtlinien zu verfeinern. Im Folgenden wird erklärt, wie sich jeder dieser Tags auf die E-Mail-Authentifizierung auswirkt, zusammen mit praxisnahen Anwendungsszenarien.
t=y
Testmodus
Die Einstellung t=y zeigt an, dass sich eine Domain im „Testmodus" befindet. Dieses neue Tag ersetzt das pct=-Tag der ursprünglichen DMARC-Spezifikation und bietet eine klarere Möglichkeit, die Testabsicht zu signalisieren. Wenn t=y gesetzt ist, werden E-Mail-Empfänger aufgefordert, die Richtlinie weniger streng zu behandeln. Im Einzelnen:
-
Eine Richtlinie mit
p=rejectundt=y(ehemalspct=0) kann alsp=quarantinebehandelt werden -
Eine Richtlinie mit
p=quarantineundt=y(ehemalspct=0) kann alsp=nonebehandelt werden
Dieser Ansatz ermöglicht es Domain-Inhabern, die Auswirkungen strengerer Richtlinien zu überwachen, ohne sie sofort durchzusetzen, und verringert so das Risiko, dass legitime E-Mails während der Testphase abgelehnt werden.
Beispiel:
v=DMARC1; p=reject; rua=mailto:[your-domain.com]@rua.dmarcdkim.io; t=y
psd=y
Public-Suffix-Domain-Richtlinie
Das psd=y-Tag ermöglicht es einer Public Suffix Domain (PSD) wie gov.uk oder bank, eine DMARC-Richtlinie zu veröffentlichen, die für alle darunter liegenden Domains gilt, auch wenn diese Subdomains keine eigenen DMARC-Einträge gesetzt haben.
Dies ist besonders hilfreich in Umgebungen, in denen:
- Sicherheitsrichtlinien auf Registry- oder Branchenebene durchgesetzt werden müssen.
- Viele Subdomains unabhängig registriert oder betrieben werden (z. B. von Kommunen oder Banken).
- Eine zentrale Steuerung der Domain-Sicherheit erforderlich ist.
Beispiel (auf PSD-Ebene veröffentlicht):
_dmarc.bank. IN TXT "v=DMARC1; p=quarantine; psd=y"
np=reject
Subdomain-Richtlinie für nicht existierende Domains
Das np=-Tag legt eine DMARC-Richtlinie für Subdomains fest, die nicht existieren (NXDOMAIN), aber dennoch gefälscht werden könnten.
Dies schließt eine Lücke, durch die Angreifer E-Mails von random.nonexistent.company.com fälschen konnten, um die DMARC-Richtlinie von company.com zu umgehen.
Beispiel:
v=DMARC1; p=reject; np=reject; rua=mailto:[your-domain.com]@rua.dmarcdkim.io
Mit dieser Konfiguration:
-
Legitime E-Mails von
company.commüssen die DMARC-Prüfungen bestehen. -
Jede gefälschte E-Mail von einer nicht existierenden Subdomain wie
secure-login.company.comwird abgelehnt.
Zusammen geben diese neuen Tags Domain-Inhabern mehr Kontrolle über das Authentifizierungsverhalten und verbessern den Schutz bei Grenzfällen. Verwenden Sie t=y während der Einführung, psd=y für Registry-Level-Richtlinien und np=, um Spoofing von nicht registrierten Subdomains zu blockieren.
Domain prüfen und den Anweisungen folgen, um Ihre DMARC-Konfiguration festzunageln.
Kein Expertenwissen nötig!