HubSpot: E-Mail authentifizieren (DKIM, SPF und DMARC)

Von Thomas · virtueller CISO · 09. September 2026

HubSpot ist zuerst eine Marketing-Plattform: Kampagnenversand, automatisierte E-Mails, Nurturing-Sequenzen, alles auf ein CRM gestützt. Diese Marketing-Natur hat eine Folge für die Authentifizierung, die viele beim Lesen ihrer ersten DMARC-Berichte entdecken: Bei HubSpot ruht die Ausrichtung vollständig auf DKIM, denn SPF richtet sich nicht aus. Zu verstehen, warum, erspart einen sehr verbreiteten Konfigurationsfehler — jenen, der darin besteht, ein SPF zu „reparieren", das sich nie ausrichten sollte.

Standardmäßig versendet eine mit HubSpot verbundene Domain unter der Identität der Plattform. Die Signatur trägt nicht die angezeigte Domain, der Umschlag liegt auf der technischen Domain von HubSpot, und eine p=reject-Richtlinie weist diesen an sich legitimen Verkehr ab. Die Einrichtung der Authentifizierung — das „Verbinden der Versanddomain" in den HubSpot-Einstellungen — setzt zwei DKIM-Einträge, die genügen, damit DMARC besteht. Der Rest läuft darauf hinaus, klar zu verstehen, was SPF tut und vor allem, was es in dieser Anordnung nicht tut.

Dieser Leitfaden behandelt die zwei DKIM-CNAMEs, den Grund, warum SPF sich nicht ausrichtet, wie DMARC dennoch allein über DKIM validiert, den Fehler, HubSpot in das Root-SPF aufzunehmen, sowie die häufigen Konfigurationsfallen und den abschließenden Gegenbeweis über die RUA-Berichte.

Die zwei DKIM-CNAMEs

Die DKIM-Authentifizierung von HubSpot ruht auf zwei CNAME-Einträgen, die in der Zone der Versanddomain gesetzt werden. Aus den Einstellungen erzeugt und zeigt HubSpot beim Verbinden einer Domain die genauen zu veröffentlichenden Werte an — von der Form:

hs1._domainkey.beispiel.de.  CNAME  beispiel.de.hs1._domainkey.hubspotemail.net.
hs2._domainkey.beispiel.de.  CNAME  beispiel.de.hs2._domainkey.hubspotemail.net.

Zwei Selektoren, hs1 und hs2, werden von Anfang an bereitgestellt: Die Logik ist die einer CNAME-Delegation, im Prinzip identisch mit anderen großen Plattformen. Der öffentliche Schlüssel wird nicht in die Zone der Domain kopiert, er lebt bei HubSpot, und der CNAME schlägt die Brücke. Zwei Selektoren erlauben den Schlüsselwechsel ohne manuellen Eingriff in die Zone — HubSpot kann ein neues Paar erzeugen und auf seiner Seite von einem Selektor zum anderen umschalten.

Entscheidend für DMARC: Die angebrachte Signatur trägt d=beispiel.de, die Organisationsdomain selbst. Die DKIM-Ausrichtung ist somit gesichert, sobald die beiden CNAMEs propagiert sind und die Domain in der Konsole validiert ist. Es ist dieser Mechanismus, und nur er, der DMARC bestehen lässt.

Warum SPF sich nicht ausrichtet

Hier liegt der Punkt, der verwirrt. Die Umschlagadresse der HubSpot-Kampagnen — der Return-Path, den SPF tatsächlich prüft — bleibt auf der technischen Domain von HubSpot (hubspotemail.net). SPF authentifiziert diese Domain zwar: HubSpot veröffentlicht dort die Autorisierung seiner Server. Doch es richtet sich an hubspotemail.net aus, nicht an beispiel.de. Aus Sicht von DMARC besteht SPF, ohne sich auszurichten — und ein Mechanismus, der besteht, ohne sich auszurichten, zählt nicht.

Anders als Plattformen, die einen eigenen Return-Path anbieten (einen Bounce-CNAME auf der Domain des Kunden), verlagert HubSpot den Umschlag für seine Marketing-Sendungen nicht auf die Domain des Absenders. Es gibt daher keinen Hebel, um SPF auszurichten: Es ist eine Architekturentscheidung der Plattform, kein vergessenes Kästchen. Die SPF-Ausrichtung bei HubSpot erzwingen zu wollen, heißt, etwas zu jagen, das es in dieser Anordnung nicht gibt.

