SendGrid: die authentifizierte Domain einrichten (SPF/DKIM)

Von Thomas · virtueller CISO · 2026-08-01

Bei Produktteams wie bei Marketingteams gehört SendGrid (Twilio) zu den am weitesten verbreiteten Versandplattformen: transaktionale E-Mails, Anwendungsbenachrichtigungen, Kampagnen. Solange auf DNS-Seite nichts konfiguriert ist, versendet ein SendGrid-Konto jedoch unter der Identität der Plattform — die DKIM-Signatur trägt eine Domain unter sendgrid.net, die Envelope-Adresse ebenfalls. Aus Sicht von DMARC hat dieser völlig legitime Verkehr keinerlei Bindung an die Domain im From-Feld: keiner der beiden Mechanismen ist ausgerichtet, und eine p=reject-Policy würde ihn schlicht abweisen.

Die Antwort der Plattform heißt „Domain Authentication" — früher „Domain Whitelabel", inzwischen umbenannt. Das Prinzip: drei CNAME-Einträge in der DNS-Zone der Absenderdomain, die die Veröffentlichung der DKIM-Schlüssel und des nötigen SPF-Eintrags an SendGrid delegieren. Sobald die Validierung durch ist, verlässt jede Nachricht die Plattform im Namen der Organisation signiert, mit einem Envelope, der ihr ebenfalls gehört.

Sauber umgesetzt, macht diese Konfiguration SendGrid zu einem der günstigsten Fälle unter den großen ESPs: DKIM richtet sich aus, und SPF richtet sich ebenfalls aus — ein doppeltes Alignment, das andere Plattformen nicht bieten. Dieser Leitfaden erklärt die Rolle jedes CNAME, die Mechanik der „Automated Security", was die Delegation für DMARC ändert, das Link Branding, die Fehler, an denen die Validierung scheitert, und die abschließende Gegenprobe: die RUA-Berichte.

Drei CNAMEs, eine DNS-Delegation

Der Einrichtungsassistent von SendGrid erzeugt drei Einträge, die in die Zone der Domain gehören — hier beispiel.de:

em1234.beispiel.de.         CNAME  u1234567.wl123.sendgrid.net.
s1._domainkey.beispiel.de.  CNAME  s1.domainkey.u1234567.wl123.sendgrid.net.
s2._domainkey.beispiel.de.  CNAME  s2.domainkey.u1234567.wl123.sendgrid.net.

Der erste, em1234 (das genaue Präfix variiert von Konto zu Konto und lässt sich anpassen), wird zur Envelope-Subdomain: Genau dieser Name erscheint im Return-Path der ausgehenden Nachrichten. Da es ein CNAME ist, wird jede DNS-Anfrage auf diesen Namen in die Zone von SendGrid umgeleitet — und dort veröffentlicht die Plattform den passenden SPF-Eintrag, der ihre eigenen Versandadressen autorisiert. So kann der Anbieter IPs in seinem Bestand hinzufügen oder ausmustern, ohne dass sich in der Zone der Domain auch nur eine Zeile bewegt.

Die beiden folgenden, s1._domainkey und s2._domainkey, sind die DKIM-Selektoren. Gleiche Logik: Der öffentliche Schlüssel wird nicht in die Zone der Domain kopiert, sondern bei SendGrid veröffentlicht, und der CNAME schlägt die Brücke. Prüft ein empfangender Server eine Signatur mit d=beispiel.de; s=s1, folgt die DNS-Auflösung dem CNAME und holt den Schlüssel bei SendGrid ab — für den Empfänger völlig transparent.

Das ist Delegation im eigentlichen Sinn: Die Domain behält die Kontrolle — das Löschen der drei CNAMEs kappt alles augenblicklich —, aber die Pflege des Inhalts, Schlüssel wie Adresslisten, liegt bei der Plattform. Kommentierte Beispiele für DMARC-Einträge zeigen, wie sich dieser Baustein anschließend in die Gesamtpolicy der Domain einfügt: Die Domain-Authentifizierung bereitet das Alignment vor, der _dmarc-Eintrag setzt die Anweisung.

„Automated Security": Schlüsselrotation ohne DNS-Änderung

Die standardmäßig aktivierte Option „Automated Security" ist der eigentliche Daseinszweck der CNAMEs. Zwei Selektoren, s1 und s2, werden von Anfang an bereitgestellt: Die Plattform kann ein frisches Schlüsselpaar erzeugen, es auf ihrer Seite veröffentlichen und die Signaturen dann von einem Selektor auf den anderen umschalten — ohne DNS-Ticket, ohne internen Eingriff, ohne Risikofenster. Die DKIM-Schlüsselrotation, eine notorisch vernachlässigte Operation, sobald sie eine manuelle Zonenänderung verlangt, wird zum Nicht-Ereignis, das die Plattform selbst abwickelt. Ein kompromittierter oder schlicht alt gewordener Schlüssel lässt sich so ersetzen, ohne dass irgendwo ein Change-Prozess angestoßen oder ein Wartungsfenster geplant werden muss.

