DMARC-Eintrag: 5 Richtlinienbeispiele

Ein Beispiel für einen DMARC-Eintrag zeigt eine DNS-TXT-Richtlinie für Mail, bei der weder SPF noch DKIM erfolgreich und zur From-Domain ausgerichtet ist. Eine falsche Konfiguration kann legitime Nachrichten beeinträchtigen, ohne Domainfälschungen zuverlässig einzuschränken. Den Gesamtaufbau erläutern geschäftliche E-Mail und E-Mail mit eigener Domain erstellen.

Veröffentlichen Sie einen gültigen Richtlinieneintrag unter _dmarc.yourdomain.com. Bei ungeprüftem Versand beginnen Sie mit Beobachtung und erwägen Einschränkungen erst nach Prüfung der Sender. TrekMails Leitfaden zu erforderlichen DNS-Einträgen beschreibt die Grundlagen; hier geht es um die Auswahl eines passenden DMARC-Eintrags.

Was ein DMARC-Eintrag tatsächlich bewirkt

Ein DMARC-Beispieleintrag bezeichnet das Protokoll, die gewünschte Behandlung fehlgeschlagener Mail und ein Berichtsziel. DMARC baut auf SPF und DKIM auf. Mindestens eines muss erfolgreich sein und zur sichtbaren From-Domain ausgerichtet sein; reine Ausrichtung genügt nicht.

Ein kurzer Eintrag für Berichte ohne DMARC-Durchsetzungsanforderung:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com

Die Bestandteile:

v=DMARC1 kennzeichnet den Eintrag als DMARC.
p=none fordert keine Quarantäne oder Ablehnung durch DMARC an; lokale Filter bleiben möglich.
rua=mailto:dmarc@example.com fordert aggregierte XML-Berichte an, soweit Empfänger sie bereitstellen.

Darauf bauen weitere Einstellungen auf. Das Berichtsziel sollte betreut und zugriffsgeschützt sein; externe Ziele können eine DNS-Autorisierung benötigen.

DMARC ist eine Richtlinie, kein Vertrauensurteil über den Inhalt. SPF und DKIM liefern Authentifizierungsergebnisse. DMARC prüft, ob ein erfolgreicher Pfad zur sichtbaren From-Domain ausgerichtet ist.

5 DMARC-Beispiele für unterschiedliche Anforderungen

Ein allgemeines DMARC-Beispiel passt nicht zu jedem Versand. Die folgenden Einträge sind Alternativen: für Beobachtung, schrittweise Durchsetzung oder besondere Subdomain- und Ausrichtungsanforderungen. Veröffentlichen Sie nicht alle gemeinsam.

Nur beobachten. Für die Erfassung tatsächlicher Sender und Weiterleitungswege.
```
v=DMARC1; p=none; rua=mailto:dmarc@example.com
```
Verdächtige Behandlung anfordern. Nach Prüfung legitimer Versandwege als Zwischenschritt erwägen.
```
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
```
Ablehnung anfordern. Erst nach Untersuchung wichtiger und seltener Sender.
```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
```
Stufenweise Einführung. Einen Anteil fehlgeschlagener Mail zur Durchsetzung anfordern; Empfänger können unterschiedlich reagieren.
```
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
```
Subdomainrichtlinie und strikte Ausrichtung. Für bewusst getrennte Behandlung und geprüfte exakte Domainübereinstimmung. Eine Subdomain ohne eigenen passenden Eintrag erbt dabei die Richtlinie der Organisationsdomain.
```
v=DMARC1; p=reject; sp=quarantine; adkim=s; aspf=s; rua=mailto:dmarc@example.com
```

Richtlinie	Möglicher Einsatz	Nutzen	Risiko
`p=none`	Sender erfassen	Keine DMARC-Einschränkung anfordern	Keine zusätzliche Durchsetzung; andere Filter gelten weiter
`p=quarantine`	Geprüfter Versand	Verdächtige Behandlung anfordern	Legitime nicht ausgerichtete Mail kann betroffen sein
`p=reject`	Umfassend getestete Konfiguration	Ablehnung fehlgeschlagener Domainauthentifizierung anfordern	Fehlkonfiguration kann legitime Mail treffen
`pct=25`	Geplante Einführung	Begrenzten Anteil der Fehler zur Durchsetzung anfordern	Keine garantierte Abdeckung oder Risikobegrenzung
`adkim=s; aspf=s`	Exakte Domainanforderungen	Exakte Ausrichtung prüfen	Mehr externe Versandkonfigurationen benötigen Anpassung

