Keine DMARC-Berichte erhalten? Eine Checkliste zur Ursachensuche

Sie haben einen DMARC-Record mit einer rua=-Adresse veröffentlicht, ein paar Tage gewartet, und Ihr Postfach ist leer. Keine Berichte, keine Fehler, nichts, das Ihnen sagt, ob der Record defekt ist oder Sie einfach zu früh dran sind. Die Ursachen sind wenige und leicht zu prüfen, wenn Sie die Reihenfolge kennen. Dieser Leitfaden geht die Checkliste durch, vom günstigsten Test (Geduld) bis zu technischeren wie der Autorisierung externer Empfangsadressen, und erklärt, wie sich jeder Fehler zeigt.

Die kurze Antwort#

Fehlende DMARC-Berichte haben fast immer eine von sieben Ursachen: Sie haben noch keine 24 bis 48 Stunden gewartet, der Record liegt am falschen DNS-Namen, es gibt mehr als einen DMARC-Record, der rua=-Wert ist fehlerhaft (er muss mit mailto: beginnen), die Berichtsadresse liegt in einer anderen Domain ohne Autorisierung, Ihre Domain versendet zu wenig E-Mails, als dass Empfänger darüber berichten würden, oder das Postfach filtert die komprimierten Anhänge heraus. Prüfen Sie sie in dieser Reihenfolge. Eine Live-Abfrage von _dmarc.yourdomain.com klärt die ersten vier in unter einer Minute. dig TXT _dmarc.yourdomain.com +short zeigt einen zweiten Record, denn der kostenlose SPF-, DKIM- und DMARC-Prüfer zeigt nur den ersten, den er findet, und prüft die rua=-Syntax nicht. Wenn der Record sauber ist und ein paar Tage vergangen sind, sehen Sie sich das Zielpostfach an.

Schritt 1: Geben Sie ihm Zeit und wissen Sie, wer Berichte sendet#

Provider bündeln, was sie über einen Tag gesehen haben, und senden pro Domain einen Bericht. Die ersten Berichte treffen also 24 bis 48 Stunden nach dem Aktivieren des Records ein, manchmal später. Am ersten Tag kommt nichts an.

Zwei weitere Punkte setzen die Erwartungen:

• Nicht jeder Empfänger sendet Berichte. Große Mailbox-Provider tun es. Viele kleinere nie. Sie sammeln eine Stichprobe von Providern, kein vollständiges Protokoll.
• Ein Empfänger berichtet nur, wenn er E-Mails von Ihnen gesehen hat. Wenn Ihre Domain gestern nichts an einen bestimmten Provider gesendet hat, hat dieser Provider nichts zu berichten.

Wenn Sie drei volle Tage gewartet haben, gehen Sie zum Record über.

Schritt 2: Bestätigen, dass der Record am richtigen Ort liegt#

DMARC-Records liegen an einem bestimmten Namen: _dmarc. vor Ihrer Domain. Ein Record an der nackten Domain oder an dmarc.example.com wird ignoriert. Schlagen Sie nach, was wirklich veröffentlicht ist:

dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:reports@example.com"

Was Sie in der Antwort prüfen sollten:

• Der Record existiert überhaupt. Manche DNS-Hoster wollen im Hostfeld nur _dmarc, nicht den vollen Namen. Wer den vollen Namen eintippt, bekommt Ihre Domain doppelt angehängt. Hoster-spezifische Schritte finden Sie in Leitfäden wie Cloudflare und GoDaddy.
• Er beginnt exakt mit v=DMARC1, davor steht nichts.
• Er enthält ein p=-Tag. Nach RFC 9989 wird ein Record ohne gültiges p=, aber mit gültigem rua= als p=none behandelt und erhält weiterhin Berichte. Das ist also meist nicht die Ursache fehlender Berichte, aber veröffentlichen Sie das Tag trotzdem explizit.
• Tags sind durch Semikolons getrennt.

Denken Sie an DNS-Caching. Wenn Sie den Record gerade bearbeitet haben, nutzen Empfänger womöglich die alte Kopie, bis ihre TTL abläuft.

Schritt 3: Sicherstellen, dass es nur einen DMARC-Record gibt#

