zone: erklaert, was die Mail-Records tun - plus gemessener Ist-Stand

Die Rezepte in ZONE-01 nannten Werte (Null-MX, v=spf1 -all, p=reject), ohne zu
sagen, wogegen sie schuetzen. Wer sie umsetzt, ohne das zu wissen, kann nicht
erkennen, wann ein Halbfertig-Zustand schlechter ist als der Ausgangszustand -
und genau das ist eingetreten.

Ergaenzt: die vier Mechanismen einzeln (SPF, DKIM, DMARC, Null-MX), was jeder
beantwortet und warum keiner allein reicht. Zwei Punkte, die man kennen muss:

- SPF darf nur EINMAL je Name existieren; ein zweiter Record erzeugt PermError,
  und dann pruefen viele Empfaenger gar nicht mehr. Die Haertung schlaegt ins
  Gegenteil um.
- DMARC wird vererbt. Fehlt _dmarc.<name>, gilt die Policy des Apex - und die
  steht auf p=none. Damit erben ALLE Subdomains 'kein Schutz', egal wie sauber
  ihr SPF ist. Der Apex ist damit der groesste Hebel der Zone (ZONE-02), nicht
  die Einzelnamen (ZONE-01).

Dazu der gemessene Ist-Stand (DoH, um den Lab-Resolver zu umgehen): Bei rohana
sind MX und SPF geloescht, die Ersatz-Records fehlen. Vorher gab es wenigstens
ein Softfail-SPF, jetzt gar keine Aussage - keine Aussage ist schwaecher als eine
schlechte. Bei selendis ist nur das www weg, der Mail-Satz steht unveraendert.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj

shared/zone-axion1337.md

@@ -8,7 +8,20 @@ Host trennen lässt.
 | **Registrar / DNS** | IONOS (`ns1098.ui-dns.biz`, `ns1022.ui-dns.com`, `ns1070.ui-dns.org`, `ns1059.ui-dns.de`) |
 | **Apex** | `217.160.0.140` / `2001:8d8:100f:f000::2e9` — IONOS-Hosting, nicht eigene Infrastruktur |
 | **Mail** | IONOS (`mx00.ionos.de`, `mx01.ionos.de`) |
-| **Stand** | 2026-07-30 |
+| **Stand** | 2026-08-06 (Mail-Records gemessen) |
+
+**Ist-Stand der Mail-Härtung** (gemessen 2026-08-06 über DoH, um den Lab-Resolver
+zu umgehen):
+
+| Name | `www` | MX | SPF | `_dmarc` | Bewertung |
+|---|---|---|---|---|---|
+| `rohana` | löst auf ❌ | gelöscht | **gelöscht** ⚠️ | fehlt | ⚠️ schwächer als vorher |
+| `selendis` | weg ✅ | IONOS ❌ | `~all` ❌ | fehlt | unangetastet |
+| `matrix` | löst auf ❌ | IONOS ❌ | `~all` ❌ | fehlt | offen |
+| `game` | löst auf ❌ | — | — | fehlt | teilweise |
+| **Apex** | legitim ✅ | IONOS (genutzt) | `~all` | **`p=none`** ⚠️ | siehe ZONE-02 |
+
+Kein einziger Name trägt bisher `_dmarc`, alle erben damit `p=none` vom Apex.
 
 > **Die Aufstellung ist nicht garantiert vollständig.** Zonentransfer ist verweigert,
 > DNS erlaubt kein Enumerieren. Die Records unten stammen aus gezielten Abfragen und
@@ -32,6 +45,92 @@ Host trennen lässt.
 Mail-Records existieren auf `selendis` und `matrix` (MX ×2, SPF, DKIM-CNAMEs,
 `autodiscover`), auf `rohana` und `game` nicht.
 