Wenn die legitimen Versandwege bereits geprüft sind, kann dieses DMARC-Beispiel ein möglicher nächster Schritt sein. Es ist keine universelle sichere Anfangskonfiguration:

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

Quarantine fordert bereits Einschränkungen an. Der Empfänger bestimmt die konkrete Behandlung; Spamordner und Wiederherstellung sind nicht garantiert.

Ein DMARC-Beispiel im DNS veröffentlichen

Für einen DMARC-Eintrag verwenden Sie den Host _dmarc, veröffentlichen einen passenden Wert und prüfen ihn extern. Häufige Fehler sind die Domainwurzel statt _dmarc sowie mehrere Richtlinieneinträge. Mehrere Zeichenketten desselben TXT-Eintrags sind davon zu unterscheiden.

Das folgende Muster ist bei geprüfter Quarantine-Einführung an die Eingaberegeln Ihres DNS-Anbieters anzupassen:

Host: _dmarc
Type: TXT
TTL: 3600
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

Prüfen Sie anschließend den Wert; die TTL garantiert keine bestimmte weltweite Verbreitungszeit:

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

Ein gültiger Richtlinieneintrag mit v=DMARC1 am Anfang bestätigt die DNS-Veröffentlichung, aber noch nicht alle tatsächlichen Versandwege.

Nach RFC 7489 wird bei mehreren gültigen DMARC-Richtlinien oder fehlendem passenden Eintrag keine solche Richtlinie angewendet. Prüfen Sie zudem das DNS-Format: Manche Oberflächen erwarten _dmarc, andere den vollständigen Hostnamen.

Den gesamten DNS-Aufbau mit MX, SPF, DKIM und DMARC erläutern TrekMails erforderliche DNS-Einträge.

Häufige Fehler mit Auswirkungen auf Mail

Ein fehlerhaftes DMARC-Beispiel kann am falschen Host, an mehreren Richtlinien, einer unerreichbaren Berichtsadresse oder zu früh gewählter strikter Ausrichtung scheitern. Ein SPF-Fehler nach Weiterleitung ist nicht automatisch ein DMARC-Fehler.

Besonders wichtig:

DMARC an der Domainwurzel veröffentlichen. Der Host lautet _dmarc, nicht @.
Mehrere DMARC-Richtlinien veröffentlichen. Pro Abfrageort ist ein gültiger Richtlinieneintrag erforderlich.
p=reject vor vollständiger Prüfung wählen. Vergessene CRM- oder Rechnungsdienste können betroffen sein.
DMARC für Weiterleitungsfehler verantwortlich machen. SPF kann scheitern, während gültiges ausgerichtetes DKIM bei erhaltenen signierten Daten genügt. Details erläutern Domainmail an Gmail weiterleiten und E-Mail-Alias-Weiterleitung.
Ausrichtung übersehen. Nicht ausgerichtetes erfolgreiches SPF führt nur dann zu DMARC-Fehlern, wenn auch kein erfolgreiches ausgerichtetes DKIM vorhanden ist.
Berichte nicht einrichten. Ohne rua fehlen diese angeforderten Rückmeldungen; andere Protokolle können weiterhin Hinweise geben.

Googles Absenderanforderungen können für die entsprechenden Sender bei fehlendem DMARC oder Ausrichtungsfehlern Einschränkungen vorsehen. Die geltenden Bedingungen stehen in der offiziellen Absender-FAQ. Sie sollten nicht pauschal auf jeden Versandumfang übertragen werden.

Ein passendes DMARC-Beispiel für TrekMail

Das geeignete DMARC-Beispiel hängt vom Versandweg ab. Verwalteter SMTP ist in entsprechenden bezahlten Tarifen verfügbar, benötigt aber passende DNS-Einträge und Nachrichtentests. Bei eigenem SMTP prüfen Sie den tatsächlichen Envelope-SPF-Bereich und ausgerichtetes DKIM des Anbieters.

Mögliche Verwaltungsansätze:

