Landingpage · kostenloser SMTP-Dienst

Worauf sollte ein Produktteam bei der Wahl eines kostenlosen SMTP-Dienstes achten?

Bewerten Sie einen kostenlosen SMTP-Dienst als eingeschränkte Produktionsabhängigkeit, nicht als Hostnamen zum Nulltarif. Prüfen Sie, ob das Angebot ein dauerhafter kostenloser Tarif oder eine ablaufende Testphase ist, welche Nachrichten, Empfänger, Bytes, Logs, Events und Support-Leistungen auf die Limits angerechnet werden, was bei Erreichen der Obergrenze passiert und ob Zahlungsdaten oder automatische Mehrkosten verlangt werden. Testen Sie anschließend verpflichtendes TLS, eingeschränkte Zugangsdaten, verifizierte Absenderdomains, SPF, DKIM, DMARC-Alignment, das Verhalten bei teilweise abgelehnten Empfängern, 4xx- und 5xx-Antworten, Bounces, Beschwerden, Sperrlisten, Aufbewahrung, Export und Löschung. Modellieren Sie die Migrationskosten vor dem Launch und setzen Sie die Annahme durch einen kostenlosen Tarif niemals mit Zustellung oder Platzierung im Posteingang gleich.

„Kostenlos“ anhand des aktuellen Vertrags definieren

„Kostenlos“ kann ein dauerhaftes Kontingent, eine befristete Testphase, Startguthaben, Tests nur an verifizierte Empfänger oder einen kostenpflichtigen Tarif mit befristetem Guthaben bezeichnen. Lesen Sie am Tag der Bewertung die aktuellen Preise und Bedingungen des Providers. Erfassen Sie Währung, Region, Steuern, ob eine Zahlungskarte nötig ist, Ablauf der Testphase, enthaltene Einheiten, Verhalten bei Mehrverbrauch, Verhalten bei Sperrung und welche Funktionen beim Downgrade wegfallen. Verlassen Sie sich nicht auf Suchergebnis-Snippets, alte Vergleichsartikel, Screenshots oder einen Vertriebschat ohne belastbare Vertragsreferenz. AWS SES, Resend und Mailgun veröffentlichen auf ihren offiziellen Seiten unterschiedliche aktuelle Preismodelle und Leistungsumfänge; keines davon sollte als austauschbar gelten. Verknüpfen Sie die geprüfte Seiten-URL und das Erfassungsdatum mit der Entscheidung und planen Sie vor dem Launch eine erneute Prüfung ein, denn Provider-Angebote können sich ändern. Kostenlose Anschaffung beseitigt keine Kosten für Engineering, DNS, Monitoring, Datenschutz, Vorfälle oder Migration.

Den Workload in abrechenbaren und betrieblichen Einheiten modellieren

Schätzen Sie Nachrichten, Empfänger, Anhänge, Bytes, API- oder SMTP-Anfragen, Event-Zustellungen, eingehende E-Mails, gespeicherte Inhalte, Log-Aufbewahrung, Domains, Teammitglieder und Umgebungen. Eine Nachricht mit mehreren Empfängern kann das Kontingent anders verbrauchen als eine Transaktion mit einem Empfänger. Wiederholungsversuche, Test-Traffic, Warm-up, Bounces und erneut abgespielte Webhooks können Volumen hinzufügen. Berechnen Sie den Bedarf im Durchschnitt, in der Spitzenminute, der Spitzenstunde, pro Tag, pro Monat und saisonal, dazu Reserven für Wachstum und Vorfälle. Halten Sie die Ratenkontrollen der Anwendung unterhalb der Provider-Obergrenzen und schützen Sie Mandanten voreinander. Fragen Sie, was bei null verbleibenden Einheiten passiert: harte Ablehnung, Zurückstellung, automatische Abrechnung, eingeschränkte Funktionen oder stiller Verlust von Logs. Ein kostenloser Tarif, der Versandaufrufe abdeckt, aber eine nutzbare Event-Historie, Support oder den Export der Sperrliste ausschließt, kann betrieblich teurer sein als ein kleiner kostenpflichtiger Tarif. Validieren Sie die beobachteten Zähler des Kontos vor dem Produktivbetrieb mit kontrolliertem Traffic.

