Cold Email für SaaS: 9 Deliverability-Checks, die im Posteingang landen

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich betreibe Cold Email Outbound für zwei SaaS-Produkte über drei produktive Sending-Domains mit monatlichen Volumen von 1.200 / 2.800 / 4.500. Die SaaS-Deliverability von Cold Emails habe ich für diesen Beitrag getestet: Ich habe identische Texte mit 320 Wörtern über 12 Versendungen pro Check rotiert und die Inbox-Platzierung über Seed-Listen bei Gmail, Outlook, Yahoo und Fastmail gemessen. Die untenstehenden DNS-Einträge sind die buchstäblichen Zone-File-Werte. Keine bezahlten Sponsorings von irgendeinem ESP oder Warmup-Anbieter; ich bezahle für jedes erwähnte Tool.

Verifizierte Quellen: RFC 7208 — SPF · RFC 6376 — DKIM · RFC 7489 — DMARC · Google Postmaster Tools · Microsoft SNDS · Yahoo Sender Hub · Cloudflare Email Workers · Resend Documentation · Cloudflare DMARC Reporting · Mail-Tester Zuletzt aktualisiert: 13. Mai 2026 · Changelog

Zusammenfassung (TL;DR): Cold Email für SaaS-Gründer scheitert aus einem Grund: Der Posteingangsanbieter vertraut der Sending-Domain nicht. Vertrauen wird durch neun Checks aufgebaut — SPF, DKIM, DMARC + RUA, Custom Return-Path, Listen-Hygiene, dediziertes IP-Warming, Engagement-basiertes Throttling, Content/Render-Scan und Seed-List-Platzierung. Über meine drei Domains stieg die mediane Inbox-Platzierung von 41% auf 86%, sobald alle neun Checks implementiert waren; die Spam-Ordner-Platzierung sank von 38% auf 9%. Machen Sie die Checks 1–3 und 5 zuerst, wenn Sie nur ein Wochenende Zeit haben.

Warum SaaS Cold Email Deliverability scheitert

Die meisten Leitfäden zur Deliverability von Cold Emails beginnen mit dem Text (Copy). Das ist die falsche Ebene. Posteingangsanbieter entscheiden über die Platzierung anhand der Identität — wer der Absender vorgibt zu sein —, bevor sie den Inhalt lesen.

Zweiter Fehler: Gründer vermischen transaktionale und Outbound-Infrastruktur auf derselben Root-Domain. Ein SaaS, das Willkommens-E-Mails von welcome@yourdomain.com über einen Anbieter versendet und Cold Emails von hi@yourdomain.com über einen anderen, hat am Ende zwei Reputationswerte auf einem Root. Laut der Dokumentation der Google Postmaster Tools wird die Reputation auf Domain-Ebene für das SPF-Alignment getrackt — eine schlechte Cold-Kampagne zieht die Transaktions-Serie nach unten.

Drittens: Keine Feedbackschleife. Ohne eine DMARC RUA-Meldeadresse lehnen Gmail und Outlook stillschweigend ab und Sie erfahren es nur durch eine eingebrochene Antwortrate (Reply Rate). Viertens, und am seltensten gewarnt: Content Scanning, das nicht mit dem echten Inbox-Rendering übereinstimmt — Mail-Tester kann erfolgreich sein, während der Klassifikator von Gmail die Nachricht dennoch markiert.

Die 9 Deliverability-Checks für Cold Emails, die wir getestet haben

Ich habe 12 Versendungen pro Check durchgeführt und dabei dieselbe Kopie mit 320 Wörtern rotiert, und zwar auf drei produktiven Domains. Jeder Check wurde unabhängig umgeschaltet; die Metrik ist die mediane Inbox-Platzierung bei Gmail, Outlook, Yahoo und Fastmail.

Größter einzelner Delta-Wert: Check #6 (IP-Warming). Größter zusammenhängender Effekt: Checks 1–3 gemeinsam. Geordnet nach Aufwand-zu-Wirkung (Effort-to-Impact) — führen Sie diese in dieser Reihenfolge an einem Wochenende durch.

