Was ist DMARC? Funktionsweise, Phasen und der Weg zu p=reject.

Einleitung

Wer im Jahr 2026 unter einer eigenen Domain E-Mails versendet, kommt um DMARC nicht mehr herum. Google und Yahoo machen die Authentifizierung seit 2024 zur Pflicht für Absender mit größerem Volumen, und Microsoft hat nachgezogen.

Die Einführung wird oft unterschätzt. Ein DMARC-Record ist in zehn Minuten veröffentlicht. Die eigentliche Arbeit beginnt danach. Denn DMARC ist nicht nur Konfiguration, sondern auch ein Messinstrument: Es zeigt, wer wirklich in deinem Namen E-Mails versendet. Aber eben nur, wenn man es richtig einsetzt. Und fast immer sind es mehr Systeme, als irgendjemand in der Organisation auf dem Schirm hatte.

Dieser Beitrag erklärt DMARC so, wie wir es im Projekt gegenüber IT-Leitungen tun: technisch korrekt, aber ohne Marketing-Glättung. Inklusive der Stellen, an denen das Thema in der Praxis komplizierter wird als die Dokumentation suggeriert.

Was ist DMARC?

DMARC steht für Domain-based Message Authentication, Reporting & Conformance. Seit Mai 2026 ist der Standard in RFC 9989 spezifiziert, das den ursprünglichen RFC 7489 von 2015 ablöst und DMARC vom rein informativen Dokument zum Protokoll auf dem IETF-Standards-Track erhebt. Am grundsätzlichen Mechanismus ändert das nichts: DMARC leistet weiterhin zwei Dinge:

1. Er legt fest, wie empfangende Mailserver mit E-Mails umgehen sollen, die vorgeben, von deiner Domain zu stammen, aber nicht authentifiziert werden können.
2. Er sorgt dafür, dass du als Domain-Inhaber Reports über den E-Mail-Verkehr unter deiner Domain erhältst – inklusive legitimer und illegitimer Absender.

Technisch ist DMARC ein DNS-TXT-Record, der auf dem Subdomain _dmarc.deine-domain.de veröffentlicht wird. Ein minimaler Record sieht so aus:

v=DMARC1; p=none; rua=mailto:reports@deine-domain.de;

Technisch verlangt der Standard nur zwei Tags. Den dritten solltest du trotzdem immer setzen, weil DMARC ohne ihn blind bleibt:

v=DMARC1 Pflicht

Version. Aktuell nur ein gültiger Wert.

p=none Pflicht

Policy. Bestimmt, was mit nicht-authentifizierter Post passiert: none, quarantine oder reject.

rua=mailto:… dringend empfohlen

Reporting-Adresse. Formal optional, in der Praxis aber der eigentliche Sinn von DMARC: Empfänger senden hierhin täglich aggregierte Reports über alle DMARC-Prüfungen. Ohne den rua-Tag erfährst du nie, wer in deinem Namen sendet.

Wie DMARC funktioniert

DMARC prüft nicht selbst, ob eine E-Mail legitim ist. Stattdessen baut es auf zwei älteren Standards auf – SPF und DKIM – und ergänzt sie um eine entscheidende zusätzliche Prüfung: die Alignment-Kontrolle.

Der Ablauf in fünf Schritten

1. Ein Mailserver empfängt eine E-Mail, die vorgibt, von deine-domain.de zu stammen.
2. Der Server ruft den SPF-Record von deine-domain.de ab und prüft, ob der sendende IP-Adressbereich dort gelistet ist.
3. Der Server prüft die DKIM-Signatur der E-Mail gegen den öffentlichen Schlüssel im DNS.
4. Mindestens einer der beiden Checks muss bestanden sein und die authentifizierte Domain muss mit der sichtbaren Absenderdomain (dem From-Header) übereinstimmen. Das ist das Alignment.
5. Scheitert die Prüfung, wird die DMARC-Policy angewendet: durchlassen, in Spam verschieben oder abweisen. Parallel entsteht ein Eintrag im Report.

Der Alignment-Schritt ist der eigentliche Mehrwert von DMARC. Ohne ihn könnte ein Angreifer mit einer fremden, aber gültig signierten Domain eine E-Mail verschicken, die vorgibt, von deine-bank.de zu stammen – und SPF und DKIM wären zufrieden. Erst DMARC stellt sicher, dass die sichtbare Domain authentifiziert ist.

SPF, DKIM und DMARC – das Zusammenspiel

In der Praxis werden die drei Standards oft in einen Topf geworfen. Sie beantworten aber unterschiedliche Fragen:

Erst die Kombination der drei ergibt einen funktionierenden Spoofing-Schutz. SPF und DKIM sind die Vorab-Checks, DMARC ist die Regel, die darauf aufbaut und dem empfangenden Mailserver sagt, wie er mit dem Ergebnis umgehen soll: durchlassen, in Spam verschieben oder abweisen.

Der Weg zu p=reject

