Route · SMTP Relay
SMTP Relay
SMTP ist für viele Apps, Plugins und interne Services noch der schnellste Weg. Sendarix liefert SMTP auf Produktionsniveau mit klaren Logs und Ereignis-Ergebnissen.
# Kritische E-Mail über eine Routing-Policy senden curl -sS -X POST 'https://app.sendarix.com/v1/email/send' \ -H 'Content-Type: application/json' \ -H 'X-API-Key: YOUR_API_KEY' \ -H 'Idempotency-Key: otp_8842' \ -d '{"to":"user@acme.com","template":"password_reset","routing_policy":"transactional-critical"}'
const sendarix = require("sendarix")(process.env.SENDARIX_KEY); await sendarix.email.send({ to: "user@acme.com", template: "password_reset", routingPolicy: "transactional-critical", idempotencyKey: "otp_8842" });
# Drop-in SMTP — Integration behalten, Control Plane gewinnen host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Ein Relay, jeder Stack
Legacy und moderne Systeme auf einem zuverlässigen Relay
Nutzen Sie dasselbe Relay für transaktionalen Traffic, Benachrichtigungen und plattformgenerierte Nachrichten – ohne fragile Einzellösungen.
Repräsentative Produkt-UI — Beispieldaten, keine Live-Kundenmetriken.
Für echte SMTP-Betriebsabläufe
Das ist keine einfache Weiterleitung, sondern eine kontrollierte Versand-Pipeline mit Authentifizierung, Queue-Disziplin und Observability für Operations-Teams.
Sichere Einlieferung
SMTP AUTH und TLS-fähige Submission für geschützte Credentials und Transport.
Durchsatz-Stabilität
Konstante Performance bei Bursts und täglichem Hintergrund-Mail.
Sichtbarkeit & Logs
Zustell-Ergebnisse schnell prüfen mit durchsuchbaren Logs und Event-Tracking.
Reibungslose Migration
Wechsel von alten SMTP-Providern ohne sofortigen kompletten Architektur-Umbau.
Dedizierte Versand-Identität
Authentifizierte Domains und Absender-Richtlinien passend zu Enterprise-Mail-Anforderungen.
Queue-bewusste Zuverlässigkeit
Konsistente Zustellung bei Spitzen durch kontrolliertes Queueing und Retry-Verhalten.
SMTP-Relay-Ablauf
Ein klarer 4-Schritte-Ablauf für planbare, debuggbare Infrastruktur.
1. Verbinden
Anwendung verbindet sich per SMTP-Credentials und baut eine sichere Session auf.
2. Akzeptieren
Nachricht wird validiert und in die Queue für kontrollierte Verarbeitung übernommen.
3. Routen
Traffic wird über Zustellpfade mit Resilienz und providerbewusstem Verhalten geroutet.
4. Verfolgen
Ergebnis-Events und Logs geben operative Sicherheit und schnellere Fehlersuche.
Häufig gestellte Fragen
Können wir mit SMTP starten und später zur API wechseln?
Ja. Viele Teams beginnen mit SMTP für Geschwindigkeit und ergänzen API-Endpunkte für tiefere Produkt-Workflows.
Erhalten wir Sichtbarkeit auf Zustell-Ebene?
Ja. Logs und Event-Streams zeigen akzeptiert, zugestellt und gebounct.
Eignet sich das für hohes Versandvolumen?
Ja. Das Relay ist für dauerhaften Traffic und typische Produktions-Bursts ausgelegt.
Welche Ports und Verschlüsselung sollten wir nutzen?
Die meisten Produktions-Clients nutzen Submission auf Port 587 mit STARTTLS oder implizites TLS auf 465. Vermeiden Sie Klartext-SMTP in öffentlichen Netzen.
Können wir SMTP auf bekannte IP-Adressen beschränken?
Ja. IP-Allowlisting ist eine gängige Enterprise-Kontrolle: nur Ihre App-Server, VPN-Egress oder MTA-Flotte authentifizieren sich am Relay.
Wie sollten wir SMTP-Credentials in Apps handhaben?
Speichern Sie SMTP-Credentials in einem Secrets Manager, rotieren Sie sie bei Personalwechsel und committen Sie sie nie ins Repository. Bevorzugen Sie Credentials pro Umgebung.
Schadet es der Deliverability, für jede E-Mail eine neue SMTP-Verbindung zu öffnen?
Zu viel Connect-Churn erhöht Latenz und Last. Wo Ihr Stack es erlaubt, Verbindungen sinnvoll wiederverwenden und dokumentierte Rate- und Concurrency-Vorgaben befolgen.
Können Legacy-CRMs und Drucker dasselbe SMTP-Relay nutzen?
Oft ja. SMTP ist der kleinste gemeinsame Nenner für ältere Systeme; Sie können Streams per Domains, Headern oder Subaccounts segmentieren, wo Ihr Plan das unterstützt.
Wie ist es mit Nachrichtengröße und Anhängen?
Große Payloads erhöhen Fehlerrisiko und Verarbeitungszeit. Prüfen Sie Plan-Limits und hosten Sie schwere Dateien extern mit Links in der E-Mail.
What is the difference between port 587 and port 465?
Port 587 uses STARTTLS (opportunistic TLS upgrade after CONNECT), while port 465 uses implicit TLS where the connection is encrypted from the start. Both are valid for secure submission. Port 587 is the RFC-compliant standard for message submission; port 465 is deprecated but still widely supported for legacy clients.
How does Sendarix handle greylisting?
When a destination provider returns a 450 or 451 temporary response, Sendarix respects the retry period specified in the SMTP response. Most providers implement greylisting for 30 seconds to 10 minutes. Sendarix tracks these windows and retries within the provider's specified interval to maximize first-attempt success.
What is the maximum message size via SMTP?
Default maximum message size is 50MB including attachments and MIME encoding. For files larger than 25MB, Sendarix recommends uploading to cloud storage and sending a signed link instead. Some providers reject messages over 25MB entirely, regardless of SMTP acceptance.
Can we use subaddressing (user+tag@example.com) with Sendarix?
Yes. Subaddressing is fully supported and passed through to destination mail servers. The plus-address portion is visible to receiving MTA filters and can be used for routing, tagging, or filtering rules on the recipient side.
How do we verify our sending domain with Sendarix?
Domain verification requires adding DKIM records to your DNS. Sendarix provides a DKIM public key pair during setup. Add the TXT record to your domain's DNS, then Sendarix validates the record propagates before signing outgoing mail on your behalf.
SMTP-Setup-Guides
Verwandte Produkte
Schützen Sie kritische E-Mail über jeden Tenant hinweg.
Verschieben Sie diese Woche Ihren kritischsten Stream zu Sendarix. Alles andere bleibt genau dort, wo es ist.