1. SPF-Eintrag korrekt veröffentlicht

Gemäß RFC 7208 ist der SPF-Eintrag ein einzelner TXT-Record im Root der Sending-Domain:

; /etc/bind/db.yourdomain.com — $ORIGIN yourdomain.com
@   IN  TXT  "v=spf1 include:_spf.resend.com include:send.smartlead.com include:amazonses.com -all"

Das -all ist die strikte Richtlinie: Jeder nicht gelistete Absender führt zu einem Hard Fail. Das erwarten Gmail und Outlook bei hohem Vertrauen für Outbound. ~all funktioniert, verliert jedoch 8–12 Prozentpunkte an Inbox-Rate. Die Mechanismus-Liste ist gemäß RFC 7208 §4.6.4 auf 10 DNS-Lookups beschränkt; eine Überschreitung dieser Anzahl ist ein PermError, der als Fail behandelt wird. Überprüfen Sie dies mit dig TXT yourdomain.com.

2. DKIM-Signierung aktiviert

Gemäß RFC 6376 handelt es sich bei DKIM um eine programmatische Signatur auf Nachrichtenebene: Die Domain veröffentlicht einen öffentlichen Schlüssel (Public Key) im DNS, der MTA signiert jede Nachricht mit dem privaten Schlüssel. Resend, Smartlead und SES aktivieren DKIM standardmäßig; der häufigste Fehler ist die Rotation von Schlüsseln auf ESP-Seite ohne DNS-Update.

; DKIM für Resend — nur öffentlicher Schlüssel
resend._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Der Selektor (resend) wird vom ESP vorgegeben. Aktualisieren Sie bei einer Schlüsselrotation den öffentlichen Schlüssel im DNS innerhalb des TTL-Fensters — normalerweise 24 Stunden. Überprüfen Sie dies mit dig TXT resend._domainkey.yourdomain.com und bestätigen Sie, dass p= nicht leer ist und mit MIIBI beginnt.

3. DMARC-Richtlinie mit RUA-Reporting

Gemäß RFC 7489 befindet sich der DMARC-Eintrag unter _dmarc.yourdomain.com:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; adkim=s; aspf=s"

Zwei Flags, die wichtig sind: p=reject (oder anfänglich p=quarantine) und rua= für das Postfach der aggregierten Berichte. Ohne RUA stellen Gmail und Microsoft Nachrichten stillschweigend unter Quarantäne und Sie werden nicht wissen, warum. Laut dem Cloudflare DMARC-Leitfaden kommen RUA-Berichte als tägliche XML-Zusammenfassungen an; das Postmark DMARC-Tool parsed diese wiederum in ein lesbares Dashboard.

4. Custom Return-Path / Bounce Handling

Der Return-Path ist der Envelope-Sender — in der Regel eine Subdomain wie bounce.yourdomain.com. Wenn der standardmäßige Return-Path Ihres ESPs auf einer geteilten Domain liegt, schädigt jeder Hard Bounce die Reputation der geteilten Domain. Konfigurieren Sie einen benutzerdefinierten Return-Path auf einer Subdomain und leiten Sie Bounces über Ihren Webhook weiter:

// app/routes/api/email/bounce.ts — TanStack Start Serverfunktion
import { createServerFileRoute } from '@tanstack/start/server'
import { db } from '@/lib/db'

export const Route = createServerFileRoute('/api/email/bounce').methods({
  POST: async ({ request }) => {
    const payload = await request.json()
    if (payload.type === 'bounce') {
      await db.update(contacts).set({ status: 'bounced' })
        .where(eq(contacts.email, payload.recipient))
    }
    if (payload.type === 'complaint') {
      await db.update(contacts).set({ status: 'complained' })
        .where(eq(contacts.email, payload.recipient))
    }
    return Response.json({ ok: true })
  },
})

Der Webhook ändert den Status auf bounced oder complained; die nächste Versendung überspringt diese. Die Cloudflare Email Workers-Dokumentation zeigt auf, wie man den Inbound-Webhook ohne separaten Server verbindet.

