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, Microsoft hat nachgezogen, und im Rahmen von PCI DSS 4.0 ist sie ebenfalls ausdrücklich gefordert.

Die Einführung wird oft unterschätzt. Ein DMARC-Record ist in zehn Minuten veröffentlicht – das eigentliche Problem beginnt danach. Denn DMARC ist keine Konfiguration, sondern ein Messinstrument: Es zeigt, wer wirklich in Ihrem Namen E-Mails versendet. 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. Es ist ein in RFC 7489 spezifizierter Standard, der zwei Dinge leistet:

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

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

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

Die drei Pflicht-Tags sind schnell erklärt:

v=DMARC1

Version. Aktuell nur ein gültiger Wert.

p=none

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

rua=mailto:…

Reporting-Adresse. Empfänger senden an diese Adresse täglich aggregierte Reports.

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 ihre-domain.de zu stammen.
2. Der Server ruft den SPF-Record von ihre-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 ihre-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 den Inhalt der Reports erzeugt.

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 Ihrer 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 Ihrer 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.
• pct=100 läuft seit mindestens zwei Wochen störungsfrei.

Was in dieser Phase passiert

Die Policy steht auf p=reject. Empfangende Server weisen jede E-Mail, die sich nicht als von Ihrer 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, aber erst in den vergangenen zwei Jahren ist der Druck zur Durchsetzung messbar gestiegen. Drei Entwicklungen wirken parallel:

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.