Eine Domain muss genau einen DMARC-Record veröffentlichen. Wenn zwei TXT-Records bei _dmarc beide mit v=DMARC1 beginnen, ignorieren Empfänger typischerweise beide, und die Berichte bleiben aus. Das passiert, wenn jemand einen neuen Record hinzufügt, ohne den alten zu löschen, oder wenn eine DNS-Migration den Record doppelt kopiert.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:old@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:new@example.com"

Löschen Sie einen, behalten Sie den anderen und führen Sie alle Adressen in einer einzigen rua=-Liste zusammen. Mehrere Berichtsziele werden innerhalb eines Records durch Kommas getrennt, nicht durch weitere Records.

Schritt 4: Die rua-Syntax prüfen#

Der rua=-Wert ist eine Liste von URIs, und jede muss mit mailto: beginnen. Typische Fehler:

Die letzte Zeile erwischt viele. Aggregatberichte kommen von rua. Wer nur ruf setzt, bekommt so gut wie nichts. Die vollständige Tag-Liste steht in So richten Sie DMARC ein.

Schritt 5: Berichte für eine andere Domain autorisieren#

Das ist die am häufigsten übersehene Ursache. Wenn Ihre rua=-Adresse in einer anderen Domain liegt als der, die der Record schützt, prüfen Empfänger, ob die andere Domain dem Empfang der Berichte zugestimmt hat. Sonst könnte jeder Berichtsfluten auf das Postfach eines Opfers lenken.

Nehmen Sie diesen Record für example.com:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:reports@thirdparty.example.net"

Weil die Adresse außerhalb von example.com liegt, muss die empfangende Domain einen Autorisierungs-Record veröffentlichen, dessen Name aus Ihrer Domain gebildet wird:

example.com._report._dmarc.thirdparty.example.net.  TXT  "v=DMARC1;"

Wenn dieser TXT-Record nicht existiert, verwerfen konforme Empfänger den Bericht. Sie können das prüfen mit:

dig TXT example.com._report._dmarc.thirdparty.example.net +short

Zwei praktische Hinweise:

• Wenn Sie beide Domains kontrollieren, fügen Sie den Autorisierungs-Record einfach am Ziel hinzu. Wenn ein Anbieter die Berichte für Sie empfängt, veröffentlicht er dies normalerweise für Sie oder sagt Ihnen, dass Sie es tun sollen.
• Berichte an ein Postfach in Ihrer eigenen Domain umgehen die Prüfung vollständig, weshalb eine einfache Weiterleitung dmarc@yourdomain.com die robusteste Einrichtung ist.

Schritt 6: Das Zielpostfach prüfen#

Wenn der Record gültig ist und die Autorisierung steht, kommen die Berichte womöglich an und gehen verloren:

• Anhangsfilter. Berichte kommen als .gz- oder .zip-Anhänge, manchmal als nacktes XML. Mailfilter, die komprimierte Anhänge entfernen, verwerfen sie stillschweigend. Prüfen Sie Spam, Quarantäne und jede Regel, die Archive löscht.
• Volles Postfach. Eine aktive Domain kann Dutzende Berichte pro Tag erzeugen. Ein kleines gemeinsames Postfach läuft schnell voll und beginnt, sie abzulehnen.
• Alias oder Weiterleitung, die umschreibt. Ein Gruppenalias, der externe Absender blockiert, lehnt Berichte von Providern ab.

Suchen Sie nach Betreffs, die „Report Domain“ und den Namen Ihrer Domain enthalten. Wenn Sie nach der Filterprüfung keine finden, liegt das Problem vorgelagert.

Ein eigenes Postfach oder ein Dienst, der die Berichte für Sie empfängt, vermeidet das meiste davon. Rohes XML im persönlichen Posteingang vergräbt außerdem das Signal, wie in So lesen Sie DMARC-Berichte beschrieben.

Wenn Sie eine Qualisend-Berichtsadresse verwenden#

Wenn Ihr rua= auf eine Adresse <key>@dmarc.qualisend.com aus DMARC-Berichte zeigt, werden die Zielprüfungen für Sie erledigt. Qualisend veröffentlicht einen Wildcard-Autorisierungs-Record, sodass Provider für jede Domain an diese Adresse senden, und Sie fügen den Autorisierungs-Record aus Schritt 5 nicht hinzu. Diese zusätzlichen Dinge können Daten trotzdem blockieren:

