No DMARC record found: die eine Zeile, die deiner Domain fehlt

Kurz gesagt

• Die Meldung heisst, dass es bei _dmarc.yourdomain.com keinen TXT-Eintrag gibt. Dein Mailserver ist nicht kaputt.
• Lege einen TXT-Eintrag mit dem Host _dmarc und dem Wert v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com an. Mit p=none bleibt die Zustellung genau wie bisher.
• Gmail, Yahoo und Outlook.com verlangen den Eintrag nur von Massenversendern. Lege ihn trotzdem an: Google zählt die ganze Domain und hebt den Status als Massenversender nie wieder auf, und Berichte gibt es erst, wenn ein Eintrag existiert.
• Findet ein Prüftool weiterhin nichts, suche nach dem falschen DNS-Anbieter, einem doppelten Hostnamen oder zwei DMARC-Einträgen. Zwei Einträge heben sich gegenseitig auf.
• Der Standard hat sich im Mai 2026 mit RFC 9989 geändert: pct ist weg, t und np sind neu. Googles Hilfe beschreibt pct noch, Stand Oktober 2026.

«No DMARC record found» (kein DMARC-Eintrag gefunden) heisst, dass ein Prüftool im DNS nach einem TXT-Eintrag bei _dmarc.yourdomain.com gefragt und nichts zurückbekommen hat. An deinem Mailserver ist nichts kaputt. Die Lösung ist ein TXT-Eintrag mit dem Host _dmarc und dem Wert v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Mit p=none werden deine Mails genau wie bisher zugestellt. Du teilst Empfängern nur mit, dass du mitmachst, und du bekommst ab jetzt Berichte.

DMARC ist der dritte der drei E-Mail-Einträge, neben SPF und DKIM. SPF führt die Server auf, die für deine Domain senden dürfen. DKIM signiert jede Nachricht. DMARC sagt einem Empfänger, was er tun soll, wenn keines von beiden für die Domain in deiner From-Adresse bürgt, und wohin er eine tägliche Zusammenfassung schicken soll. Seit Mai 2026 ist es in RFC 9989 festgelegt, das das ältere RFC 7489 abgelöst hat. Viele Anleitungen beschreiben noch die ältere Fassung, und Googles Hilfeseite tut das Stand Oktober 2026 ebenfalls.

Der Eintrag, den du anlegst

Melde dich dort an, wo das DNS deiner Domain verwaltet wird. Das ist die Firma, auf die deine Nameserver zeigen, und nicht immer die, bei der du die Domain gekauft hast. Lege einen neuen Eintrag mit diesen Werten an:

Als Zeile in einer Zonendatei ausgeschrieben sieht der fertige Eintrag so aus:

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

Ersetze example.com durch deine eigene Domain. Die drei Teile bewirken Folgendes:

• v=DMARC1 kennzeichnet die Zeile als DMARC-Eintrag. Es muss an erster Stelle stehen, mit DMARC1 in Grossbuchstaben. Sonst ignorieren Empfänger den ganzen Eintrag.
• p=none ist die Richtlinie: Behandelt meine Mails so, wie ihr es ohnehin tun würdet. Wegen dieses Eintrags wird nichts blockiert oder in den Spam verschoben.
• rua=mailto:… ist die Adresse für die täglichen Berichte. Richte diese Adresse ein, oder einen Alias, der an dich weiterleitet, bevor du den Eintrag veröffentlichst.

Google führt dieselben drei Felder in DMARC einrichten auf. Es verlangt ausserdem, dass SPF und DKIM seit 48 Stunden funktionieren, bevor du DMARC hinzufügst. Beanstandet dein Prüftool auch diese beiden, behebe sie zuerst.

So prüfst du, ob es geklappt hat

Frag das DNS selbst. Öffne unter macOS oder Linux ein Terminal und verwende dig. Unter Windows verwendest du nslookup.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Ist der Eintrag aktiv, kommt die Zeile in Anführungszeichen zurück. Das hat Googles eigene Domain am 5. Oktober 2026 geantwortet:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Eine leere Antwort heisst, dass der Eintrag noch nicht da ist oder nicht dort, wo Empfänger ihn suchen. Sobald deine eigene Abfrage die Zeile zeigt, lass das Prüftool, das dir die Meldung gezeigt hat, noch einmal laufen. MXToolbox zum Beispiel formuliert das Problem als «No DMARC Record found» und erklärt, dass «deine Domain keinen veröffentlichten DMARC-Eintrag hat».