DMARC besteht allein über DKIM

Hier spielt die Mechanik von DMARC zugunsten der Konfiguration. DMARC validiert eine Nachricht nur, wenn SPF oder DKIM besteht und sich ausrichtet — eine der beiden Bedingungen genügt. Bei HubSpot richtet sich DKIM aus; SPF nicht. Die Nachricht besteht DMARC also auf der Grundlage des alleinigen DKIM, was vollkommen konform und ausreichend ist.

Diese Asymmetrie hat eine wissenswerte Grenze: Die Redundanz ist geringer. Wo eine Anordnung mit doppelter Ausrichtung (SPF und DKIM) den Verlust eines der beiden übersteht, hält eine HubSpot-Sendung nur durch DKIM. Schreibt ein zwischengeschaltetes Gateway den Nachrichtentext um und macht die Signatur ungültig, fängt nichts die Nachricht auf — SPF, nicht ausgerichtet, kann nicht einspringen. In der Praxis bleibt dieser Fall bei direktem Marketing-Verkehr (ohne Weiterleitung oder kaskadierende Verteilerliste) selten, und DKIM hält. Die kommentierten Vorlagen zeigen, wie die _dmarc-Anweisung gesetzt wird, sobald DKIM steht. Unter DMARCbis wird die als Referenz dienende Organisationsdomain über den DNS Tree Walk bestimmt, ohne Änderung an dieser Überlegung.

Der einzige Fall, in dem die DKIM-allein-Asymmetrie wirklich beißt, sind weitergeleitete Nachrichten: eine automatische Weiterleitung, eine Verteilerliste, die den Betreff umschreibt oder eine Fußzeile hinzufügt. Dort kann die DKIM-Signatur wegfallen, und ohne ausgerichtetes SPF als Reserve scheitert die Nachricht an DMARC. Das ARC-Protokoll wurde genau dafür entworfen — es lässt einen vertrauenswürdigen Vermittler die ursprüngliche Authentifizierung bezeugen —, aber noch nicht jeder Empfänger wertet es aus. Bei direkt an Abonnenten gesendeter Marketing-Post bleibt das Thema theoretisch; es wird real, sobald sich Weiterleitungen einschieben.

SPF nicht fälschlich „reparieren"

Der häufigste Fehler rund um HubSpot besteht darin, include:_spf.hubspot.com (oder Äquivalent) dem Root-SPF-Eintrag der Domain hinzuzufügen, in dem Glauben, so SPF auszurichten. Das ist nutzlos und kontraproduktiv. Nutzlos, weil die SPF-Ausrichtung von der Umschlag-Domain abhängt, nicht von den Includes des Root-SPF: Solange der Umschlag auf hubspotemail.net bleibt, richtet kein Include irgendetwas aus. Kontraproduktiv, weil jeder Include eine der zehn DNS-Abfragen verbraucht, die SPF erlaubt — und ein Eintrag, der reflexhaft Dienste stapelt, löst irgendwann einen permerror aus, der SPF für die gesamte Domain ungültig macht, einschließlich der Post, die sich sehr wohl ausrichtete.

Die Regel ist also klar: Bei HubSpot bleibt das Root-SPF für Kampagnen unangetastet. Man stützt sich auf DKIM, beachtet das Limit von zehn DNS-Abfragen bei SPF für die anderen Dienste und lässt den HubSpot-Umschlag sein Leben führen, ohne ihn ausrichten zu wollen.

Häufige Konfigurationsfehler

Mehrere Fallen tauchen im Korpus der Berichte regelmäßig auf, die der kostenlose DMARC-Analyzer täglich verarbeitet.

Erwarten, dass SPF sich ausrichtet. Der häufigste: Ein Bericht zeigt SPF „fail" (im Sinne der Ausrichtung) auf HubSpot-Verkehr, und man versucht, einen Mangel zu beheben, der keiner ist. Sobald DKIM sich ausrichtet, besteht DMARC.

HubSpot dem Root-SPF hinzufügen. Oben beschrieben: keine Wirkung auf die Ausrichtung, mit dem Risiko des permerror.

Die CNAMEs veröffentlichen, ohne die Domain in HubSpot zu verbinden. Wie anderswo muss die Plattform die Propagierung feststellen und die Versanddomain als authentifiziert markieren, bevor die Signaturen tatsächlich angebracht werden.

