레거시와 최신 시스템을 하나의 신뢰할 수 있는 릴레이로 유지
SMTP는 여전히 많은 앱, 플러그인, 내부 서비스에 가장 빠른 경로입니다. Sendarix는 명확한 로그와 이벤트 결과가 있는 프로덕션급 SMTP 처리를 제공합니다.
트랜잭션 트래픽, 알림 워크로드, 플랫폼 생성 메시지에 동일한 릴레이를 사용하고 일회성 취약 도구를 추가하지 마세요.
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.
실제 SMTP 운영을 위해 설계됨
단순 전달 계층이 아닙니다. 인증 지원, 대기열 규율, 운영 팀을 위한 관찰 가능성을 갖춘 제어된 발송 파이프라인입니다.
안전한 제출
자격 증명과 전송을 보호하는 SMTP AUTH 및 TLS 지원 제출 흐름.
처리량 안정성
버스트 트래픽과 일상 백그라운드 메일 워크로드에 일관된 성능.
가시성 및 로그
검색 가능한 로그와 이벤트 수준 추적으로 전달 결과를 빠르게 조사합니다.
원활한 마이그레이션
즉각적인 전체 아키텍처 재작성 없이 기존 SMTP 제공업체에서 이전합니다.
전용 발송 신원
엔터프라이즈 메일 요구에 맞는 인증 도메인 및 발신자 정책을 사용합니다.
대기열 인식 신뢰성
제어된 대기열 및 재시도 동작으로 급증 시에도 전달 일관성을 보호합니다.
SMTP 릴레이 흐름
인프라를 예측 가능하고 디버깅 가능하게 유지하는 명확한 4단계 흐름.
1. 연결
애플리케이션이 SMTP 자격 증명으로 연결하고 보안 세션을 설정합니다.
2. 수락
메시지가 검증되고 제어 처리를 위해 대기열에 수락됩니다.
3. 라우팅
복원력과 제공업체 인식 동작으로 전달 경로를 통해 트래픽이 라우팅됩니다.
4. 추적
결과 이벤트와 로그가 운영 신뢰와 더 빠른 문제 해결을 제공합니다.
Real-World Scenario: Legacy System Integration
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.
SMTP Command Flow
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.
Example SMTP 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
SMTP Response Code Reference
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)
Authentication and TLS Configuration
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 Mechanisms
SMTP AUTH has several mechanisms. PLAIN and LOGIN are the most widely supported:
AUTH PLAIN
Sends credentials as a single base64-encoded string: [authzid]\0username\0password. Safe over TLS. Do not use over plain HTTP.
AUTH LOGIN
Two-step challenge-response: username prompt then password prompt. Base64-encoded at each step. Also requires TLS.
AUTH XOAUTH2 (OAuth 2.0)
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.
Recommended Configuration
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.
TLS Configuration
smtp_relay.tls_opportunistic_h4
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.
Implicit TLS (SMTPS on 465)
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.
Certificate Verification
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.
SMTP TLS Pinning
For high-security applications, you can pin the Sendarix leaf certificate. Monitor certificate rotation announcements and update pinned certificates before expiration.
Provider-Specific Behavior: Gmail vs Outlook
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 (Google Workspace / Gmail)
Authentication Requirements
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.
Rate Limits
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.
TLS Requirements
Gmail requires TLS for all inbound connections. Sending plaintext to Gmail is rejected at the MTA level. Sendarix enforces TLS for all major providers.
Bounce Behavior
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.
Spam Filtering Signals
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 Outlook / Microsoft 365
Authentication Requirements
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.
Rate Limits
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.
TLS Requirements
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.
Bounce Behavior
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.
Complaint Handling
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.
Junk Folder Placement
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.
SMTP Relay Failover Architecture
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.
Failover Levels
Connection-Level Failover
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.
IP-Level Failover
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.
Provider-Level 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.
Region-Level Failover
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.
DNS-Based Failover
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.
Testing Failover Behavior
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.
Common SMTP Relay Use Cases
SMTP relay is the right choice when you need broad compatibility, existing tool integration, or transactional workload handling without API changes.
Legacy Application Integration
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 / CMS Notification Mail
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.
CI/CD Pipeline Notifications
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.
Internal Service Alerts
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 Multi-Tenant Notification Sending
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.
E-Commerce Order Confirmations
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.
Ready to Route Email Through Production Infrastructure?
Get SMTP credentials and start sending in minutes. No architecture changes required.
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.
Related SMTP Configuration Guides
Step-by-step SMTP configuration for the most common email providers and platforms. Each guide covers host, port, encryption, authentication, and provider-specific behavior.
Gmail SMTP Settings
smtp.gmail.com · port 587 · TLS · App passwords
Outlook SMTP Configuration
smtp-mail.outlook.com · port 587 · TLS · OAuth
Yahoo SMTP Settings
smtp.mail.yahoo.com · port 587 · TLS · App password
Office 365 SMTP Setup
smtp.office365.com · port 587 · TLS · OAuth2
Zoho Mail SMTP Settings
smtp.zoho.com · port 587 · TLS · SMTP auth
iCloud SMTP Configuration
smtp.mail.me.com · port 587 · TLS · App password
Proton Mail SMTP Settings
smtp.protonmail.com · port 587 · TLS · Bridge
Yandex SMTP Configuration
smtp.yandex.com · port 587 · TLS · SMTP pass
GMX SMTP Settings
smtp.gmx.com · port 587 · TLS · App password
FastMail SMTP Configuration
smtp.fastmail.com · port 587 · TLS · App password
SendGrid SMTP Settings
smtp.sendgrid.net · port 587 · TLS · API key
Mailgun SMTP Configuration
smtp.mailgun.org · port 587 · TLS · SMTP credentials
Postmark SMTP Settings
smtp.postmarkapp.com · port 587 · TLS · Server token
Amazon SES SMTP Configuration
email-smtp.*.amazonaws.com · port 587 · TLS · SMTP credentials
Mailchimp Mandrill SMTP Settings
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.
자주 묻는 질문
SMTP로 시작했다가 나중에 API로 옮길 수 있나요?
예. 많은 팀이 속도를 위해 SMTP로 시작한 뒤 더 깊은 제품 워크플로를 위해 API 엔드포인트를 추가합니다.
전달 수준 가시성을 받을 수 있나요?
예. 로그와 이벤트 스트림을 사용해 수락, 전달, 바운스 결과를 확인할 수 있습니다.
대량 발송에 적합한가요?
예. 릴레이는 프로덕션 플랫폼에서 흔한 지속 트래픽과 버스트 이벤트를 위해 구축되었습니다.
어떤 포트와 암호화를 사용해야 하나요?
대부분의 프로덕션 클라이언트는 STARTTLS가 있는 587 제출 또는 465의 암시적 TLS를 사용합니다. 공용 네트워크에서 평문 SMTP는 피하세요.
SMTP를 알려진 IP로 제한할 수 있나요?
예. IP 허용 목록은 일반적인 엔터프라이즈 제어입니다. 애플리케이션 서버, VPN 이그레스 또는 MTA 함대만 릴레이에 인증할 수 있습니다.
앱에서 인증 자격 증명은 어떻게 다루나요?
SMTP 자격 증명을 비밀 관리자에 보관하고, 인력 변경 시 순환하며, 소스 제어에 커밋하지 마세요. 환경별 자격 증명을 권장합니다.
이메일마다 새 SMTP 연결을 열면 전달성에 해가 되나요?
과도한 연결 churn은 지연과 부하를 추가할 수 있습니다. 스택이 허용하면 연결을 책임감 있게 재사용하고 문서화된 속도 및 동시성 지침을 따르세요.
레거시 CRM과 프린터가 동일한 SMTP 릴레이를 사용할 수 있나요?
종종 예. SMTP는 오래된 시스템의 공통 분모입니다. 플랜이 지원하는 경우 도메인, 헤더 또는 하위 계정으로 스트림을 분할할 수 있습니다.
메시지 크기와 첨부 한도는 어떻게 되나요?
큰 페이로드는 실패 위험과 처리 시간을 늘립니다. 플랜 한도를 확인하고 첨부가 무거우면 외부 호스팅 후 이메일에 링크를 고려하세요.
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.