Was die einzelnen Teile eines DMARC-Eintrags bedeuten

Ein Eintrag ist eine Liste von Paaren der Form tag=value, getrennt durch Strichpunkte. Im Standard ist nur v zwingend, und es muss an erster Stelle stehen. Setze p an die zweite: Googles Hilfe hält fest, dass «die Tags v und p zuerst aufgeführt werden müssen», und der ältere Standard erwartete dieselbe Reihenfolge. Das sind die Tags aus RFC 9989, Abschnitt 4.7:

Ältere Einträge enden oft auf pct=100. Das Tag sollte eine Richtlinie auf einen Teil der durchfallenden Mails anwenden. RFC 9989 hat es zusammen mit rf und ri entfernt und nennt den Grund:

Die Betriebserfahrung hat gezeigt, dass das Tag «pct» meist nicht genau angewendet wurde, ausser der angegebene Wert war 0 oder 100 (der Standardwert), und die Ungenauigkeiten bei anderen Werten unterschieden sich von einer Implementierung zur anderen stark.

Empfänger müssen Tags ignorieren, die sie nicht kennen, ein altes pct=100 schadet also nicht. Die Einträge von yahoo.com und microsoft.com enthielten es am 5. Oktober 2026 noch, und Googles Hilfeseite empfiehlt pct weiterhin für eine schrittweise Einführung. In einem neuen Eintrag lässt du es weg.

Brauchst du DMARC, wenn du nur ein paar E-Mails pro Tag sendest?

Nach den veröffentlichten Regeln der grossen Mailanbieter ist ein DMARC-Eintrag Pflicht, sobald du in grossen Mengen sendest. Darunter ist er eine Empfehlung.

Die Quellen sind Googles Richtlinien für E-Mail-Absender, Yahoos Sender Best Practices und Microsofts Ankündigung für Absender mit hohem Volumen, alle Stand Oktober 2026. Sendest du dreissig E-Mails pro Tag aus einem Postfach, verlangt keiner von ihnen den Eintrag. Es gibt trotzdem drei Gründe, ihn jetzt anzulegen.

• Die Schwelle wird pro Domain gezählt, und sie wird nicht zurückgesetzt. Google zählt alle Nachrichten an private Gmail-Konten zusammen, die von derselben Hauptdomain kommen, Subdomains eingeschlossen. Seine FAQ für Absender sagen: «Absender, die die obigen Kriterien mindestens einmal erfüllen, gelten dauerhaft als Massenversender.»
• Google und Yahoo empfehlen ihn beide für alle. Google schreibt: «Wir empfehlen, für deine Domains immer SPF, DKIM und DMARC einzurichten.» Yahoo «rät allen Absendern dringend, für jede Domain, die Mails sendet, eine DMARC-Richtlinie zu veröffentlichen».
• Ohne den Eintrag bekommst du keine Berichte. An ihnen siehst du, welche Server Mails mit deiner Domain in der From-Zeile senden, deine eigenen Tools ebenso wie Fremde.

Für Massenversender hat der fehlende Eintrag Folgen. Googles FAQ für Absender führen dafür den vorübergehenden Fehler 4.7.31 auf: «Die sendende Domain hat keinen DMARC-Eintrag, oder der DMARC-Eintrag gibt keine DMARC-Richtlinie an.» Dieselbe Seite sagt, dass Mails, die die Anforderungen nicht erfüllen, seit November 2025 mit «vorübergehenden und dauerhaften Ablehnungen» rechnen müssen.

Eintrag angelegt, und das Prüftool findet immer noch nichts?

Dann ist meist einer dieser Punkte die Ursache. Geh sie mit der dig-Abfrage von oben durch.

