{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreia7wd3ynoa7v5kzjbgkcdwum2b5utvgddnihvwa4a2wy6rfo5yhbi",
    "uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmofeih5g2v2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreidweh3si6szfpceggdupnps5w6wl7yeybi6pd46xymkxg7foh6jau"
    },
    "mimeType": "image/png",
    "size": 675338
  },
  "description": "DMARC baut auf SPF und DKIM auf und schliesst die zwei Luecken die beide einzeln offen lassen: Der Absender bestimmt was mit unzustellbaren Mails passieren soll, Reports landen taeglich im Postfach. Policy-Stufen none/quarantine/reject erklaert, plus typischer rua-Reporting-Setup.",
  "path": "/2013/11/30/dmarc-domain-based-message-authentication-reporting-conformance/",
  "publishedAt": "2026-05-25T11:39:20.000Z",
  "site": "https://www.kernel-error.de",
  "tags": [
    "DKIM",
    "DMARC",
    "Email",
    "Hardening",
    "InfoSec",
    "MailServer",
    "SelfHosted",
    "SPF",
    "RFC 7489",
    "dmarcian.com",
    "rspamd",
    "Einfach melden."
  ],
  "textContent": "DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) baut auf SPF und DKIM auf. Es löst zwei Probleme, die SPF und DKIM allein offen lassen: Erstens kann der Absender festlegen, was mit Mails passieren soll, die weder SPF noch DKIM bestehen. Zweitens bekommt der Absender Berichte darüber, wie seine Mails bei den Empfängern ankommen.\n\n### DMARC-Record aufbauen\n\nDMARC wird als TXT-Record unter `_dmarc.domain.de` im DNS veröffentlicht. Ein Beispiel:\n\n\n    _dmarc.kernel-error.de.  IN TXT  \"v=DMARC1; p=quarantine; adkim=s; aspf=s; pct=100; rua=mailto:postmaster@kernel-error.de; ruf=mailto:postmaster@kernel-error.de\"\n\nDie einzelnen Parameter:\n\n**`v=DMARC1`**|  Protokollversion (immer DMARC1)\n---|---\n**`p=quarantine`**|  Policy für die Hauptdomain (siehe unten)\n**`sp=quarantine`**|  Policy für Subdomains (optional, erbt sonst von `p`)\n**`adkim=s`**|  DKIM-Alignment: `s` = strict, `r` = relaxed\n**`aspf=s`**|  SPF-Alignment: `s` = strict, `r` = relaxed\n**`pct=100`**|  Prozent der Mails, auf die die Policy angewendet wird\n**`rua=mailto:...`**|  Adresse für aggregierte Berichte (täglich, XML)\n**`ruf=mailto:...`**|  Adresse für forensische Berichte (pro Vorfall)\n\n### Alignment: Wofür DMARC wirklich da ist\n\nSPF prüft den Envelope-From, DKIM prüft die signierende Domain. Beides sagt nichts über den `From:`-Header aus, den der Empfänger tatsächlich sieht. DMARC schließt diese Lücke mit dem sogenannten Alignment: Es verlangt, dass mindestens eine der beiden Prüfungen (SPF oder DKIM) zur Domain im `From:`-Header passt.\n\n**Strict** (`s`) bedeutet: Die Domains müssen exakt übereinstimmen. **Relaxed** (`r`) erlaubt auch Subdomains (z.B. `mail.kernel-error.de` passt zu `kernel-error.de`). Für die meisten Setups ist `strict` die richtige Wahl, solange alle ausgehenden Mails über die Hauptdomain signiert werden.\n\n### Policy-Stufen\n\nDer `p`-Parameter legt fest, was der Empfänger mit Mails machen soll, die weder SPF noch DKIM bestehen:\n\n**`p=none`**|  Nur beobachten, nichts tun. Gut zum Einstieg, um über die Reports erstmal zu sehen was passiert.\n---|---\n**`p=quarantine`**|  Als Spam markieren. Die Mail wird zugestellt, landet aber im Spam-Ordner.\n**`p=reject`**|  Ablehnen. Die Mail wird gar nicht erst angenommen.\n\nDer empfohlene Weg: Mit `p=none` anfangen und die Reports auswerten. Wenn alles sauber aussieht, auf `quarantine` hochdrehen. Wenn auch das stabil läuft, auf `reject` gehen. Mit `pct` kann man die Policy schrittweise ausrollen, z.B. erst auf 10% der Mails anwenden und dann langsam erhöhen.\n\n### Reporting\n\nDie aggregierten Reports (`rua`) kommen einmal am Tag als komprimierte XML-Dateien per Mail. Darin steht, welche IPs Mails mit deiner Domain versendet haben und ob SPF/DKIM bestanden oder durchgefallen sind. Das ist Gold wert: Man sieht sofort, ob jemand die Domain missbraucht oder ob ein legitimer Dienst falsch konfiguriert ist.\n\nDie XML-Dateien sind nicht besonders lesefreundlich. Zum Auswerten eignet sich dmarcian.com (XML hochladen, menschenlesbare Übersicht bekommen) oder man baut sich eine eigene Auswertung. Für größere Setups gibt es Open-Source-Tools wie parsedmarc, die Reports automatisch verarbeiten und in Elasticsearch oder eine Datenbank schieben.\n\nDie forensischen Reports (`ruf`) liefern Details zu einzelnen fehlgeschlagenen Mails. In der Praxis schicken die meisten großen Provider (Google, Microsoft) allerdings keine forensischen Reports mehr, aus Datenschutzgründen. Die aggregierten Reports reichen für die meisten Fälle aus.\n\n### Cross-Domain-Reporting\n\nWer mehrere Domains betreibt und die Reports zentral an eine Adresse schicken will, muss aufpassen. Soll der Report für `kernel-error.com` an `postmaster@kernel-error.de` gehen, muss die Empfänger-Domain das erlauben. Dafür braucht es einen zusätzlichen TXT-Record in der Zone von `kernel-error.de`:\n\n\n    kernel-error.com._report._dmarc.kernel-error.de.  IN TXT  \"v=DMARC1\"\n\nDieser Record sagt: „kernel-error.de akzeptiert DMARC-Reports für kernel-error.com.“ Ohne diesen Eintrag ignorieren Empfänger die Report-Adresse, weil sie in einer fremden Domain liegt.\n\n### DMARC testen\n\n\n    # DMARC-Record abfragen\n    dig TXT _dmarc.kernel-error.de +short\n\nEinen vollständigen Check inklusive SPF und DKIM bekommt man über `mxtoolbox.com` oder ähnliche Online-Tools. Einfach eine Testmail an die Prüfadresse schicken und den Report abwarten.\n\n### Das Zusammenspiel\n\nDMARC funktioniert nur zusammen mit SPF und DKIM. Alle drei zusammen ergeben eine vollständige E-Mail-Authentifizierung: SPF legt fest welche Server senden dürfen, DKIM signiert die Mail kryptografisch und DMARC verknüpft beides mit einer Policy und liefert Feedback. Wer das Ganze mit rspamd betreibt, hat Auswertung und Enforcement gleich mit dabei. Fragen? Einfach melden.",
  "title": "DMARC einrichten: Policy, Alignment und Reporting für deine Domain"
}