Konfiguration	Verteilte Verwaltung	Gemeinsamer Ablauf
Verwalteter Versand	Postfachhosting und getrennten SMTP-Anbieter verbinden	Verwalteten TrekMail-SMTP mit korrektem DNS konfigurieren und Ausrichtung testen
Eigener SMTP	Anbieterwerte erst nach Fehlern ermitteln	Tatsächliche SPF- und DKIM-Anforderungen vorab prüfen
Mehrere Domains	Domains einzeln ohne einheitliche Dokumentation bearbeiten	DNS-Vorlagen anpassen und Ergebnisse pro Domain beobachten

Die Dokumentation zu Managed TrekMail SMTP beschreibt den Versand entsprechender bezahlter Tarife. Prüfen Sie stets die aktuelle Konfiguration. Bei Bring Your Own SMTP muss der SPF-Eintrag der tatsächlichen Envelope-Domain den ausgehenden Anbieter autorisieren. Wenn SPF nicht ausgerichtet ist, kann erfolgreiches ausgerichtetes DKIM DMARC bestehen lassen.

Postfachhosting und App-Versand sind getrennte Wege. Sendet eine Anwendung über SES, SendGrid oder Mailgun, reicht ein korrektes DMARC-Beispiel nicht aus, wenn kein erfolgreicher ausgerichteter Authentifizierungspfad vorliegt.

Praktisch bedeutet das:

Verwalteten SMTP auf einem geeigneten bezahlten Tarif prüfen, wenn gemeinsame Verwaltung gewünscht ist.
Bei eigenem SMTP SPF, DKIM und DMARC gemeinsam testen; SPF berücksichtigt DNS-auslösende Mechanismen und Modifikatoren einschließlich verschachtelter Auswertung.
Für mehrere Domains betreute Berichtsziele und eine angepasste Einführung dokumentieren.

Als Preisorientierung wird Starter ab $3.50 monatlich genannt. Für bezahlte Tarife wird eine 14-tägige Testphase angeboten; Nano hat eine kostenlose Option ohne Karte. Aktuelle Pauschaltarife, Limits, gemeinsamer Speicher und IMAP-Migration stehen bei TrekMail-Tarife.

DMARC-Beispiele schrittweise für 2026 einführen

Ein DMARC-Beispiel sollte auch 2026 stufenweise eingeführt werden: Versand erfassen, Ergebnisse prüfen und erst dann verschärfen. Sofortiges Reject kann vergessene Produktionssysteme unnötig gefährden.

Mit Beobachtung beginnen.

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Berichte zunächst beispielsweise 7 bis 14 Tage analysieren und mit Rechnungen, CRM, Support und Weiterleitung abgleichen. Seltene kritische Abläufe benötigen zusätzliche Tests, Protokolle oder längere Beobachtung.
Erfolgreiche ausgerichtete Authentifizierung für jeden Sender prüfen. Nicht passende Anbieter konfigurieren oder einen kontrollierten alternativen Versandweg planen.

Nach Prüfung Quarantine erwägen.

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

Nach Klärung verbleibender Fehler und kritischer Tests Reject erwägen; jeweils den vorherigen Eintrag ersetzen.
```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
```

Für Agenturen und Domainportfolios sind dokumentierte Abläufe leichter wiederholbar als spontane Einzelkorrekturen. TrekMail kann je nach Tarif Mehrdomainverwaltung, Pauschalpreise, gemeinsamen Speicher und serverseitigen IMAP-Import verbinden. Der Import kopiert Nachrichten, ersetzt aber keinen geplanten MX- oder Anwendungswechsel.

Das passende DMARC-Beispiel berücksichtigt tatsächliche Sender und die gewünschte Richtlinie. Berichte sind nur ein Teil der Prüfung. Korrigieren Sie die Ausrichtung und erwägen Sie danach Quarantine oder Reject. So lässt sich Domainfälschung begrenzen, ohne Zustellung oder vollständigen Schutz zu versprechen.

TrekMail kann je nach Tarif Postfächer, DNS-Hinweise, verwalteten oder eigenen SMTP und Mehrdomainverwaltung bereitstellen. Informationen auf trekmail.net helfen beim Vergleich; Pauschaltarife haben ebenfalls Ressourcen- und Funktionsgrenzen.