Route · SMTP Relay
SMTP relay
SMTP resta spesso il percorso più veloce per molte app, plugin e servizi interni. Sendarix offre gestione SMTP di livello produzione con log chiari ed esiti di evento.
# Invia un’email critica tramite routing policy 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" });
# SMTP drop-in — mantieni l’integrazione e ottieni un control plane host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Un relay per ogni stack
Mantieni sistemi legacy e moderni su un relay affidabile
Usa lo stesso relay per traffico transazionale, carichi di notifica e messaggi generati dalla piattaforma senza aggiungere strumenti ad hoc fragili.
UI prodotto rappresentativa — dati illustrativi, non metriche live dei clienti.
Progettato per operazioni SMTP reali
Non è un semplice inoltro. È una pipeline di invio controllata con supporto autenticazione, disciplina di coda e osservabilità per i team operativi.
Invio sicuro
SMTP AUTH e flussi di submission compatibili TLS per credenziali e trasporto protetti.
Stabilità del throughput
Prestazioni coerenti per picchi di traffico e posta giornaliera in background.
Visibilità e log
Analizza rapidamente gli esiti di consegna con log ricercabili e tracciamento a livello evento.
Migrazione fluida
Passa da vecchi provider SMTP senza forzare una riscrittura completa immediata dell'architettura.
Identità di invio dedicata
Usa domini autenticati e policy mittente allineate ai requisiti e-mail enterprise.
Affidabilità consapevole della coda
Proteggi la coerenza della consegna durante i picchi con accodamento e retry controllati.
Flusso SMTP relay
Un flusso chiaro in 4 passi per mantenere l'infrastruttura prevedibile e debuggabile.
1. Connessione
L'applicazione si connette con credenziali SMTP e stabilisce una sessione sicura.
2. Accettazione
Il messaggio viene validato e accettato in coda per elaborazione controllata.
3. Instradamento
Il traffico viene instradato con resilienza e comportamento consapevole del provider.
4. Tracciamento
Eventi di esito e log forniscono fiducia operativa e troubleshooting più rapido.
Domande frequenti
Possiamo iniziare con SMTP e passare all'API dopo?
Sì. Molti team iniziano con SMTP per velocità, poi aggiungono endpoint API per flussi prodotto più profondi.
Abbiamo visibilità a livello di consegna?
Sì. Log e flussi di eventi consentono di ispezionare esiti accettato, consegnato e rimbalzato.
È adatto all'invio ad alto volume?
Sì. Il relay è costruito per traffico sostenuto e picchi tipici delle piattaforme in produzione.
Quali porte e crittografia usare?
La maggior parte dei client in produzione usa submission sulla porta 587 con STARTTLS, o TLS implicito sulla 465. Evita SMTP in chiaro su reti pubbliche.
Possiamo limitare SMTP a IP noti?
Sì. La whitelist IP è un controllo enterprise comune: solo server applicativi, uscita VPN o flotta MTA possono autenticarsi.
Come gestire le credenziali di autenticazione nelle app?
Conserva le credenziali SMTP in un gestore di segreti, ruotale quando cambia il personale e non committarle mai. Preferisci credenziali per ambiente.
Aprire una nuova connessione SMTP per ogni e-mail danneggia la deliverability?
Un eccesso di connessioni/disconnessioni può aggiungere latenza e carico. Riutilizza le connessioni in modo responsabile e segui le linee guida documentate su rate e concorrenza.
CRM legacy e stampanti possono usare lo stesso relay?
Spesso sì. SMTP è il denominatore comune; puoi segmentare quei flussi con domini, header o subaccount dove il piano lo supporta.
E dimensione messaggi e limiti allegati?
Payload grandi aumentano rischio di fallimento e tempo di elaborazione. Controlla i limiti del piano e considera hosting file esterni con link nell'e-mail quando gli allegati sono pesanti.
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.
Guide di configurazione SMTP
Prodotti correlati
Protege email crítico en cada tenant.
Mueve tu stream más crítico a Sendarix esta semana. Deja todo lo demás exactamente donde está.
