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>
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=none → p=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 mehrp=none) — der Kernpunkt. Von sorb bereits eigenständig umgestellt.- Subdomain-Vererbung: Ohne
sp=-Tag gilt laut RFC 7489 diep=-Policy auch für Subdomains — mitp=rejecterben sie alsoreject. Das vom Issue gewünschtesp=rejectist 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 abers1-ionos._domainkey/s2-ionos._domainkey/s42582890._domainkey. Alle drei CNAMEs existieren am Apex, die Schlüssel hinters1-ionos/s2-ionoslö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.