Das eigentliche Ziel jeder DMARC-Einführung ist p=reject. Erst dort bietet DMARC echten Schutz vor Domain-Spoofing – vorher ist es Beobachtung. Der Weg dorthin führt praktisch immer über drei Phasen, die nicht übersprungen werden sollten.

Warum nicht direkt auf reject? Weil niemand am ersten Tag weiß, wer tatsächlich alles unter der eigenen Domain sendet. Eine zu frühe Durchsetzung trifft die Drittsysteme als erstes – und sie sind in der Regel geschäftskritisch.

Was in dieser Phase passiert

Der DMARC-Record wird mit Policy p=none veröffentlicht. E-Mails werden normal zugestellt. Im Hintergrund beginnen Empfänger wie Google, Microsoft und Yahoo, täglich aggregierte XML-Reports an die in rua angegebene Adresse zu senden.

Ziel ist eine vollständige Bestandsaufnahme: Welche IPs versenden unter deiner Domain? Welche davon sind legitim?

Ziel am Ende der Phase

• Jeder legitime Absender ist identifiziert und in der SPF- und DKIM-Konfiguration berücksichtigt.
• Der Anteil an E-Mails, die DMARC bestehen, liegt stabil über 98 %.
• Die verbleibenden Fehlschläge sind erklärt.

Was in dieser Phase passiert

Die Policy wird auf p=quarantine angehoben. Empfänger behandeln nicht-authentifizierte E-Mails unter deiner Domain ab jetzt wie Spam, meist landen sie im Junk-Ordner.

Ziel am Ende der Phase

• Keine geschäftskritischen E-Mails landen mehr aufgrund fehlender Authentifizierung im Spam.
• Die SPF- und DKIM-Abdeckung ist über 99 % und stabil.

Was in dieser Phase passiert

Die Policy steht auf p=reject. Empfangende Server weisen jede E-Mail, die sich nicht als von deiner Domain authentifizieren lässt, endgültig ab. Gespoofte Nachrichten erreichen den Empfänger nicht. Das ist das Ziel.

Wann ist eine Domain wirklich bereit für reject?

• Die DMARC-Pass-Rate ist dauerhaft stabil auf einem Niveau, das keine geschäftskritischen Fehler mehr erwarten lässt.
• Jede verbleibende Fehlermeldung ist konkret einem System zugeordnet – kein „unbekannter Absender" mehr in den Reports.
• Es gibt keine neuen Drittanbieter-Onboardings in der Pipeline, die noch nicht authentifiziert sind.

DMARC-Reports: Was sie zeigen

Reports sind das Herzstück von DMARC. Ohne sie ist die Policy blind. Empfänger wie Google senden täglich ein oder mehrere XML-Dokumente an die rua-Adresse.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
  </report_metadata>
  <record>
    <row>
      <source_ip>52.28.144.77</source_ip>
      <count>1842</count>
      <policy_evaluated>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

Jeder Report enthält pro sendender IP-Adresse die Anzahl der Mails, das Ergebnis für SPF und DKIM und die angewendete Policy.

Warum es jetzt wichtig ist

DMARC ist seit 2012 spezifiziert, seit Mai 2026 ist es mit RFC 9989 ein offizieller Standard auf dem IETF-Standards-Track und bei den großen Mailprovidern faktisch verpflichtend. Der Druck zur Durchsetzung ist in den vergangenen Jahren messbar gestiegen. Mehrere Faktoren wirken dabei zusammen:

Was früher eine Best Practice war, ist damit eine Voraussetzung für regulären Mailbetrieb mit größeren Empfängern geworden.

Wo es in der Praxis komplex wird

Die Dokumentation macht DMARC zu einem linearen Prozess. In echten Setups gibt es einige Stellen, an denen es regelmäßig hakt.

SPF-Flattening und das 10-Lookup-Limit

SPF erlaubt maximal zehn DNS-Lookups pro Record. Wer vier oder fünf Drittanbieter eingebunden hat, läuft schnell gegen diese Grenze. Das Ergebnis ist ein permerror – SPF ist faktisch kaputt.

Drittanbieter-DKIM bei Marketing- und Transaktionsmail

Dienste wie Mailchimp, Sendgrid oder Salesforce Marketing Cloud können grundsätzlich DKIM-Signierung übernehmen – aber nur, wenn der Kunde seitens der Domain passende CNAMEs setzt und die Schlüssel rotiert werden.

E-Mail-Weiterleitungen

Wenn ein Empfänger die Mail weiterleitet, bricht SPF praktisch immer – die Sender-IP ist dann nicht mehr die ursprünglich autorisierte. DKIM bleibt in der Regel intakt.

Edge Cases: Mailinglisten, Shared Services, Legacy-Dienste

Es gibt Konstellationen, die sich nicht sauber lösen lassen. Mailinglisten ändern den From-Header oft nicht und brechen dadurch DMARC. Alte Faxgateways, Ticketsysteme oder intern betriebene Mailer haben keine Möglichkeit zur DKIM-Signierung.