• Du hast das DNS am falschen Ort bearbeitet. Liegen deine Nameserver bei einer anderen Firma als deinem Registrar, werden Einträge, die du beim Registrar anlegst, nie abgefragt. dig +short NS example.com zeigt, wer für deine Domain antwortet.
• Der Host ist falsch. Der Eintrag liegt auf example.com selbst oder auf einem doppelten Namen, wie oben beschrieben. Empfänger fragen nur nach _dmarc.example.com.
• Es gibt zwei DMARC-Einträge. Der Standard ist hier streng: «Werden für ein einzelnes Ziel mehrere DMARC-Richtlinieneinträge zurückgegeben, werden alle verworfen.» Führe sie zu einem zusammen. Zwei Berichtsadressen kommen in ein rua, durch ein Komma getrennt.
• Das erste Tag lautet nicht genau v=DMARC1. Kleinbuchstaben, ein Tippfehler wie DMARC 1 oder ein p= davor machen den Eintrag ungültig.
• Der Eintragstyp ist nicht TXT, oder der Wert wurde mit typografischen Anführungszeichen aus einem Dokument eingefügt. Tippe den Wert als reinen Text, ohne Anführungszeichen, es sei denn, die Hilfe deines DNS-Anbieters verlangt sie.
• Eine alte Antwort liegt noch im Cache. Resolver merken sich «kein solcher Eintrag» eine Weile. Frag einen deiner eigenen Nameserver direkt, indem du seinen Namen an die Abfrage hängst, zum Beispiel dig +short TXT _dmarc.example.com @ns1.example.net. Zeigt sich der Eintrag dort, ziehen die Prüftools nach.

Wohin die Berichte gehen und was du damit machst

Jeder Empfänger, der Mails mit deiner Domain in der From-Zeile bekommen hat, schickt einen Bericht an die rua-Adresse. Laut Googles Seite Informationen zu DMARC-Berichten werden sie «in der Regel einmal täglich per E-Mail gesendet». Der Bericht ist eine XML-Datei, meist komprimiert, im Anhang einer E-Mail. RFC 9990 beschreibt das Format.

Google warnt, dass grosse Organisationen «täglich bis zu Hunderte oder sogar Tausende Berichte bekommen können», und empfiehlt eine Gruppe oder ein eigenes Postfach. Die Zahl hängt davon ab, wie viel du sendest und an wie viele Domains, ein oder zwei Postfächer erzeugen also weit weniger. Ein Alias wie dmarc@ mit einem Filter in einen eigenen Ordner genügt.

Die Adresse sollte auf derselben Domain liegen wie der Eintrag. Willst du die Berichte woanders haben, muss die andere Domain zustimmen, indem sie einen eigenen Eintrag veröffentlicht. Ohne ihn müssen Empfänger die Adresse ignorieren (RFC 9990, Abschnitt 4).

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

Deshalb funktioniert eine kostenlose Gmail-Adresse nicht als Berichtsadresse: gmail.com veröffentlichte keinen solchen Eintrag, als wir am 5. Oktober 2026 nachgesehen haben.

In der Datei steht jeder Block record für einen sendenden Server: seine IP-Adresse, die Zahl der Nachrichten und unter policy_evaluated, ob DKIM und SPF für deine Domain bestanden haben. Du suchst zwei Dinge. Server, die du kennst und die fail zeigen, musst du in Ordnung bringen, und DMARC schlägt fehl, obwohl SPF und DKIM bestehen erklärt, wie. Server, die du nicht kennst, sind entweder ein Tool, das du vergessen hast, oder jemand, der deinen Namen benutzt.

Nach p=none: wann du die Richtlinie verschärfst

p=none ist ein Beobachtungsmodus. Er erfüllt das Minimum, das die Mailanbieter verlangen, und hindert niemanden daran, deine Adresse zu fälschen. Das tun nur p=quarantine, das Empfänger bittet, durchfallende Mails als verdächtig zu behandeln, und p=reject, das sie bittet, solche Mails abzuweisen.

Bevor du verschärfst, muss jede legitime Quelle deiner Mails bestehen. RFC 9989 sagt, dass solche Lücken «vor jedem Versuch behoben werden MÜSSEN», die Richtlinie durchzusetzen, und dass es, je nachdem, wie oft du sendest, «viele Monate dauern kann», bis die Berichte dir Sicherheit geben. Googles Seite zur Einführung hält eine Woche Berichte für «in der Regel ausreichend». Mit einem Postfach und einem oder zwei Tools bist du näher an Googles Angabe, aber gib dir ein paar Wochen, damit auch der monatliche Rechnungslauf und das Kontaktformular auftauchen.