Sichere SMTP-Submission verlangen

Ein produktiver SMTP-Dienst sollte geschützte Submission, unterstützte Ports, TLS-Verhalten, Authentifizierungsmechanismen, Zertifikatsanforderungen, den Geltungsbereich der Zugangsdaten und die Rotation dokumentieren. Bevorzugen Sie verpflichtendes TLS und brechen Sie sicher ab bei fehlendem STARTTLS, Zertifikatsfehler, abweichendem Hostnamen oder nicht unterstütztem Protokoll. Speichern Sie Zugangsdaten in einem verwalteten Secret-System, niemals in Browser-Code, mobilen Apps, Quellcode, Images, Logs, URLs, Analytics, Tickets oder Prompts. Trennen Sie Befugnisse für Produktion, Tests, Mandanten und Administration. Prüfen Sie, ob der kostenlose Tarif Zugangsdaten, Quell-IPs, Domains, Regionen oder gleichzeitige Verbindungen einschränkt. RFC 8314 empfiehlt, Klartextprotokolle zugunsten von TLS für Submission und Zugriff abzulösen, während RFC 4954 die SMTP-Authentifizierung als Protokollerweiterung definiert, nicht als Produktautorisierung. Die Anwendung muss weiterhin Geschäftsereignis, Absender, Mandant, Empfänger, Template und Nachrichtenklasse autorisieren, bevor sie die SMTP-Verbindung öffnet.

Absenderidentität und DNS-Inhaberschaft prüfen

Verlangen Sie eine From-Domain im Besitz der Organisation und ein dokumentiertes Verfahren zur Domain-Verifizierung. Inventarisieren Sie SMTP MAIL FROM bzw. Return-Path, sichtbares From, DKIM-d=-Domain und Selektor, sendende IPs und die Behandlung von Antworten. Veröffentlichen Sie eine gültige SPF-Richtlinie, die den tatsächlichen Pfad enthält, konfigurieren Sie die DKIM-Signierung mit geschützten Schlüsseln und werten Sie das DMARC-Alignment mit der sichtbaren From-Domain aus. Die Verifizierung durch den Provider belegt, dass eine Einrichtungsprüfung bestanden wurde; sie belegt weder die Einwilligung der Empfänger noch korrektes Produktiv-Routing, Reputation oder Platzierung im Posteingang. Klären Sie, welche DNS-Einträge der Provider besitzt und welche in der autoritativen Zone der Organisation bleiben. Bewahren Sie frühere Werte und Rollback-Schritte auf. Vermeiden Sie für die produktive Identität eine From-Domain, die nur dem Provider gehört, denn das schwächt die Portabilität und kann DMARC-Alignment oder Markenkontinuität vom Anbieter abhängig machen. Testen Sie rohe empfangene Nachrichten über jeden Versandstrom und jede Umgebung.

Brauchbare Ergebnisse pro Empfänger verlangen

