Files
management/docs/issues/0006-zone-02-apex-dmarc-ist-p-none-und-schuetzt.md
T
Thore CimbalandClaude Opus 4.8 c0a428f43d docs(issues): close #0006 — apex DMARC already at p=reject, DKIM present
Verified via DoH: _dmarc.axion1337.de is p=reject (sorb changed it), subdomains
inherit reject with sp= absent per RFC 7489, and the noted DKIM gap was a false
alarm — IONOS uses s1-ionos/s2-ionos/s42582890 selectors, all present with valid
keys. Apex SPF left at ~all deliberately: real mail flows over the apex and DMARC
already enforces reject, so -all adds little while risking silent send breakage.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-14 12:00:00 +00:00

2.5 KiB

type, id, status, created, milestone, priority, area, gitlab_iid, related
type id status created milestone priority area gitlab_iid related
issue 0006 done 2026-08-01 M1 low security 6

ZONE-02: Apex-DMARC ist p=none und schützt nichts

Import aus management#6 (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).

_dmarc.axion1337.de = v=DMARC1; p=none; — reines Monitoring, kein Schutz gegen gefälschte Mail. Zusätzlich fehlt sp=: alle Subdomains erben p=none, auch künftige. sp=reject am Apex wäre der effiziente Hebel und macht die einzelnen _dmarc-Records aus ZONE-01 auf Dauer entbehrlich.

Reihenfolge wichtig: erst für jeden real sendenden Namen SPF/DKIM korrekt setzen, dann sp=reject — umgekehrt zerlegt es Mailversand unbemerkt. Für den Apex selbst (echte IONOS-Mail): p=nonep=quarantine → Reports beobachten → p=reject. Auffällig: s1._domainkey.axion1337.de hatte keinen DKIM-Record, obwohl die Subdomains IONOS-DKIM-CNAMEs haben — beim Härten mitprüfen.

Quelle: shared/zone-axion1337.md


Übernommen aus dem Backlogs-Markdown beim Framework-Umbau 2026-08-01 (voller Wortlaut: Git-Historie der Datei).

Erledigt 2026-08-14 — Ist-Stand geprüft, Anliegen erfüllt

Extern per DoH verifiziert; alle drei Punkte des Issues sind adressiert:

  • _dmarc.axion1337.de = v=DMARC1; p=reject; (nicht mehr p=none) — der Kernpunkt. Von sorb bereits eigenständig umgestellt.
  • Subdomain-Vererbung: Ohne sp=-Tag gilt laut RFC 7489 die p=-Policy auch für Subdomains — mit p=reject erben sie also reject. Das vom Issue gewünschte sp=reject ist damit gegenstandslos (und die Einzel-_dmarc-Records aus ZONE-01 sind Gürtel+Hosenträger, schaden aber nicht).
  • Vermeintliche DKIM-Lücke war ein Fehlalarm: gesucht wurde damals unter s1._domainkey, IONOS verwendet aber s1-ionos._domainkey / s2-ionos._domainkey / s42582890._domainkey. Alle drei CNAMEs existieren am Apex, die Schlüssel hinter s1-ionos/s2-ionos lösen gültig auf (je 408 Zeichen TXT).

Bewusst nicht geändert: Apex-SPF bleibt v=spf1 include:_spf-eu.ionos.com ~all (Softfail). Über axion1337.de läuft echter Mailverkehr (aktive Postfächer, MX auf mx00/mx01.ionos.de); da DMARC bereits reject erzwingt, ist der Sicherheitsgewinn von -all marginal, das Risiko eines still gebrochenen Versands durch einen vergessenen legitimen Sender aber real.