E-Mail: Domains, DNS & Versand

Bevor WeZend E-Mails in Ihrem Namen versendet, weisen Sie nach, dass Ihnen die Domain gehört. Genau das hält Ihre Mail aus dem Spam-Ordner heraus — Posteingangsanbieter vertrauen Mail, die kryptografisch an eine verifizierte Domain gebunden ist.

1. Domain hinzufügen

Öffnen Sie im Dashboard Einstellungen → E-Mail-Domains und fügen Sie die Domain hinzu, von der Sie senden (zum Beispiel mail.ihrefirma.de). Das API-Äquivalent:

curl -X POST https://api.wezend.com/v1/account/email-domains \
  -H "X-API-Key: $WEZEND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "domain": "mail.ihrefirma.de" }'

Die Antwort listet die exakten DNS-Records auf, die Sie erstellen müssen: einen SPF-Record (welche Server für Sie senden dürfen), einen DKIM-Schlüssel (eine Signatur, die Empfänger prüfen) und eine DMARC-Richtlinie (was Empfänger tun sollen, wenn eine Nachricht an den ersten beiden scheitert).

2. DNS-Records erstellen

Kopieren Sie jeden Record exakt wie angezeigt zu Ihrem DNS-Anbieter. DNS-Änderungen können von Minuten bis zu einigen Stunden dauern, bis sie sich verbreiten.

3. Verifizieren

Klicken Sie im Dashboard auf Verifizieren oder rufen Sie POST /v1/account/email-domains/:id/verify auf — die Plattform führt Live-DNS-Abfragen für alle drei Records durch, speichert das Ergebnis und gibt es zurück:

Das ist eine DNS-Prüfung, und DNS ist nur die halbe Frage. Sie kann nicht sehen, ob ausgehende Mail tatsächlich signiert wird — lesen Sie sie also als "die Records sind veröffentlicht", nicht als "DKIM funktioniert". POST /v1/account/email-domains/:id/check-signing ist die ehrliche Bestätigung: sie sieht sich eine echte Signatur an. Führen Sie sie aus, bevor Sie DMARC verschärfen — beides als ein einziges grünes Häkchen dargestellt ist genau der Weg, auf dem eine Domain "verifiziert" anzeigt, während die zugestellte Mail überhaupt kein DKIM trägt.

DMARC selbst hat über den DNS-Record hinaus zwei Endpoints. POST /v1/account/email-domains/:id/dmarc nimmt einen Aggregat-Report (rua) als { xml } und wertet ihn zu einer Pass/Fail-Alignment-Übersicht aus, sodass Sie sehen, wer als Ihre Domain sendet und was scheitert; GET auf demselben Pfad liefert die letzten Reports und einen Rollup. GET /v1/account/email-domains/:id/dmarc/readiness beantwortet die Frage, die vor dem Wechsel auf p=quarantine zählt, anhand derselben vier Kriterien, die die Plattform an ihre eigene Domain anlegt: mindestens 14 Tage Reports, mindestens 3 berichtende Organisationen, Alignment von 99% oder besser und keine nicht ausgerichtete Quelle über 5 Nachrichten im Fenster. Sie gibt die fehlenden Gründe zurück, nicht nur ein Urteil. Und PUT /v1/account/email-domains/:id/bimi mit { logo_url } setzt oder entfernt das BIMI-Logo, sobald DMARC durchsetzt. Eine ganz neue Domain hat keine Reputation, deshalb setzt POST /v1/account/email-domains/:id/warmup mit { "action": "start" } sie auf eine 21-tägige Rampe: solange die läuft, wird Marketing-E-Mail über das Tageslimit hinaus zurückgehalten statt gesendet, und pause, resume sowie stop tun, was sie sagen. Transaktionale Mail ist nicht Teil der Rampe.

{
  "spf_verified": true,
  "dkim_verified": false,
  "dmarc_verified": true,
  "status": "pending",
  "checks": {
    "spf":   { "ok": true,  "reason": "ok" },
    "dkim":  { "ok": false, "reason": "wrong_selector", "detail": "smtp", "selector": "zc1", "hint": "You published a valid DKIM key under the \"smtp\" selector — that's another provider's key (e.g. your mailbox host), not WeZend's. WeZend signs with the \"zc1\" selector, so add the \"zc1._domainkey\" CNAME shown above; the \"smtp\" one can stay, it's harmless." },
    "dmarc": { "ok": true,  "reason": "ok", "policy": "quarantine" }
  }
}

SPF und DKIM müssen beide bestehen, bevor status auf verified wechselt; DMARC ist empfohlen, blockiert aber nicht.

checks enthält einen Eintrag pro Record, sodass eine gescheiterte Prüfung Ihnen sagt, was zu korrigieren ist, statt ein nacktes rotes Kreuz zu zeigen:

• ok — der Boolean dieses Records.
• reason — ein stabiler Maschinencode. Verzweigen Sie in Ihrem eigenen Tooling darauf; der Wortlaut von hint ist nicht Teil des Vertrags.
• hint — eine Zeile menschlicher Formulierung für die Person, die das DNS verwaltet. null bei einer bestandenen Prüfung, mit einer Ausnahme (siehe DMARC unten).
• detail — der Wert, an dem die Prüfung hing: der tatsächlich gefundene Selektor, das fehlende SPF-Include, der Host ohne Record. null, wenn nicht zutreffend.
• selector — nur DKIM: der Selektor, mit dem WeZend signiert, damit Sie ihn in Ihrer eigenen Oberfläche benennen können. policy — nur DMARC: der ausgelesene p=-Wert, einer von none, quarantine oder reject.

Verifizieren erneut auszuführen ist immer sicher. Haben Sie ein rotes DKIM-Kreuz auf einem Record gesehen, von dem Sie wissen, dass er korrekt publiziert ist, führen Sie es erneut aus — die Verifizierung lieferte früher für jede Domain ein falsch-negatives DKIM, weil WeZends verwalteter Schlüssel-Host als TXT-Record publiziert wird, die Health-Prüfung aber nur A und CNAME abfragte.

Reason-Codes

• ok — der Record ist vorhanden und korrekt.
• esp_target_unresolved — das liegt bei WeZend, nicht bei Ihnen. Unser eigenes SPF-Include oder der verwaltete DKIM-Schlüssel-Host löst nicht auf, sodass noch kein Record, den Sie publizieren, bestehen kann. detail benennt den Host. Schicken Sie den Domain-Inhaber deswegen nicht ins DNS — wenden Sie sich an den Support und nennen Sie den Host.
• no_spf_record — die Domain hat überhaupt keinen v=spf1-TXT-Record.
• missing_include — ein SPF-Record existiert, enthält aber nicht WeZends Include (detail). Ergänzen Sie es im bestehenden Record; publizieren Sie keinen zweiten SPF-Record.
• not_published — DKIM: nichts unter <selector>._domainkey.<domain>. detail ist der abgefragte Host.
• wrong_cname_target — DKIM: unter dem richtigen Host existiert ein CNAME, der aber woanders hinzeigt. detail ist der Host, auf den er zeigen muss.
• wrong_selector — DKIM: die Domain publiziert durchaus einen gültigen DKIM-Schlüssel, aber unter einem anderen Selektor. detail ist der gefundene Selektor.
• no_record — DMARC: kein v=DMARC1-TXT-Record unter _dmarc.<domain>.

Der Fall des falschen Selektors

Das ist der Fehler, in den echte Kunden laufen. Das DNS sieht richtig aus, SPF und DMARC bestehen, DKIM ist rot — und die Ursache ist, dass der publizierte Schlüssel jemand anderem gehört. Ein Mailbox-Anbieter hatte DKIM bereits unter seinem eigenen Selektor eingerichtet, typischerweise smtp._domainkey oder default._domainkey, und dieser Record wurde für den gehalten, den WeZend verlangt hat.

WeZend signiert mit seinem eigenen Selektor (standardmäßig zc1) und besitzt den privaten Schlüssel keines anderen Anbieters, ein fremder Selektor kann also nie als bestanden gelten. Publizieren Sie zusätzlich den <selector>._domainkey-CNAME aus Schritt 2. Der Record des anderen Anbieters kann bleiben — beide koexistieren, und ihn zu entfernen würde die Mail zerstören, die Sie über diesen Anbieter versenden.

DMARC-Durchsetzung, während DKIM scheitert

Eine DMARC-Prüfung, die besteht, liefert dennoch einen hint, wenn die Richtlinie p=quarantine oder p=reject lautet und DKIM scheitert. Genau diese Kombination befördert Ihre Mail tatsächlich in den Spam-Ordner: Sie haben den Empfängern gesagt, alles, was die Authentifizierung nicht besteht, in Quarantäne zu stellen oder abzulehnen — und DKIM besteht sie nicht. Halten Sie DMARC auf p=none, bis DKIM verifiziert ist, und ziehen Sie es dann an.

4. Senden

Nach der Verifizierung ist E-Mail nur ein weiterer Kanal auf demselben Endpoint, den Sie bereits nutzen:

curl -X POST https://api.wezend.com/v1/messages/send \
  -H "X-API-Key: $WEZEND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "kunde@example.com",
    "channel": "email",
    "sender": "hallo@mail.ihrefirma.de",
    "subject": "Willkommen!",
    "html": "<h1>Hallo</h1><p>Danke für Ihre Anmeldung.</p>"
  }'

Öffnungen und Klicks werden automatisch erfasst (ein Tracking-Pixel und umgeschriebene Links), Bounces und Beschwerden speisen die Sperrliste, und Ihre Absenderreputation wird kontinuierlich überwacht — siehe Deliverability.