Der Dienst muss unterscheiden zwischen Annahme per SMTP oder API, Ablehnung pro Empfänger, vorübergehender Zurückstellung, dauerhaftem Fehler, späterem Bounce, Beschwerde, Abmeldung und Sperre durch den Provider. Prüfen Sie, wie diese Ergebnisse im kostenlosen Tarif geliefert, authentifiziert, wiederholt, geordnet, aufbewahrt und exportiert werden. Authentifizieren Sie Webhooks vor dem Parsen, setzen Sie Aktualitäts- und Replay-Kontrollen durch, speichern Sie Events dauerhaft vor der Bestätigung und ordnen Sie sie Versuchen zu, die der Anwendung gehören. Speichern Sie angenommene und abgelehnte Empfänger getrennt. Wiederholen Sie geeignete vorübergehende Fehler mit begrenztem Backoff, Jitter, Obergrenzen für Versuche und Altersgrenzen für die Warteschlange. Stoppen Sie automatische Sendungen nach dauerhaftem Adressfehler, Beschwerde oder Abmeldung für den jeweiligen Geltungsbereich. Ein Dashboard ohne exportierbare Belege erzeugt betrieblichen Lock-in. Ein Provider-Event „delivered“ beschreibt oft die Annahme durch den Zielserver, nicht den endgültigen Postfachordner. Öffnungen und Klicks sind Engagement-Messungen und können durch Datenschutztechnik verzerrt werden.

Limits prüfen, die nicht auf der Preisseite stehen

Preisseiten enthalten selten den gesamten betrieblichen Vertrag. Prüfen Sie in der aktuellen Dokumentation Empfängerzahl, Nachrichtengröße, Anhangsgröße, Verbindungsrate, gleichzeitige Sitzungen, API-Rate, DNS-Domains, Templates, Webhook-Versuche, Event-Aufbewahrung, Kapazität der Sperrliste und Empfängerbeschränkungen in der Testphase. Klären Sie, ob Support, Audit-Logs, dedizierte IPs, regionale Verarbeitung, Inbound-Routen oder Compliance-Funktionen kostenpflichtige Tarife erfordern. Testen Sie das tatsächliche Konto, denn neue Konten oder Testkonten können niedrigere Limits oder eine manuelle Prüfung haben. Erfassen Sie jedes Limit mit Quell-URL und Beobachtungsdatum. Planen Sie nicht exakt am Maximum; lassen Sie Spielraum für Provider-Änderungen, Wiederholungsversuche und die Wiederherstellung nach Vorfällen. Kann eine Anwendung ein Limit durch vom Nutzer gelieferte Empfänger-Arrays oder Anhänge unbemerkt überschreiten, setzen Sie zuerst eine strengere Produktgrenze durch. Behandeln Sie undokumentierte oder unklare Limits als Risiko, nicht als unbegrenzte Kapazität.

Datenschutz, Sicherheit und Missbrauchskontrollen bewerten

Erfassen Sie Nachrichteninhalte, Empfängerdaten, Header, Event-Payloads, IP-Adressen, Logs, Support-Zugriffe, Backups und Unterauftragsverarbeiter über alle Regionen hinweg. Minimieren Sie benutzerdefinierte Metadaten und vermeiden Sie Geheimnisse oder unnötige personenbezogene Daten in Tags und Headern. Klären Sie Aufbewahrung und Löschung für kostenlose Konten, auch nach der Kündigung. Prüfen Sie Mandantentrennung, rollenbasierten Zugriff, MFA, Audit-Historie, Rotation von Zugangsdaten, Webhook-Signierung, Autorisierung für Sperrlisten und Benachrichtigung bei Vorfällen. Testen Sie Header-Injection, beliebige Absenderwahl, übermäßige Empfängerzahlen, Missbrauch von Anhängen, mandantenübergreifende Event-Abfragen und Replay. Kostenlose Tarife sind häufige Ziele von Missbrauch, daher können Provider automatisierte Prüfungen oder schnelle Sperrungen verhängen; das Produkt braucht eine dauerhafte Warteschlange und einen sicheren Weg zum Pausieren. Umgehen Sie Missbrauchskontrollen niemals durch wechselnde Konten, Domains, Zugangsdaten oder IPs. Bewahren Sie Einwilligungs- und Sperrlistenstatus außerhalb des Providers auf, damit eine Sperrung oder Migration den Schutz der Empfänger nicht beseitigen kann.

Wechselkosten vor dem ersten Versand berechnen