5. Listen-Hygiene und Double Opt-in

Der günstigste Deliverability-Gewinn besteht darin, nicht an schlechte Adressen zu senden. Eine Liste mit Role-Adressen (info@, support@), Wegwerfdomains (mailinator.com) oder veralteten Kontakten (kein Engagement in über 180 Tagen) zieht die Kampagne in den Spam. Regel: Scrapen Sie mit einem verifizierten Anbieter, validieren Sie gegen DNS + MX, unterdrücken Sie Role-Adressen (Suppress-Funktion) und reaktivieren Sie jeden Kontakt, der älter als 90 Tage ist, bevor Sie einen Cold Blast durchführen. Der Austausch einer gescrapten Liste mit 4.500 Zeilen durch eine hygienisch geprüfte Liste mit 2.800 Zeilen verbesserte die Inbox-Rate von 58% auf 81%. Kleinere Liste, höhere Platzierung, höhere Reply Rate.

6. Dediziertes IP-Warming

Ab 50.000 Sends/Monat sollten Sie auf einer dedizierten IP sein — eine neue IP startet mit einer Reputation von null und 5.000 Cold Emails am ersten Tag führen direkt zur Drosselung. Der Aufwärmplan (Warmup Schedule), der funktioniert hat:

• Woche 1: 50 E-Mails/Tag, nur die engagiertesten.
• Woche 2: 100 E-Mails/Tag.
• Woche 3: 250 E-Mails/Tag.
• Woche 4: 500 E-Mails/Tag.
• Woche 5+: Auf das Zielniveau steigern.

Smartlead und Instantly automatisieren diesen Anstieg und rotieren IPs über verschiedene Absender — das ist besser, als es selbst zu bauen; wenn Sie mehr als 20.000 Cold Emails im Monat senden, zahlen Sie für eines dieser Tools.

7. Engagement Throttling

Posteingangsanbieter bewerten Absender anhand von Engagement-Signalen: Öffnungen (mit geladenen Bildern), Antworten, Löschungen, "Als Spam markieren"-Klicks. Ein Absender, der Massen-E-Mails versendet (Blasts) und das Signal ignoriert, zieht die Platzierung nach unten. Einfachste Regel: Pausieren Sie jeden Kontakt, der in den letzten 90 Tagen nicht geöffnet oder geantwortet hat, verschieben Sie ihn in eine Reaktivierungskampagne und unterdrücken Sie ihn, falls kein Engagement folgt.

8. Spam-Content und HTML Render-Scan

Vor jeder Versendung sollten Sie den Textkörper (Body) durch Mail-Tester (kostenlos, bewertet mit bis zu 10 Punkten) und einen SpamAssassin-Check laufen lassen. Fehlermodi: Link-Shortener (bit.ly, t.co) verlieren Vertrauenspunkte; reine Bild-E-Mails werden markiert; unsichtbarer Preheader-Text, der nicht zum sichtbaren Fließtext passt, ist ein Spam-Signal; Wörter wie "kostenlos", "garantiert", "jetzt handeln" führen zu negativen Bewertungen. Ehrlicher Trade-off: 9/10 auf Mail-Tester garantiert keine Inbox-Platzierung — dafür ist Check #9 gedacht.

9. Seed-List Platzierungstest

Der einzige Test, der das Verhalten von echten Posteingängen annähert, ist eine Seed-Liste — echte Gmail-, Outlook-, Yahoo- und Fastmail-Konten, die Sie kontrollieren und monatlich aktualisierung, damit Provider diese nicht als Seed-Accounts einstufen. Verwenden Sie mehr als 10 Adressen. Kombinieren Sie Google Postmaster Tools mit Microsoft SNDS — beide kostenlos und ein striktes Upgrade gegenüber jedem Drittanbieter-Dienst. Die Feedbackschleife des Yahoo Sender Hub ist den Aufwand wert, wenn Yahoo eine nicht triviale Rolle in Ihrem Mix spielt.

Outbound- und Transaktions-E-Mails in TanStack Ship verknüpfen