• Die Domain ist nicht abgedeckt. Berichte werden nur für Domains gespeichert, bei denen die Abdeckung in Ihrem Workspace eingeschaltet ist, oder für eine Subdomain einer solchen. Ein Bericht für eine nicht abgedeckte Domain wird angenommen, aber nicht gespeichert, das Dashboard bleibt also leer.
• Das Abonnement ist nicht aktiv. Berichte an eine Adresse, deren Workspace kein aktives DMARC-Abonnement hat, werden abgelehnt.
• Die Adresse wurde rotiert. Nach einer Rotation nimmt die alte Adresse sofort keine E-Mails mehr an, sodass jedes rua=, das sie noch auflistet, Berichte verliert, bis Sie das DNS aktualisieren.
• Der Record listet die Adresse nicht. Wenn bereits ein DMARC-Record existiert, fügen Sie ,mailto:<address> an seine rua=-Liste an und behalten Sie die Richtlinie und andere Adressen.

Qualisend bearbeitet nie Ihr DNS. Die Änderung am Record nehmen Sie bei Ihrem DNS-Hoster vor. Die Seite sagt Ihnen, dass die ersten Berichte meist innerhalb von 24 bis 48 Stunden ankommen, was dem Verhalten der Provider entspricht.

Subdomains und der Record, der gilt#

Wenn die fehlenden Berichte eine Subdomain betreffen, sehen Sie nach, was dort tatsächlich veröffentlicht ist. Eine Subdomain mit eigenem DMARC-Record nutzt diesen, und wenn dieser Record kein rua= hat, wird nichts an die Adresse der übergeordneten Domain gesendet. Eine Subdomain ohne Record greift auf den Record der übergeordneten Domain und ihre sp=-Richtlinie zurück. Berichte nennen die Domain in der Richtlinie, suchen Sie sie also unter diesem Namen statt unter Ihrer Hauptdomain.

Nach jeder DNS-Änderung lohnt es sich, die ganze Domain durch die Domain-Zustandsprüfung laufen zu lassen. Er markiert einen fehlenden DMARC-Record, einen Record ohne Richtlinien-Tag und eine p=none-Richtlinie und zeigt den veröffentlichten Record, sodass Sie den rua=-Wert selbst lesen können. Die kostenpflichtige Domain-Zustand-Überwachung warnt außerdem, wenn eine gültige Richtlinie gar kein rua= hat. Wenn das nach DNS-Änderungen immer wieder passiert, erklärt der Leitfaden zur Domain-Zustand-Überwachung, wie Sie es abfangen, bevor Berichte ausbleiben.

Eine abschließende Checkliste#

• Warten Sie 48 Stunden, nachdem der Record aktiv ist.
• Führen Sie dig TXT _dmarc.yourdomain.com aus und lesen Sie das Ergebnis.
• Bestätigen Sie einen Record, der mit v=DMARC1 beginnt, mit explizitem p=.
• Bestätigen Sie rua=mailto: mit Kommas zwischen Adressen.
• Wenn die Adresse in einer anderen Domain liegt, prüfen Sie den Autorisierungs-Record _report._dmarc.
• Prüfen Sie Spam, Quarantäne, Größenlimits und Filter des Zielpostfachs.
• Stellen Sie sicher, dass die Domain tatsächlich E-Mails an Provider gesendet hat, die berichten.

Wenn die Berichte endlich ankommen, ist die nächste Aufgabe, sie zu verstehen. Das behandeln DMARC-Monitoring und Wer sendet mit Ihrer Domain.

DMARC-Berichte zeigen Ihnen, wer mit Ihrer Domain sendet, aber nicht, ob Ihre Liste sauber ist. Wenn Sie die Liste als Nächstes prüfen wollen, bietet der kostenlose Tarif auf der Preisseite 100 Credits für die vollständige Verifizierung, und der kostenlose E-Mail-Checker prüft einzelne Adressen. Funktionierende Authentifizierung braucht trotzdem eine gesunde Liste, um den Posteingang zu erreichen.