Legen Sie Provider-spezifische Felder hinter einen Adapter und halten Sie das Event-Modell der Anwendung unabhängig. Inventarisieren Sie SMTP-Host und -Authentifizierung, API-Payloads, Templates, Absenderdomains, Return-Paths, DKIM-Selektoren, Webhooks, Event-Namen, Nachrichten-IDs, Tags, Sperrlisten, Inbound-Routen und Logs. Verlangen Sie Exporte der Sperrliste und der Betriebshistorie in Formaten, die das Produkt validieren kann. Eine Migration muss Schlüssel für Geschäftsereignisse, die Historie der Versuche, Einwilligungen, Empfängerschutz und Absenderinhaberschaft erhalten. Testen Sie einen zweiten Transport mit kontrollierten Identitäten, konfigurieren Sie ihn aber nicht als automatische Umgehung bei dauerhaften Empfänger- oder Richtlinienfehlern. Schätzen Sie Zeitfenster für DNS-Änderungen, Rotation von Zugangsdaten, Konvertierung von Templates, parallele Webhook-Verarbeitung, Vermeidung von Duplikaten und Aufbewahrung alter Events. Der günstigste kostenlose Tarif kann die falsche Wahl sein, wenn der Ausstieg bedeutet, Belege zu verlieren, die Absenderidentität zu ändern oder Sicherheitskontrollen unter dem Druck eines Vorfalls neu aufzubauen.

Vor dem Produktivbetrieb einen bewerteten Nachweis durchführen

Erstellen Sie eine repräsentative Testmatrix: TLS-Aushandlung und Zertifikatsfehler, Authentifizierung und Rotation, verifizierte und nicht autorisierte Absender, einfache und Multipart-Inhalte, Unicode, Anhänge, teilweise abgelehnte Empfänger, vorübergehende und dauerhafte Antworten, Timeout nach DATA, Bounces, Beschwerden, Abmeldungen, Webhook-Replay, Events in falscher Reihenfolge, ausgeschöpftes Kontingent, Tarifablauf, Export und Kontoschließung. Verwenden Sie eigene kontrollierte Empfänger und niemals echte Kundenlisten. Bewerten Sie Sicherheit, Korrektheit, Belege, Kapazität, Datenschutz, Support, Portabilität und Gesamtkosten getrennt. Blockieren Sie den Launch bei fehlender TLS-Verifizierung, gemeinsam genutzten Geheimnissen ohne Rotation, mandantenübergreifender Offenlegung, fehlender Behandlung dauerhafter Fehler, nicht verfügbarem Export der Sperrliste, stillen Mehrkosten oder unklarer Aufbewahrung. Wiederholen Sie den Nachweis, wenn sich ein Tarif, ein Versandpfad, eine Domain oder ein Provider-Vertrag ändert. Ein kostenloser Tarif kann für einen begrenzten Workload mit geringem Risiko angemessen sein – aber nur, wenn Kontrollen und Ausstiegsplan denselben Standard erfüllen, den man von einer kostenpflichtigen Abhängigkeit erwartet.

Aktuelle Tarife von SendHQ bewerten

SendHQ hat keinen kostenlosen Tarif. Neue Workspaces erhalten einen kontrollierten Integrationstest mit 100 Zustellungen an die Konto-E-Mail-Adresse oder eine AWS-SES-Simulator-Adresse. Aktuelle Preise, Kontingente und Funktionen kostenpflichtiger Tarife finden Sie auf der Preisseite von SendHQ.

Häufig gestellte Fragen

Ist ein kostenloser SMTP-Dienst für den Produktivbetrieb sicher?

Für einen begrenzten Workload kann er es sein – aber nur, wenn TLS, eingeschränkte Zugangsdaten, Absenderauthentifizierung, Empfängerschutz, Belege, Datenschutz, Kapazität, Support und Migration alle Prüfungen bestehen.

Was ist der Unterschied zwischen einem kostenlosen Tarif und einer Testphase?