Die Automated Security lässt sich abschalten, womit das klassische Modell zurückkehrt: Der DKIM-Schlüssel kommt dann als TXT-Eintrag, der wörtlich in die Zone zu kopieren ist, und die SPF-Autorisierung fällt zurück ans interne Team — als include, das im eigenen Eintrag zu pflegen ist. Jede künftige Rotation wird wieder zur manuellen, koordinierten Operation. Dieser Modus hat seine Berechtigung, wenn interne Richtlinien die DNS-Delegation an Dritte untersagen — manche regulierten Branchen verlangen das —, aber der Preis ist Betriebsaufwand. Für die große Mehrheit der Organisationen ist der CNAME-Standardmodus die richtige Wahl: weniger Kopierfehler, längere Schlüssel möglich, und die kryptografische Hygiene liegt bei einem Akteur, der sie industrialisiert.

Das DMARC-Alignment: das günstige Szenario

DMARC erklärt eine Nachricht nur dann für gültig, wenn SPF oder DKIM besteht und sich mit der From-Domain ausrichtet. Genau an diesem Punkt hebt sich die Domain-Authentifizierung von SendGrid ab.

Auf DKIM-Seite trägt die Signatur d=beispiel.de — die Domain selbst, keine Plattformdomain. Das Alignment ist damit gesichert, auch im strikten Modus. Auf SPF-Seite wird der Envelope der Nachrichten zu bounce@em1234.beispiel.de: eine Subdomain der Organisationsdomain. Im entspannten Modus — dem DMARC-Standard — richtet sich diese Subdomain mit beispiel.de aus; unter DMARCbis wird die Organisationsdomain über den DNS Tree Walk bestimmt, mit demselben Ergebnis. Beide Mechanismen bestehen also ausgerichtet, und diese Redundanz hat operativen Wert: Bricht eine Weiterleitung SPF, weil sich die sendende IP ändert, überlebt DKIM; verändert ein Gateway den Nachrichtentext und entwertet die Signatur, bleibt SPF bestehen.

Der Vergleich mit anderen ESPs zeigt, was an diesem Aufbau günstig ist. Bei Mailchimp ruht das Alignment allein auf DKIM: Der Envelope bleibt auf den Domains der Plattform, SPF besteht, richtet sich aber nie aus — konform und ausreichend, doch ohne Netz. Die SPF- und DKIM-Einrichtung bei Mailjet folgt einem Zwischenmodell, mit Einträgen zum Kopieren in die Zone statt einer vollständigen Delegation. SendGrid erreicht durch die Delegation der DKIM-Selektoren und der Envelope-Subdomain das doppelte Alignment, ohne dass ein einziger Wert von Hand übertragen wird — der robusteste Aufbau, den ein ESP heute anbieten kann.

Link Branding: Domain-Kohärenz bis in die Links

Dieselbe CNAME-Mechanik gilt für eine zweite, eigenständige, aber komplementäre Funktion: das „Link Branding". Standardmäßig schreibt das Klick-Tracking von SendGrid jeden Link einer Nachricht auf eine Plattformdomain um. Mit Link Branding zielt die Umschreibung stattdessen auf eine Subdomain der Absenderdomain — url1234.beispiel.de oder ein gewähltes Präfix —, ebenfalls per CNAME delegiert.

DMARC bewertet keine Links: Dieser Baustein ändert nichts am Alignment. Was er ändert, ist die wahrgenommene Kohärenz der Nachricht. Eine E-Mail, signiert mit beispiel.de, deren sämtliche Links auf eine fremde Tracking-Domain zeigen, sendet ein dissonantes Signal — an Spamfilter wie an aufmerksame Empfänger, die vor dem Klick über einen Link fahren. Domain-Kohärenz — From, Envelope, Links, alles unter derselben Flagge — speist die Gesamtreputation; domainfremde Tracking-Links gehören zu den Faktoren, die in warum E-Mails im Spam landen untersucht werden. Wenn ohnehin CNAMEs in die Zone kommen, kostet es wenig, den Satz zu vervollständigen — die Einrichtung folgt demselben Assistenten und derselben Validierungslogik wie die Domain-Authentifizierung selbst.

Die typischen Fehler, an denen die Validierung scheitert

Die Einrichtung passt in drei Einträge, doch eine Handvoll Fallen kehrt ständig wieder.

