Warum DMARC?
SPF und DKIM prüfen jeweils nur ein technisches Detail: Ist die IP erlaubt (SPF)? Ist die Signatur gültig (DKIM)? Beide sagen nichts darüber, ob die Absender-Adresse, die der Empfänger sieht, zur Domain passt, die geprüft wird. Genau hier setzt DMARC an.
Beispiel-Record
; TXT-Record für _dmarc.firma.at "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100; adkim=s; aspf=s"
Die wichtigsten Parameter:
| Tag | Bedeutung |
|---|---|
p= | Policy: none, quarantine oder reject. |
rua= | Adresse für aggregierte Reports (tägliche Statistiken). |
ruf= | Adresse für Forensik-Reports (einzelne fehlgeschlagene Mails). |
pct= | Auf wie viel Prozent der Mails die Policy angewendet wird. |
adkim / aspf | Alignment-Strenge: s=strict, r=relaxed. |
Die drei Policies
| Policy | Wirkung | Einsatz |
|---|---|---|
p=none | Nur beobachten — Reports, keine Aktion. | Start |
p=quarantine | Verdächtige Mails in den Spam-Ordner. | Stufe 2 |
p=reject | Verdächtige Mails werden komplett abgelehnt. | Ziel |
Der Zusammenhang — eine Analogie
Stellen Sie sich einen Botschaftsbesuch vor:
- SPF ist der Zaun um das Gelände — wer überhaupt reindarf.
- DKIM ist das Siegel auf dem Brief — beweist, dass er nicht geöffnet wurde.
- DMARC ist der Protokollchef — prüft, dass Zaun und Siegel tatsächlich zur Person passen, die auf dem Briefumschlag steht. Und sagt der Wache, was bei Unstimmigkeiten zu tun ist.
none direkt auf reject ist gefährlich. Ohne Report-Analyse riskieren Sie, dass legitime Mails (vergessene Newsletter-Tools, alte CRMs) abgelehnt werden. Der DMARC-Policy-Guide zeigt den sicheren Weg.Reports richtig nutzen
Die aggregierten Reports (via rua) kommen täglich von Google, Microsoft, Yahoo & Co. als XML-Dateien. Sie listen, welche IPs unter Ihrem Namen versendet haben — inklusive aller, die SPF oder DKIM nicht bestehen. Das ist Gold wert, um Schatten-IT und Phishing-Versuche zu erkennen.