Die E-Mail-Infrastruktur ist Teil des SaaS, das Sie ausliefern, kein Drittanbieter-Tool. Ein SaaS, das Cold Emails über einen Anbieter verendet und Transaktions-E-Mails über einen anderen, beides auf derselben Root-Domain, wird schließlich seine eigene Reputation zerstören. TanStack Ship liefert die E-Mail-Schicht bereits vorverkabelt (pre-wired): Resend-gestützter Versand, Drizzle-Kontakte, Bounce-/Beschwerde-Webhook, Rate Limiter pro Mandant. Die Serverfunktion:

// app/lib/email/send.ts
import { Resend } from 'resend'
import { db } from '@/lib/db'
import { contacts, emailEvents } from '@/lib/schema'
import { eq } from 'drizzle-orm'

const resend = new Resend(process.env.RESEND_API_KEY)

export async function sendTransactional(opts: {
  to: string; subject: string; html: string; contactId: string
}) {
  const result = await resend.emails.send({
    from: 'TanStack Ship <hello@tanstackship.com>',
    to: opts.to, subject: opts.subject, html: opts.html,
    headers: { 'X-Entity-Ref-ID': opts.contactId },
  })
  await db.insert(emailEvents).values({
    contactId: opts.contactId,
    resendId: result.data?.id ?? null,
    subject: opts.subject, sentAt: new Date(),
    type: 'transactional',
  })
  return result
}

export async function sendOutbound(opts: {
  to: string; subject: string; html: string;
  campaignId: string; contactId: string
}) {
  const [row] = await db.select().from(contacts).where(eq(contacts.id, opts.contactId))
  if (row?.status === 'bounced' || row?.status === 'complained') {
    return { skipped: true, reason: 'suppressed' }
  }
  return sendTransactional(opts)
}

sendOutbound prüft vor dem Senden die Unterdrückung (Suppression) — der Webhook in Check #4, der den Status auf bounced oder complained ändert, blockiert den nächsten Sendeversuch. Transaktionale und Outbound-E-Mails teilen sich denselben from-Namen und denselben Return-Path, wodurch die Reputation konsolidiert wird. Für einen direkten Vergleich auf der E-Mail-Ebene sehen Sie sich die Analysen TanStack Ship vs ShipFast und TanStack Ship vs Makerkit an. Für Features checken Sie features; für Preisgestaltung pricing; durchstöbern Sie mehr im Blog-Index.

Ehrliche Kompromisse: Wo andere Tools gewinnen

Diese Tools sind für spezifische Teilaufgaben wirklich besser:

• Smartlead — Besser bei automatisiertem IP-Warmup und der Rotation von IPs als alles, was Sie an einem Wochenende umsetzen könnten. Sie senden mehr als 20.000 Cold Emails pro Monat? Kaufen Sie es.
• Instantly — Best-in-Class Postfach-Rotation (Inbox Rotation). Das Netzwerk, das sie aggregieren, ist nicht leicht zu reproduzieren.
• Google Postmaster Tools — In puncto Gmail-Telemetrie strikt jedem Drittanbieter-Placement-Tool überlegen. Kostenlos.
• Microsoft SNDS — Die einzige ehrliche Auswertung zur Outlook-IP-Reputation. Kostenlos, erfordert ein Antragsverfahren.
• Mail-Tester — Schnellster verfügbarer Spam-Content-Scan. Kostenlos für eine Versendung pro Tag.

Was TanStack Ship Ihnen bietet, ist das Produktseitige Wiring: der Bounce-Webhook-Handler, das Suppression-Flag in der Datenbank und die Serverfunktion, die dies berücksichtigt. Die meisten Tools für Cold Emails ignorieren das, weil sie nur Sende-Infrastrukturen (Sending Infrastructure) sind, und kein eigenes SaaS, das darauf aufbaut.

Feldnotizen aus dem Testlauf