Hinter einem CDN proxifizierte CNAMEs. Das ist Fehler Nummer eins bei Zonen, die bei Cloudflare verwaltet werden: Der Proxy (das orangefarbene Wolkensymbol) fängt die Auflösung ab und ersetzt das CNAME-Ziel durch eigene Adressen. Die SendGrid-Validierung schlägt fehl — oder schlimmer, gelingt und bricht dann lautlos. Alle drei Einträge müssen auf „DNS only" stehen, ohne Proxy: Das sind Mail-Einträge, kein Webverkehr, der beschleunigt werden müsste.
Die Subdomain em ist schon vergeben. Ein Überbleibsel einer früheren Integration, ein zweites SendGrid-Konto, ein bestehender Wildcard-Eintrag in der Zone: Kollidiert der vorgeschlagene Name, geht die Validierung nicht sauber durch. Die richtige Antwort ist ein anderes Präfix über die Option des benutzerdefinierten Return-Path (em2, m1…) — niemals das Überschreiben eines bestehenden Eintrags, von dem womöglich ein anderer Fluss abhängt.
Die Verdoppelung der Domain. Viele DNS-Oberflächen hängen die Domain automatisch an den eingegebenen Namen an: em1234.beispiel.de in das Feld „Name" zu kleben erzeugt em1234.beispiel.de.beispiel.de. Eine dig-Abfrage auf den exakt erwarteten Namen räumt den Zweifel in zehn Sekunden aus.
Zu früh geprüft — oder nie erneut geprüft. Die DNS-Propagation dauert je nach TTL Minuten bis Stunden. Ein sofortiger Fehlschlag beweist nichts; die Prüfung muss nach abgeschlossener Propagation wiederholt werden, denn die Plattform signiert erst nach bestandener Validierung im Namen der Domain.
Nachträglich gelöschte CNAMEs. Die Validierung ist keine einmal bestandene Prüfung: Die Einträge dienen jeder einzelnen Nachricht, bei jeder DKIM- und SPF-Prüfung der Empfänger. Eine Zonen-„Aufräumaktion", die sie entfernt, bricht die Authentifizierung über Nacht.

Das Ergebnis in den RUA-Berichten prüfen

Das „verified"-Banner in der SendGrid-Oberfläche bestätigt, dass die CNAMEs antworten — nicht, dass die echte Post ausgerichtet hinausgeht. Der Beweis steht in den aggregierten DMARC-Berichten, einige Tage nach der Aktivierung.

In den RUA-Berichten sollten die Zeilen, die den Versandadressen von SendGrid zugeordnet sind, zwei Ergebnisse zeigen: DKIM pass mit d=beispiel.de (Selektor s1 oder s2) und erreichtem Alignment; SPF pass mit em1234.beispiel.de als Envelope-Domain, ausgerichtet im entspannten Modus. Abweichungen sind schnell diagnostiziert: Ein DKIM, das mit d=sendgrid.net besteht, entlarvt einen Fluss, der die authentifizierte Domain nicht nutzt — ein nicht zugeordneter Subuser, ein vergessenes Zweitkonto, eine Integration, die woanders hinzeigt; ein SPF, das besteht, ohne sich auszurichten, mit einer Plattform-Envelope-Domain, verrät dasselbe Symptom. Genau diese Zeilen würden unter p=reject wieder zu Abweisungen.

Stehen beide Mechanismen über mehrere Berichtswochen hinweg auf Grün, und zwar über alle SendGrid-Flüsse (transaktional wie Marketing, alle Subuser eingeschlossen), kann die Verschärfung der Policy ihren Lauf nehmen — Testmodus t=y von DMARCbis, dann p=quarantine, dann p=reject — ohne Risiko für diesen Kanal.

Fazit

Die Domain-Authentifizierung von SendGrid beruht auf drei CNAMEs: einer Envelope-Subdomain (em1234) und zwei DKIM-Selektoren (s1._domainkey, s2._domainkey), die die Veröffentlichung der Schlüssel und des SPF-Eintrags an die Plattform delegieren. Die „Automated Security" macht die Schlüsselrotation unsichtbar; das doppelte Alignment — DKIM auf der Domain, SPF auf einer delegierten Subdomain — macht daraus einen der solidesten Aufbauten am ESP-Markt. Die klassischen Fallen sind DNS-förmig: CDN-Proxy auf diesen Einträgen abschalten, Kollision auf der Subdomain em, Verdoppelung der Domain, Validierung nach der Propagation wiederholen. Und das endgültige Urteil steht weder in der Oberfläche noch in einem Einzeltest, sondern in den aggregierten Berichten.

Für die Standortbestimmung zeigt eine kostenlose DMARC-Analyse der Domain in Sekunden, ob der SendGrid-Fluss bereits unter dem richtigen Namen signiert und ob sich der Envelope ausrichtet. Und um die Wirkung der drei CNAMEs über die Zeit zu verfolgen, öffnet das Anlegen eines Kontos den Zugang zu den dekodierten RUA-Berichten, Quelle für Quelle — die Gegenprobe, die aus einem grünen Häkchen Gewissheit macht.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos