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.
Usa lo stesso relay per traffico transazionale, carichi di notifica e messaggi generati dalla piattaforma senza aggiungere strumenti ad hoc fragili.
SMTP sessions flow through authentication, TLS, and routing enforcement before acceptance. The relay handles throttling, deferrals, and failover while delivery events are tracked via email webhooks and email analytics.
Non è un semplice inoltro. È una pipeline di invio controllata con supporto autenticazione, disciplina di coda e osservabilità per i team operativi.
SMTP AUTH e flussi di submission compatibili TLS per credenziali e trasporto protetti.
Prestazioni coerenti per picchi di traffico e posta giornaliera in background.
Analizza rapidamente gli esiti di consegna con log ricercabili e tracciamento a livello evento.
Passa da vecchi provider SMTP senza forzare una riscrittura completa immediata dell'architettura.
Usa domini autenticati e policy mittente allineate ai requisiti e-mail enterprise.
Proteggi la coerenza della consegna durante i picchi con accodamento e retry controllati.
Un flusso chiaro in 4 passi per mantenere l'infrastruttura prevedibile e debuggabile.
L'applicazione si connette con credenziali SMTP e stabilisce una sessione sicura.
Il messaggio viene validato e accettato in coda per elaborazione controllata.
Il traffico viene instradato con resilienza e comportamento consapevole del provider.
Eventi di esito e log forniscono fiducia operativa e troubleshooting più rapido.
An internal system sends scheduled reports via SMTP. The relay authenticates with credentials, processes the message through spam filtering, and delivers it via email routing with TLS enforcement. If the destination server is temporarily unreachable, the retry logic queues the message and delivers it on recovery, with status tracked via email webhooks.
Understanding the actual SMTP protocol exchange helps when debugging delivery issues and interpreting bounce codes. Below is a complete example of a typical message submission session.
This shows a full session from connection through message acceptance. Replace example.com with your verified sending domain.
S: 220 mail.sendarix.com ESMTP ready
C: EHLO mail.yourapp.com
S: 250-mail.sendarix.com
250-PIPELINING
250-SIZE 52428800
250-8BITMIME
250-STARTTLS
250-AUTH PLAIN LOGIN
250 CHUNKING
C: AUTH PLAIN dXNlcm5hbWUAdXNlcm5hbWUAYWQhZGFzZDhzNG
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<notifications@yoursenddomain.com>
S: 250 2.1.0 OK
C: RCPT TO:<user@example.com>
S: 250 2.1.5 OK
C: DATA
S: 354 Start mail input; end with CRLF.CRLF
C: (message headers and body)
C: .
S: 250 2.0.0 OK: queued as abc123
C: QUIT
S: 221 2.0.0 Goodbye
220
— Service ready (greeting)
235
— Auth successful
250
— Message accepted
354
— Ready for DATA
421
— Try again later
450
— Mailbox temp unavailable
451
— Local error
452
— Storage full
550
— User unknown (hard bounce)
552
— Message too large
554
— Transaction failed (spam/policy)
Sendarix supports both SMTP AUTH for credential-based submission and TLS for transport encryption. Proper configuration is required for reliable delivery and to avoid intermediate network interception.
SMTP AUTH has several mechanisms. PLAIN and LOGIN are the most widely supported:
Sends credentials as a single base64-encoded string: [authzid]\0username\0password. Safe over TLS. Do not use over plain HTTP.
Two-step challenge-response: username prompt then password prompt. Base64-encoded at each step. Also requires TLS.
OAuth 2.0 based SASL mechanism for applications using OAuth tokens instead of passwords. Preferred for SaaS platforms where users authorize sending on their own domains.
For most applications: use port 587 with STARTTLS and AUTH PLAIN. Reserve port 465 for legacy clients that cannot upgrade. Never transmit AUTH credentials on plaintext connections.
Connection starts unencrypted on port 587, then upgrades via STARTTLS command after EHLO. If the remote server does not advertise STARTTLS, the connection is rejected — Sendarix never sends credentials over plaintext.
Connection is encrypted from the TCP handshake. No STARTTLS upgrade needed. Preferred by enterprise clients and some legacy systems. Sendarix supports TLS 1.2 and 1.3 with modern cipher suites.
Sendarix presents a certificate signed by a known CA. Your SMTP client should verify the certificate chain against trusted root CAs. Disable certificate verification only in controlled test environments.
For high-security applications, you can pin the Sendarix leaf certificate. Monitor certificate rotation announcements and update pinned certificates before expiration.
Gmail and Outlook (Microsoft) handle SMTP submission, rate limits, and spam filtering differently. Understanding these differences helps you tune your integration and interpret delivery failures accurately.
Gmail requires SPF, DKIM, and DMARC all aligned for reliable inbox delivery. Messages failing DKIM signing or showing alignment failures are routed to spam or rejected. Sendarix DKIM signs all outbound mail from verified domains.
Gmail enforces per-IP and per-user sending limits. Standard limits: 500 emails/recipient/day, 2000 emails/day per account for consumer Gmail, 2000 emails/minute for Workspace accounts. Exceeding limits returns 421 or 550 errors temporarily.
Gmail requires TLS for all inbound connections. Sending plaintext to Gmail is rejected at the MTA level. Sendarix enforces TLS for all major providers.
Gmail returns 550 for hard bounces (invalid user) and 421 with retry for temporary issues. Soft bounces that persist across multiple delivery attempts convert to hard bounces internally and are suppressed from future sends.
Gmail's ML-based spam filter evaluates sender history, engagement rates, content patterns, and authentication status. Low engagement (many marked as spam) degrades future delivery. Sending to engaged recipients consistently improves inbox placement.
Microsoft requires SPF, DKIM (Microsoft-specific selector), and DMARC alignment. They also evaluate sender reputation via postmaster services and Smart Network Services (sns.oregon.trafficmanager.net). Without proper authentication, messages are filtered or rejected.
Microsoft enforces limits per tenant and per IP: 30,000 emails/day for standard tenants, higher for premium. Per-minute limits vary by tenant age and reputation. Exceeding limits returns 421 and queues messages for retry.
Microsoft requires TLS 1.2+ for all inbound mail. They support TLS 1.3 and prefer it. Plaintext connections are rejected. Microsoft also enforces certificate validation — self-signed certs will fail.
Microsoft uses enhanced bounce codes: 550 5.1.1 (unknown user), 550 5.1.2 (bad destination), 550 5.2.1 (mailbox unavailable). They also use 250 OK with diagnostic codes in the message headers for soft failures.
Microsoft reports complaints via Feedback Loop (FBL) integration. Messages marked as spam by recipients trigger complaint events in Sendarix. High complaint rates trigger Microsoft's "data fix" process, temporarily blocking your IP until reputation is restored.
Outlook uses Exchange Online Protection (EOP) with multiple filtering layers: connection filtering, policy filtering, and content filtering. Sending volume patterns, list hygiene, and engagement history all influence junk folder placement.
Sendarix implements multi-layer failover to ensure message acceptance even during infrastructure and provider-level outages. The failover hierarchy operates automatically with no manual intervention required.
When the primary SMTP endpoint returns connection errors, timeouts, or 421 retry responses, traffic immediately routes to the next available endpoint in the pool. Connection failures are detected within 5 seconds and failover initiates within 10 seconds.
If a specific sending IP is rate-limited or reputation-blocked at a destination provider, that IP is automatically deprioritized and traffic shifts to alternative IPs in the same reputation tier. Warmup status is respected — cold IPs do not receive production traffic during failover.
When a destination provider (e.g., Gmail API ingestion) is unavailable, messages queue locally and retry at increasing intervals. The queue is durable — messages are not lost during extended provider outages. Queue depth is visible in the Sendarix dashboard.
For enterprise configurations with multi-region sending, regional endpoints in different data centers handle traffic independently. DNS-based routing directs submission to the nearest available region.
MX records for your sending domain point to clustered ingress nodes. Sendarix manages DNS failover automatically — no manual DNS updates required when a node fails. TTL is set to 60 seconds to allow fast failover while maintaining stability.
Sendarix provides sandbox endpoints for testing failover without affecting production reputation. Use the sandbox to simulate connection failures, 421 responses, and timeout conditions to verify your application handles relay failover gracefully.
SMTP relay is the right choice when you need broad compatibility, existing tool integration, or transactional workload handling without API changes.
Applications built before modern email APIs existed often have built-in SMTP configuration. Sendarix relay replaces old provider credentials without requiring code changes. Update SMTP host, port, username, and password to start sending.
WordPress, Drupal, and other CMS platforms send email via the server's configured SMTP relay. Installing an SMTP plugin and pointing it to Sendarix routes all notification, registration, and contact form emails through production infrastructure.
Jenkins, GitLab CI, GitHub Actions, and similar tools send build status, deployment alerts, and run reports via SMTP. Configure the CI tool's SMTP settings to Sendarix to route these reliably and avoid alerts going to spam.
Monitoring tools (Datadog, PagerDuty, Prometheus Alertmanager), cron job failures, and system health checks often rely on email for critical notifications. Sendarix relay ensures these important alerts reach the on-call engineer's inbox.
SaaS platforms sending notifications on behalf of their customers (appointment reminders, order updates, account alerts) can segment traffic by customer tenant using subaddresses or header-based routing. Each tenant gets isolated reputation management.
Order confirmation, shipping update, and delivery notification emails are critical transactional messages that drive customer engagement. SMTP relay integration with e-commerce platforms (Shopify, WooCommerce, Magento) ensures these emails land in the inbox reliably.
Get SMTP credentials and start sending in minutes. No architecture changes required.
Team di ingegneria che gestiscono stack misti, piattaforme SaaS con componenti mail legacy e operazioni che necessitano SMTP affidabile senza punti ciechi.
Quando sei pronto, combina SMTP con API e-mail e webhook per logica prodotto guidata dagli eventi.
What sets Sendarix apart: Sendarix SMTP relay runs on the same routing infrastructure as the email API — meaning you get failover, routing rules, and analytics without choosing between SMTP compatibility and modern email infrastructure control.
Step-by-step SMTP configuration for the most common email providers and platforms. Each guide covers host, port, encryption, authentication, and provider-specific behavior.
smtp.gmail.com · port 587 · TLS · App passwords
smtp-mail.outlook.com · port 587 · TLS · OAuth
smtp.mail.yahoo.com · port 587 · TLS · App password
smtp.office365.com · port 587 · TLS · OAuth2
smtp.zoho.com · port 587 · TLS · SMTP auth
smtp.mail.me.com · port 587 · TLS · App password
smtp.protonmail.com · port 587 · TLS · Bridge
smtp.yandex.com · port 587 · TLS · SMTP pass
smtp.gmx.com · port 587 · TLS · App password
smtp.fastmail.com · port 587 · TLS · App password
smtp.sendgrid.net · port 587 · TLS · API key
smtp.mailgun.org · port 587 · TLS · SMTP credentials
smtp.postmarkapp.com · port 587 · TLS · Server token
email-smtp.*.amazonaws.com · port 587 · TLS · SMTP credentials
smtp.mandrillapp.com · port 587 · TLS · API key
All SMTP configuration guides include provider-specific details for authentication methods, rate limits, TLS requirements, and bounce handling behavior. These guides complement the email routing controls available in your Sendarix dashboard.
Sì. Molti team iniziano con SMTP per velocità, poi aggiungono endpoint API per flussi prodotto più profondi.
Sì. Log e flussi di eventi consentono di ispezionare esiti accettato, consegnato e rimbalzato.
Sì. Il relay è costruito per traffico sostenuto e picchi tipici delle piattaforme in produzione.
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.
Sì. La whitelist IP è un controllo enterprise comune: solo server applicativi, uscita VPN o flotta MTA possono autenticarsi.
Conserva le credenziali SMTP in un gestore di segreti, ruotale quando cambia il personale e non committarle mai. Preferisci credenziali per ambiente.
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.
Spesso sì. SMTP è il denominatore comune; puoi segmentare quei flussi con domini, header o subaccount dove il piano lo supporta.
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.
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.
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.
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.
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.
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.
Iniziate gratis senza carta o parlate con il commerciale per volumi elevati e enterprise.
Inizia a inviareParla con il commerciale