Die Richtlinie ohne DKIM-Prüfung verschärfen. Der Wechsel zu p=reject in der Annahme, gedeckt zu sein, während die CNAMEs nicht propagiert sind, bedeutet, die eigenen Kampagnen abzuweisen.

Die verbundene Domain mit der From-Domain verwechseln. Die in HubSpot authentifizierte Domain muss der im Absender der Kampagnen angezeigten entsprechen; ein Versand unter einem From @beispiel.de, während nur eine andere Domain verbunden ist, lässt diesen Verkehr ohne ausgerichtetes DKIM, und DMARC scheitert für diese Sendungen.

Geteilte IP, dedizierte IP und Marketing-Reputation

HubSpot versendet standardmäßig aus einem geteilten IP-Pool, über Kunden hinweg mancherorts gebündelt. Für hohe Volumina wird eine dedizierte IP als Option angeboten: Die Reputation gehört dann allein dem Konto, muss aber aufgebaut werden — eine frische IP ist zu wärmen, über mehrere Tage schrittweise im Volumen hochzufahren, sonst behandeln empfangende Anbieter sie als verdächtig. Diese Wahl hat keine Wirkung auf die DMARC-Ausrichtung — DKIM richtet sich unabhängig von der sendenden IP gleich aus —, wiegt aber auf der Zustellbarkeit und damit auf dem, was die Zustellraten der Berichte zeigen.

Der Marketing-Verkehr hat überdies ein besonderes Versandprofil: Volumenspitzen, höhere Abmelde- und Beschwerderaten als transaktionale Post. Deshalb ist es oft klug, Kampagnen von einer dedizierten Subdomain aus zu versenden statt von der Root-Domain, um die Marketing-Reputation von der der menschlichen Post zu isolieren. Diese Trennung ändert nichts an der oben beschriebenen DKIM-Mechanik: Der Selektor signiert im Namen der verbundenen Subdomain, die sich im entspannten Modus an der Organisationsdomain ausrichtet — und die Root-Domain, die der Menschen, behält eine eigene Reputation.

Der Gegenbeweis: die RUA-Berichte

Der einzige Beleg dafür, dass eine Konfiguration hält, ist nicht die HubSpot-Konsole, sondern das, was die Empfänger melden. Sobald ein _dmarc-Eintrag mit einer rua=-Adresse veröffentlicht ist, treffen die aggregierten Berichte binnen weniger Tage ein und schlüsseln Quelle für Quelle auf, was sich ausrichtet und was scheitert. Das Lesen der aggregierten DMARC-Berichte bestätigt den erwarteten Fall für HubSpot: auf der HubSpot-Quelle DKIM ausgerichtet, SPF nicht ausgerichtet — und das ist ein korrektes Ergebnis, kein Mangel, solange die DKIM-Spalte grün ist.

Die meisten Organisationen betreiben HubSpot neben anderen Absendern — einem transaktionalen Anbieter, der betrieblichen Mail-Suite, vielleicht einem Helpdesk. Jeder erscheint als eigene Quelle in den Berichten, und jeder richtet sich zu seinen eigenen Bedingungen aus: HubSpot allein über DKIM, eine Mail-Suite oft über SPF und DKIM. Sie nebeneinander zu lesen, verhindert ein voreiliges p=reject, solange eine Quelle noch nicht ausgerichtet ist — der Bericht, nicht die Konsole eines einzelnen Anbieters, trägt das Gesamtbild dessen, was unter der Domain ausgeht.

Eine einfache Kadenz genügt: eine erste Durchsicht wenige Tage nach der Veröffentlichung des _dmarc-Eintrags, sobald mehrere Empfänger gemeldet haben, danach ein wöchentlicher Blick, solange die Richtlinie bei p=none bleibt. Der HubSpot-Verkehr ist an seinen stabilen Adressbereichen schnell zu erkennen; es geht nicht darum, ein hier erwartetes, nicht ausgerichtetes SPF zu jagen, sondern zu prüfen, dass DKIM über alle Kampagnen hält, bevor verschärft wird. Sobald das über mehrere Tage bestätigt ist, erfolgt der Wechsel zu p=reject ohne Risiko für den HubSpot-Verkehr. Der Online-Analyzer setzt diesen Zustand aus den veröffentlichten Einträgen und den empfangenen Berichten zusammen und verortet die Domain auf dem Weg, der zu p=reject führt.