DMARC-Eintrag erstellen: DNS und Richtlinien prüfen

Oft entsteht der Wunsch, einen DMARC-Eintrag zu erstellen, erst nach gefälschten Nachrichten, Gmail-Warnungen oder einer DNS-Anfrage eines Anbieters. Auch uneinheitliche SPF- und DKIM-Ergebnisse können der Anlass sein. Für den Aufbau der übrigen Infrastruktur hilft unser Leitfaden zu geschäftlicher E-Mail, damit Domain, Postfach und DNS zusammenpassen.

Ein vorhandener Eintrag ist noch keine wirksame Konfiguration. Falscher Hostname, ungeeignete Richtlinie, unerreichbare Berichtsadresse und fehlende Ausrichtung können zunächst unbemerkt bleiben. Domainfälschungen und Probleme legitimer Mail werden dadurch nicht automatisch behoben.

Dieser Leitfaden erklärt wichtige Tags, die Veröffentlichung unter _dmarc.yourdomain.com und den geprüften Übergang von Beobachtung zu Durchsetzungsanforderungen.

Was ein DMARC-Eintrag enthält

Veröffentlichen Sie unter _dmarc.yourdomain.com einen TXT-Eintrag, der mit v=DMARC1 beginnt und eine gültige Richtlinie wie p=none, p=quarantine oder p=reject enthält. DMARC fordert eine Behandlung an, wenn weder SPF noch DKIM einen erfolgreichen zur From-Domain ausgerichteten Pfad liefert.

Ein minimales gültiges Beispiel:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none;

Dieser Eintrag fordert keine Einschränkungen durch DMARC an. Ohne Berichtsadresse fordert er allerdings auch keine Berichte an; andere lokale Filter können weiterhin wirken.

Ein Beispiel mit aggregierten Berichten:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

Die folgende Alternative ist erst nach Versandprüfung zu erwägen, nicht zusätzlich zu veröffentlichen:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

Nach RFC 7489 muss v zuerst stehen und p vorhanden sein. Ungültige Einträge können die Richtlinienauswertung verhindern. Protokolldetails erläutert RFC 7489.

Wo der DMARC-Eintrag im DNS steht

Der Eintrag gehört nicht an die Domainwurzel, sondern zum Host _dmarc. Für example.com wird _dmarc.example.com abgefragt. Ein anderer Veröffentlichungsort liefert bei dieser Suche nicht die benötigte Richtlinie.

Häufige Fehler sind die Veröffentlichung bei @ oder die Eingabe von _dmarc.example.com in einer Oberfläche, die nur _dmarc erwartet. Ob Kurzname oder vollständiger Name benötigt wird, hängt vom DNS-Anbieter ab.

Prüfen Sie die Veröffentlichung außerhalb der Verwaltungsoberfläche:

dig txt _dmarc.example.com +short
nslookup -q=txt _dmarc.example.com

Gesucht ist ein gültiger DMARC-Richtlinieneintrag, beginnend mit v=DMARC1. Mehrere Zeichenketten innerhalb desselben TXT-Eintrags sind nicht dasselbe wie mehrere Richtlinieneinträge; auch andere TXT-Inhalte müssen getrennt beurteilt werden.

Bei TrekMail können Sie die Domain hinzufügen, erforderliche Werte übernehmen und DNS-Ergebnisse prüfen. Dazu gehören Domain hinzufügen, Erforderliche DNS-Einträge und DNS-Status prüfen. Die tatsächlichen Versandwege benötigen zusätzliche Nachrichtentests.

Wichtige Tags beim Erstellen des Eintrags

Beginnen Sie mit den erforderlichen Tags v und p sowie einer geeigneten Berichtsadresse über rua. Zusätzliche Ausrichtungs- und Berichtseinstellungen sollten einen konkreten betrieblichen Zweck erfüllen.

Ein gültiger Eintrag mit p=none ohne rua fordert keine aggregierten Berichte an. Andere Protokolle können weiter Hinweise liefern, ersetzen aber nicht automatisch diese Rückmeldungen.

Die passende Richtlinie wählen

Bei unvollständig geprüftem Versand kann p=none den Anfang bilden. Nach Berichten, Inventarabgleich und Nachrichtentests lässt sich p=quarantine erwägen. p=reject sollte erst nach Prüfung kritischer und seltener legitimer Quellen folgen; eine unbekannte IP beweist keine unbefugte Sendung.

Googles beschriebene Anforderungen an Massenversender umfassen SPF und DKIM sowie From-Ausrichtung über mindestens einen erfolgreichen Mechanismus. Prüfen Sie die aktuelle Anwendbarkeit in Googles Absender-FAQ, statt eine mögliche künftige Anforderung vorwegzunehmen.

Eine aktivierte Authentifizierung ist kein ausreichender Nachweis. Nutzt ein CRM Ihre From-Domain, aber seine eigene Signatur- und Bounce-Domain, kann DMARC ohne anderen erfolgreichen ausgerichteten Pfad scheitern.

Schrittweise einen DMARC-Eintrag erstellen

Erfassen Sie Sender, veröffentlichen Sie eine Beobachtungsrichtlinie und prüfen Sie Berichte, Protokolle und reale Mail. Ruhige Berichte allein beweisen nicht, dass seltene wichtige Versandwege erfasst sind.

1. Alle Dienste erfassen, einschließlich Google Workspace, Microsoft 365, Support, CRM, Formularen, Rechnungs- und Newsletteranwendungen.
2. Gültiges SPF und DKIM für die tatsächlichen Versandwege prüfen. DMARC ersetzt diese Verfahren nicht. Die SPF-Grenze betrifft DNS-auslösende Mechanismen und Modifikatoren einschließlich verschachtelter Auswertung, nicht alle Abfragen.
3. Eine betreute Adresse wie dmarc@yourdomain.com oder einen Berichtsdienst einrichten; Datenschutz und gegebenenfalls externe DNS-Autorisierung beachten.
4. Mit p=none beginnen, wenn der Versand noch nicht vollständig geprüft ist.
5. Verfügbare Berichte mit Inventar, Protokollen und Tests abgleichen.
6. Erfolgreiche Authentifizierung zur From-Domain ausrichten.
7. Nach Prüfung p=quarantine erwägen.
8. Nach Klärung verbleibender Fehler und seltener Abläufe p=reject erwägen.

Ein mögliches Beobachtungsbeispiel für 2026, das an Ihre Umgebung anzupassen ist:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

Bei Weiterleitung hilft Domainmail an Gmail weiterleiten. SPF kann am neuen Server scheitern. Gültiges ausgerichtetes DKIM kann DMARC bestehen lassen, wenn signierte Daten unter den Kanonisierungsregeln erhalten bleiben. ARC kann eine lokale Ausnahmeentscheidung unterstützen, verwandelt einen DMARC-Fehler aber nicht in einen echten Prüfungserfolg.

Häufige Fehler beim Erstellen des Eintrags

Falsche Hostnamen, mehrere Richtlinieneinträge, unerreichbare Berichtszieladressen und ungeprüfte SPF- oder DKIM-Konfigurationen gehören zu den typischen Ursachen. Prüfen Sie die Veröffentlichung extern und testen Sie den tatsächlichen Versand.

Besonders häufig sind diese Fehler:

1. Veröffentlichung an der Domainwurzel statt unter _dmarc.
Ein Eintrag bei @ liegt nicht am benötigten Abfrageort.

2. Mehrere DMARC-Richtlinieneinträge.
RFC 7489 beschreibt den Abbruch der Auswertung bei mehreren gültigen Richtlinieneinträgen. Das ist von mehreren Zeichenketten innerhalb eines TXT-Eintrags zu unterscheiden.

3. Sofort mit p=reject beginnen.
Ein vergessener Sender kann dadurch Passwortmails, Rechnungen oder Supportantworten verlieren, wenn der Empfänger die Ablehnung umsetzt.

4. rua auf eine unerreichbare Adresse setzen.
Dann kommen dort keine Berichte an. Ihr Fehlen beweist allerdings auch bei erreichbarer Adresse nicht, dass überall Berichte versendet wurden.

5. Von DMARC eine Reparatur der Weiterleitung erwarten.
DMARC benötigt erfolgreiches ausgerichtetes SPF oder DKIM. Bei Weiterleitung kann SPF scheitern; DKIM hilft nur bei weiterhin gültiger ausgerichteter Signatur.

Bestellbestätigungen, Supportantworten und Marketing nutzen unterschiedliche SMTP-Anbieter. Sie veröffentlichen p=reject, bevor alle geprüft sind. Ein Teil besteht, andere Nachrichten scheitern und können abgelehnt werden. Die fehlende Versandprüfung wird so zum Kundenproblem.

Für den Gesamtaufbau erläutert E-Mail mit eigener Domain erstellen die DNS- und Postfachkonfiguration rund um SPF, DKIM und DMARC.

DMARC für viele Domains verwalten

Tabellen, getrennte Registrarzugänge und alte TXT-Werte erschweren konsistente Verwaltung. Eine gemeinsame Oberfläche mit DNS-Prüfungen und nachvollziehbaren Einträgen kann helfen, muss aber den tatsächlichen DNS-Anbieter und Versandweg berücksichtigen.

TrekMail kann je nach Tarif mehrere Domains, gemeinsamen Speicher, IMAP-Postfächer, Migration, Catch-all, Weiterleitung und eigenen oder verwalteten SMTP verbinden. Nano bietet eine kostenlose Option für bis zu 10 Domains mit eigenem SMTP. Als Preisorientierung für bezahlte Tarife werden ab $3.50/Monat genannt. Aktuelle Bedingungen stehen bei TrekMail-Tarife.

Eine gemeinsame Oberfläche kann den Wechsel zwischen fünf Anbietern und zwanzig Browser-Tabs verringern. Sie ersetzt weder die Prüfung aller Nachrichtenwege noch die Planung eines MX- oder Anwendungswechsels; IMAP-Import kopiert vorhandene Mail.

Letzte Prüfung vor der Durchsetzung

Prüfen Sie erfolgreichen ausgerichteten Versand aller legitimen Quellen, eine betreute Berichtsadresse und einen gültigen Richtlinieneintrag unter _dmarc. DMARC ist die Richtlinienebene, keine Umgehung fehlerhafter Authentifizierung.

Die abschließende Kurzprüfung:

1. Genau einen gültigen DMARC-Richtlinieneintrag veröffentlichen.
2. Den passenden Host _dmarc verwenden.
3. Mit v=DMARC1; p=... beginnen.
4. rua auf ein erreichbares betreutes Ziel richten.
5. Je tatsächlicher Envelope-Domain einen gültigen SPF-Eintrag verwenden.
6. DKIM für unterstützende Sender aktivieren und Ausrichtung testen.
7. Den erwarteten Wert per externer DNS-Abfrage bestätigen.
8. Mit none beobachten, sofern nicht bereits alle wichtigen Versandwege geprüft sind.

DMARC erfordert auch nach der Einführung Pflege. TrekMail kann die Verwaltung von Domains, IMAP-Postfächern, DNS-Status, SMTP und Migration je nach Tarif zusammenführen. Informationen finden Sie auf trekmail.net; Änderungen sollten weiterhin mit echten Nachrichten getestet werden.