+## Was die Mail-Records eigentlich tun
+
+Damit die Rezepte in [ZONE-01](https://git.lab/axion1337.chat/management/-/issues/5)
+nicht als Zahlensalat dastehen: Vier Mechanismen, die zusammenspielen. **Keiner
+schützt allein.**
+
+### Das Grundproblem
+
+Der Absender einer Mail (`From:`) ist frei wählbar — SMTP prüft ihn nicht. Jeder
+kann `rechnung@rohana.axion1337.de` in den Umschlag schreiben. Die folgenden
+Records sind die Möglichkeit, dem widersprechen, **bevor** jemand darauf hereinfällt.
+
+### SPF — „diese Server dürfen für mich senden"
+
+TXT-Record am Namen selbst. Listet die berechtigten Absender-IPs.
+
+Entscheidend ist das **Ende** des Eintrags:
+
+| Endung | Bedeutung | Wirkung beim Empfänger |
+|---|---|---|
+| `~all` | Softfail | „war nicht auf der Liste" → wird meist **trotzdem zugestellt**, evtl. markiert |
+| `-all` | Hardfail | „war nicht auf der Liste" → **ablehnen** |
+
+`v=spf1 -all` ohne jeden Server davor heißt: *Für diesen Namen sendet niemand.*
+Genau die richtige Aussage für `rohana`, `selendis`, `matrix` — die verschicken keine
+Mail (für `matrix` verifiziert in MATRIX-01: weder Synapse noch MAS senden).
+
+⚠️ **Es darf nur EIN SPF-Record je Name existieren.** Ein zweiter erzeugt
+`PermError`, und dann prüfen viele Empfänger **gar nicht mehr** — die Härtung
+schlägt ins Gegenteil um. Deshalb: bestehenden TXT **editieren**, nie einen zweiten
+anlegen.
+
+### DKIM — „diese Mail wurde unterwegs nicht verändert"
+
+Signatur mit einem privaten Schlüssel, öffentlicher Teil als CNAME/TXT im DNS
+(`s1-ionos._domainkey…`). Beweist Unversehrtheit und Herkunft.
+
+Für Namen, die nicht senden, sind die DKIM-Einträge schlicht **Ballast** — sie
+signieren nichts. Sie können weg.
+
+### DMARC — „und das tust du, wenn SPF oder DKIM nicht passen"
+
+TXT unter `_dmarc.<name>`. SPF und DKIM stellen nur **fest**; DMARC sagt, welche
+**Konsequenz** das hat:
+
+| Policy | Wirkung |
+|---|---|
+| `p=none` | nur beobachten — **kein Schutz**, Mail wird zugestellt |
+| `p=quarantine` | in den Spam-Ordner |
+| `p=reject` | ablehnen |
+
+⚠️ **DMARC wird vererbt.** Fehlt `_dmarc.rohana`, gilt die Policy des
+organisatorischen Namens `axion1337.de`. Die steht heute auf **`p=none`**
+([ZONE-02](https://git.lab/axion1337.chat/management/-/issues/6)) — **damit erben
+alle Subdomains „kein Schutz"**, egal wie sauber ihr SPF ist.
+
+Das ist der wichtigste Hebel der ganzen Zone: **Der Apex wirkt auf alle Namen
+gleichzeitig.** Mit `sp=` lässt sich für Subdomains sogar eine strengere Policy
+setzen als für den Apex selbst.
+
+### Null-MX — „hier nimmt niemand Mail an" (RFC 7505)
+
+Ein MX-Record mit dem Ziel `.` (Punkt) und Priorität 0.
+
+Der Grund, warum **Löschen nicht reicht**: Findet ein Absender **keinen** MX,
+weicht er per RFC 5321 auf den **A/AAAA-Record** aus und versucht, direkt an den
+Webserver zuzustellen. Der Name sieht dann nach „nimmt vielleicht Mail an" aus.
+Null-MX sagt stattdessen ausdrücklich *nein* — Absender brechen sofort ab.
+
+### Warum die Kombination
+
+| Record | Beantwortet die Frage |
+|---|---|
+| **Null-MX** | Nimmt dieser Name Mail **an**? → nein |
+| **SPF `-all`** | Darf jemand für diesen Namen **senden**? → niemand |
+| **DMARC `p=reject`** | Was tun, wenn doch jemand behauptet, es zu dürfen? → ablehnen |
+
+Erst zusammen ergeben sie eine Aussage, auf die sich ein Empfänger verlassen kann.
+Einzeln bleibt jeweils eine Lücke — und **ersatzloses Löschen** hinterlässt die
+größte: keine Aussage ist schwächer als eine schlechte Aussage.
+
+**Real eingetreten:** Bei `rohana` sind MX und SPF gelöscht, die Ersatz-Records
+fehlen (gemessen 2026-08-06). Vorher gab es wenigstens ein Softfail-SPF, jetzt gar
+keine Aussage mehr — dazu die geerbte `p=none` vom Apex. Der Halbfertig-Zustand ist
+schwächer als der Ausgangszustand.
+
 ## Offene Punkte → git.lab-Issues
 
 Seit dem Framework-Umbau (2026-08-01) leben offene Punkte als Issues im