Beim Schritt selbst sind sich die beiden Quellen nicht einig. Google schlägt weiterhin p=quarantine; pct=5 vor und rät, die Zahl dann zu erhöhen. Der Standard hat pct gestrichen und bietet stattdessen das hier:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y bittet Empfänger, Fehlschläge vorerst eine Stufe tiefer zu behandeln, also als none. Bleiben die Berichte sauber, entferne t=y. Beachte, dass ein Empfänger, der das Tag nicht kennt, es ignoriert und quarantine voll anwendet, und dass Googles Seiten t Stand Oktober 2026 nicht erwähnen. Würde eine strengere Richtlinie Mails treffen, die du noch nicht in Ordnung bringen kannst, bleib bei p=none.

Wo WarmupBay ins Spiel kommt

Wenn du ein Postfach verbindest, prüft WarmupBay SPF, DKIM und DMARC für dessen Domain. Fehlt der DMARC-Eintrag, zeigt es dir einen fertigen zum Kopieren. Du kannst das Warmup trotzdem starten. Fehlen die Einträge nach 72 Stunden noch, stoppt das Warmup.

WarmupBay kann den Eintrag nicht für dich anlegen, denn dein DNS gehört dir, und es sammelt oder liest keine DMARC-Berichte. Es übernimmt den Schritt nach den Einträgen: Dein Postfach tauscht täglich ein paar E-Mails mit anderen Postfächern in einem gemeinsamen Pool aus, beginnend mit drei und jeden Tag einer mehr, sodass sich die Versandaktivität schrittweise aufbaut. Für 10 E-Mails pro Tag ist es gratis. Sieh dir an, was die Prüfung und das Warmup abdecken, oder verbinde dein Postfach, sobald der Eintrag steht.

Häufige Fragen

Gilt ein DMARC-Eintrag auf example.com auch für Subdomains wie news.example.com?

Ja. Ein Empfänger fragt zuerst nach einem Eintrag bei _dmarc.news.example.com. Gibt es keinen, greift er auf den Eintrag der Organisationsdomain zurück, example.com. Für die Subdomain gilt die Richtlinie in sp, wenn du sie gesetzt hast, sonst die in p.

Kann ich v=DMARC1; p=none ohne rua-Adresse veröffentlichen?

Ja. Das ist ein gültiger Eintrag, und er zählt als veröffentlichte Richtlinie. Du bekommst keine Berichte und siehst deshalb nicht, ob deine eigenen Mails bestehen oder wer sonst deine Domain verwendet. Yahoo nennt eine funktionierende rua-Adresse dringend empfohlen, und Google empfiehlt, immer eine anzugeben.

Brauche ich einen DMARC-Eintrag für eine zweite Domain, die ich nur für Outreach nutze?

Ja. Empfänger schlagen die Domain in der From-Adresse jeder Nachricht nach, ein Eintrag auf deiner Hauptdomain deckt eine andere Domain also nicht ab. Verwende auf der zweiten Domain dieselbe Zeile. Sollen ihre Berichte an eine Adresse auf deiner Hauptdomain gehen, muss die Hauptdomain den Autorisierungseintrag veröffentlichen, der unter «Wohin die Berichte gehen» beschrieben ist.

Was sollte eine Domain veröffentlichen, die nie E-Mails sendet?

Das strenge Paar. Die M3AAWG empfiehlt für Domains, die nie Mails senden, den SPF-Eintrag v=spf1 -all und einen DMARC-Eintrag mit p=reject, damit niemand sie in einer From-Adresse verwenden kann. Für DMARC ist das die Zeile v=DMARC1; p=reject bei _dmarc.

Ist p=none schlechter für meine Mails als p=quarantine oder p=reject?

Die veröffentlichten Absenderregeln von Gmail, Yahoo und Outlook.com verlangen mindestens p=none und nichts Strengeres. Die Richtlinie entscheidet, was mit Mails passiert, die bei DMARC durchfallen, und dazu gehören gefälschte Mails in deinem Namen. Eine Funktion braucht mehr: BIMI, das Logo neben deinen Nachrichten, setzt laut Googles Hilfe quarantine oder reject voraus.

Quellen

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)