DNS-Einträge

Die Beispiele nehmen kunde.de als Domain und 203.0.113.10 als Adresse der Maschine.

Vor der Installation

Die drei Namen müssen auf die Maschine zeigen – sonst gibt es kein Zertifikat:

postdog.kunde.de.   A      203.0.113.10
mail.kunde.de.      A      203.0.113.10
meet.kunde.de.      A      203.0.113.10

Hat die Maschine eine IPv6-Adresse, dazu je ein AAAA-Eintrag. Ein AAAA, der auf eine andere Maschine zeigt, ist schlimmer als keiner: Let's Encrypt und viele Mailserver fragen zuerst über IPv6.

PTR

Der PTR-Eintrag (Reverse-DNS) gehört zur IP-Adresse, nicht zur Domain. Du setzt ihn deshalb nicht in der Zone, sondern bei dem Anbieter, dem die Adresse gehört – meist im Kundenmenü des Rechenzentrums:

203.0.113.10  →  mail.kunde.de

Er muss auf denselben Namen zeigen, den der Container als Hostnamen trägt (POSTDOG_MAILHOST). Ohne passenden PTR landet Mail bei vielen Empfängern im Spam. Von POSTDOG aus lässt er sich nicht setzen.

Pro Maildomain

Für jede Domain, deren Mail über POSTDOG läuft. Die Werte zeigt dir der DNS-Dialog in der Verwaltung unter Domains, mit einem Urteil pro Eintrag – siehe Domains und DNS.

MX

kunde.de.   MX   10 mail.kunde.de.

SPF

Ein TXT-Eintrag auf der Domain selbst. POSTDOG schlägt vor:

kunde.de.   TXT   "v=spf1 mx -all"

mx heißt: der Rechner, der die Post annimmt, darf auch senden – bei diesem Aufbau derselbe. Einen eigenen Standard für alle Domains legt ein Superadmin unter Einstellungen → SPF fest. Er muss mit einem all-Term oder redirect= enden und darf nie +all sein.

DKIM

pd20261112._domainkey.kunde.de.   TXT   "v=DKIM1; h=sha256; k=rsa; p=…"

Den Schlüssel erzeugt POSTDOG, den Wert zeigt der DNS-Dialog. Der Selektor trägt das Datum. Beim Schlüsselwechsel kommt ein neuer Selektor neben den alten, und POSTDOG stellt erst um, wenn die öffentlichen Resolver den neuen sehen.

DMARC

_dmarc.kunde.de.   TXT   "v=DMARC1; p=none; rua=mailto:postmaster@kunde.de; adkim=r; aspf=r"

p=none ist der Anfang: erst die Berichte lesen, dann verschärfen. Einen Standard für alle Domains – Policy, Ausrichtung, Berichtsadresse und wohin die Berichte weitergeleitet werden – legt ein Superadmin unter Einstellungen → DMARC fest. POSTDOG richtet dann die Weiterleitung für die Berichtsadresse ein und schreibt den Eintrag.

Die Berichtsadresse liegt absichtlich auf der Domain selbst. Eine fremde Berichtsdomain bräuchte beim Empfänger einen eigenen _report._dmarc-Eintrag.

Welche Zone gilt

Entscheidend ist die Zone, an die der Registrar delegiert. POSTDOG vergleicht die öffentlichen Nameserver mit denen der Zone, die es kennt. Zeigt der Dialog „delegiert woanders hin“, wirkt nichts, was in dieser Zone steht – dann trägst du die Werte bei dem Anbieter ein, auf den die Domain tatsächlich zeigt.

Kalender (CalDAV)

Kalender laufen über CalDAV unter /dav/. Damit Mailprogramme den Dienst selbst finden:

_caldavs._tcp.kunde.de.   SRV   0 1 443 mail.kunde.de.
_caldavs._tcp.kunde.de.   TXT   "path=/dav/"

Den Port legst du in POSTDOG unter Einstellungen → Kalender fest (Vorgabe 443); geschrieben wird der Eintrag aus Domains → Mail-Einstellungen → Kalender.

Thunderbird fragt diesen Eintrag nicht ab. Gibt man ihm die Maildomain, sucht es unter https://kunde.de/.well-known/caldav – also auf der Website des Kunden – und meldet „Keine Kalender unter dieser Adresse gefunden“, ohne je nach einem Kennwort zu fragen. Zwei Wege:

• Im Mailprogramm mail.kunde.de als Adresse angeben.

• Auf der Website eine Weiterleitung einrichten – im vhost von kunde.de und von www.kunde.de:

  RedirectMatch 301 ^/\.well-known/(caldav|carddav)$ https://mail.kunde.de/dav/

  location ~ ^/\.well-known/(caldav|carddav)$ { return 301 https://mail.kunde.de/dav/; }

Apple iOS und Home Assistant finden den Dienst weder so noch so. Für sie zeigt der Postfach-Dialog unter Postfächer die vollständigen Adressen.

Besprechungen: TURN

Ton und Bild laufen direkt von Browser zu Browser. Sitzen beide Seiten hinter strikten Firewalls oder NAT, geht das nur über einen TURN-Server. Ohne TURN scheitern genau diese Gespräche – „bei uns geht es, beim Kunden nicht“ hat fast immer diese Ursache.

Der TURN-Server (coturn) ist nicht Teil des Images. Er braucht einen Namen im DNS, ein Zertifikat und offene Ports, üblich sind 3478 und 5349 (UDP und TCP) und ein Bereich für die Weiterleitung. Wie er für deine Installation eingebunden wird, klärst du mit POSTDOG.

Prüfen lässt sich das nur mit zwei verschiedenen Netzen: ein Telefon über Mobilfunk gegen einen Laptop im WLAN. Zwei Tabs auf demselben Rechner beweisen nichts.