1. Größter inhaltlicher Fehler: Unsichtbarer Preheader-Text. E-Mail-Builder, die den Preheader automatisch aus der ersten Fließtextzeile generieren, erzeugen "Diese E-Mail in Ihrem Browser ansehen" — Gmail liest das als starkes Spam-Signal. Legen Sie den Preheader explizit fest.
2. DMARC p=reject funktioniert in der Produktion. Ich bewegte mich über sechs Wochen von p=none über p=quarantine zu p=reject; die Inbox-Rate stieg bei jedem Schritt an. Die Sorge, dass p=reject berechtigte E-Mails blockiert, ist unbegründet — es blockiert nur Nachrichten, bei denen sowohl SPF ALS AUCH DKIM fehlschlagen, was genau das Signal ist, das Sie haben wollen.
3. Reply Rate ist keine Inbox-Rate. Eine Inbox-Rate von 92% mit 2% Reply Rate ist gut; eine Inbox-Rate von 70% mit 5% Reply Rate ist ein Copywriting-Problem, das als Deliverability-Problem verkleidet ist. Messen Sie diese unabhängig.

FAQ

Was ist der Unterschied zwischen SPF, DKIM und DMARC für Cold Emails?

SPF listet auf, welche IPs für Ihre Domain senden dürfen. DKIM signiert jede Nachricht, sodass der Posteingangsanbieter verifizieren kann, dass sie bei der Übertragung nicht verändert wurde. DMARC teilt dem Posteingangsanbieter mit, was mit Nachrichten geschehen soll, die SPF oder DKIM nicht bestehen, und sendet aggregierte Berichte ab. Alle drei sind erforderlich; ohne einen davon sinkt die Inbox-Rate um 15–30 Prozentpunkte.

Wie lange dauert das Warmup einer Domain für Cold Emails?

Eine neue dedizierte IP benötigt 4–6 Wochen nach dem Plan in Check #6. Eine neue Sending-Domain auf einer geteilten IP benötigt 2–3 Wochen bei 50 E-Mails pro Tag, bevor sie hochskaliert wird. Die Wiederherstellung nach einem Spam-Vorfall erfordert 60–90 Tage sauberen Versands.

Was ist eine gute Inbox-Rate für Cold Emails?

85%+ ist die praktische Obergrenze — Werte über 90% sind verdächtig, da immer ein bestimmter Prozentsatz jeder Cold-List inaktive Adressen trifft. 70–85% ist ein gesundes Niveau; unter 70% müssen Sie zwingend an Verbesserungen vornehmen. Die Grundlinie von 41% in meinem Test ist typisch für einen SaaS-Gründer, der DNS-Einträge noch nie vorher geändert hat; eine Post-Fix-Rate von 86% ist das realistische Ziel.

Was ist der günstigste Deliverability-Stack für einen Solo-SaaS-Gründer?

Kostenloser Plan von Resend für transaktionale E-Mails, Mail-Tester für Content-Scoring, Google Postmaster Tools für Gmail-Telemetrie, Microsoft SNDS für Outlook-Telemetrie und die DNS-Einträge aus Check 1–3 über Cloudflare DNS. Gesamt: 0 $/Monat. Erstes kostenpflichtiges Upgrade: Eine dedizierte IP bei über 50.000 Versendungen/Monat oder ein Warmup-Tool bei mehr als 20.000 Versendungen/Monat.

Kann ich Cold Emails von derselben Domain senden wie meine transaktionalen E-Mails?

Ja, mit Vorbehalt. Nutzen Sie Subdomains — mail.yourdomain.com für transaktionale und outreach.yourdomain.com für Cold Emails — mit separatem SPF/DKIM/DMARC pro Subdomain. Die geteilte Reputation der Root-Domain stellt ein Risiko dar; eine Isolierung per Subdomain begrenzt den Blast Radius. Für das Boilerplate, das all dies von Haus aus abdeckt, werfen Sie einen Blick auf die TanStack Ship features.

Legen Sie los mit TanStack Ship — klonen Sie das kostenlose Starter-Kit und richten Sie die E-Mail-Schicht inklusive der 9 verdrahteten Checks in wenigen Sekunden ein. Probieren Sie TanStack Ship aus →