Ein kostenloser Tarif ist ein dauerhaftes Kontingent zu den aktuellen Bedingungen; eine Testphase läuft ab oder verbraucht befristetes Guthaben. Prüfen Sie den aktuellen Vertrag und das Verhalten an der Obergrenze.

Welche Einheiten sollte ein Team vergleichen?

Vergleichen Sie Nachrichten, Empfänger, Bytes, Anhänge, Anfragen, Events, eingehende E-Mails, Logs, Aufbewahrung, Domains, Nutzer, Umgebungen, Support und das Verhalten bei Mehrverbrauch. Berechnen Sie jede Einheit für durchschnittliches Volumen, Spitzen, Wachstum, Wiederholungsversuche und Vorfälle.

Belegt die Annahme durch einen kostenlosen SMTP-Dienst die Zustellung?

Nein. Die Annahme ist eine Stufe beim Provider oder im Transport. Annahme durch den Empfängerserver, späterer Bounce, Postfachfilter, Platzierung im Posteingang und Interaktion durch Menschen bleiben eigene Ergebnisse.

Sollte ein Provider die einzige Sperrliste führen?

Nein. Pflegen Sie Einwilligungs- und Empfängerschutzstatus im eigenen Produkt, mit Belegen und Audit-Historie, damit eine Migration oder Sperrung den Schutz nicht beseitigen kann. Wenden Sie diesen Status unmittelbar vor jedem späteren Versandversuch an.

Wie sollte man mit einem ausgeschöpften Kontingent umgehen?

Stoppen Sie neue Aufträge oder stellen Sie sie je nach Ablaufzeit dauerhaft in eine Warteschlange, lösen Sie vor Erreichen der Obergrenze einen Alert aus und umgehen Sie Limits niemals durch wechselnde, nicht autorisierte Konten oder Identitäten.

Brauchen kostenlose Dienste SPF, DKIM und DMARC?

Die Absenderidentität braucht weiterhin korrekte Authentifizierung und korrektes Alignment. Ein kostenloser Tarif ändert nichts an den Standards der Empfänger, an der Domain-Inhaberschaft oder an der DNS-Sicherheit.

Hat SendHQ einen kostenlosen Tarif?

Nein. Neue Workspaces erhalten einen kontrollierten Integrationstest mit 100 Zustellungen an die Konto-E-Mail-Adresse oder eine AWS-SES-Simulator-Adresse.

Quellen

Weiterlernen

SMTP-Relay-Dienst bewertenBewerten Sie SMTP-Relay-Dienste nach Submission-Sicherheit, Authentifizierung, Warteschlangen, Retry-Verhalten, Limits, Zustell-Events, Sperrliste, Isolation und Eignung für die Migration.Google SMTP-Relay-Dienst bewerten: LeitfadenBewerten Sie das SMTP-Relay von Google Workspace nach Autorisierungsmodell, TLS, Absenderidentität, Kontingenten, Fehlerbehandlung, Authentifizierung, Observability und Migrationsrisiko.E-Mail-API integrieren: Leitfaden für ProduktteamsEntwerfen Sie eine sichere E-Mail-API-Integration mit verifizierten Domains, Versand über Warteschlangen, stabilen IDs, kontrollierten Wiederholungsversuchen, Zustell-Events, Sperrliste und Mandantentrennung.Zustellbarkeitsdienst für E-Mails bewertenBewerten Sie Zustellbarkeitsdienste nach Umfang, Belegen, Authentifizierung, Feedback-Loops, Sperrlisten, Datenschutz, Portabilität und betrieblicher Eignung.SMTP-Ports 25, 465 und 587: ein PraxisleitfadenWählen Sie den richtigen SMTP-Port nach Rolle und TLS-Modus und diagnostizieren Sie Fehler bei Verbindung, Handshake, Authentifizierung und Annahme der Nachricht.