SocketLabs SMTP Settings and Configuration (2026)
Native SMTP relay, no add-on required
SocketLabs runs a first-class customer-facing relay at smtp.socketlabs.com and accepts connections on ports 25, 2525, 587 and 465. Credentials are self-service from the control panel. SMTP sits on equal footing with the HTTP Injection API rather than behind a paid upgrade.
SocketLabs treats SMTP as a primary send path rather than a legacy compatibility layer. The help center ships first-party setup guides for Postfix, Sendmail, Exchange 2010 through 2019, the IIS SMTP virtual server, cPanel/Exim, WordPress, Drupal, Thunderbird and Outlook, which makes it a natural fit for on-premise estates that cannot be rewritten against an HTTP API. Paid plans start at $39.95/month for 40,000 emails with $0.00130 per email overage, and there is no permanent free tier, only a one-month Core trial. If you need a lower-commitment relay for a small transactional stream, compare with Postmark, SendGrid and Mailgun first. One caveat belongs at the top rather than buried: Infobip completed its acquisition of SocketLabs on July 9, 2026 and has published nothing since about brand, pricing or roadmap.
Quick reference
| SMTP server | smtp.socketlabs.com |
| Port · STARTTLS | 587 RECOMMENDED |
| Port · implicit SSL | 465 – requires implicit SSL, not STARTTLS |
| Alternative ports | 25 and 2525 – both also accept STARTTLS |
| Username | Issued, not chosen. Documented form server12345 – the word server plus your numeric Server ID |
| Password | Generated string from Configuration › SMTP Credentials (Key Manager). Not the Injection API key |
SocketLabs does not pin a stable IP for the relay: the docs say the address behind smtp.socketlabs.com changes frequently because the service runs geographically distributed servers, and instruct firewall admins to allow the CIDR range 142.0.176.0/20 rather than a resolved A record. Full detail in the official SMTP connections reference.
SMTP configuration
SocketLabs outbound relay
Transactional and bulk outbound mail from applications, MTAs, control panels and desktop clients.
smtp-cx.socketlabs.com, is returned by the v2 subaccount credential endpoint. Use whichever was issued with your credential.Setup steps
- Add and verify your sending domain first. Unverified domains are rejected at SMTP time with
554 5.1.0 The Sender's Address Was Not Allowed. - Open Configuration › SMTP Credentials (Key Manager) and generate or reveal the username and password for the server you will send from.
- Point your client, MTA or plugin at smtp.socketlabs.com on port 587 with STARTTLS. Use 465 only for implicit SSL, 2525 only if outbound 587 is blocked.
- Enter the issued username and password. Do not paste the Injection API key here, it is a different credential and returns
501 5.7.0. - Send a test message and confirm it in the control panel reporting view before cutting production traffic over, keeping concurrency at or below 20 connections.
Authentication
SocketLabs takes an unusual approach: it never asks you to edit your existing SPF record. Alignment comes from a custom bounce domain that places the Return-Path under a subdomain of yours, CNAMEd into infrastructure whose SPF SocketLabs maintains. Domain verification is mandatory before any mail leaves the platform.
SPF and DKIM setup
There is no published include: mechanism for SocketLabs; treat any third-party blog offering one as unverified. The official path is two CNAME records: one for DKIM signing, one serving as both the custom bounce (Return-Path) domain and the engagement tracking domain.
; DKIM signing - single documented selector "dkim" dkim._domainkey.yourdomain.com. IN CNAME dkim._domainkey.email-od.com. ; Custom bounce domain + engagement tracking (one record serves both) email.yourdomain.com. IN CNAME tracking.socketlabs.com. ; White-labelled sub-client chaining, as documented bounces.customerexample.com. IN CNAME email.yourdomain.com.
Three details catch people out. The DKIM target sits on email-od.com, the legacy “Email On Demand” domain, not socketlabs.com. Only the selector dkim is documented, so rotation is not available. And if your DNS provider refuses underscores in CNAME hostnames, SocketLabs directs you to its TXT-based Advanced DKIM feature. Allow 24-48 hours for propagation. See the official DKIM signing guide and custom bounce domains guide.
Verification has two routes. The email route mails an authentication code to an address on the domain: quick, but it leaves you without DKIM or a custom Return-Path. The DNS route requires at least one of custom bounce domain, DKIM signature or engagement tracking, and is the only one that produces a properly authenticated setup.
DMARC alignment
SocketLabs does not prescribe a DMARC record and does not host one for you. That is not an omission to work around, the documented architecture already gives you both alignment legs. DKIM signs with d= your own domain, and the custom bounce domain puts the Return-Path on a subdomain of your organizational domain, so SPF aligns in relaxed mode. With both records live, p=quarantine or p=reject is achievable without any SocketLabs-specific exception.
; Publish this yourself - SocketLabs does not supply it _dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r"
Start at p=none with aggregate reporting, confirm SocketLabs traffic shows DKIM pass with your own domain in d= and the Return-Path on your bounce subdomain, then tighten. If you add only DKIM and skip the bounce domain, SPF authenticates against a SocketLabs-controlled domain and will not align. DMARC still passes on DKIM alone, but you lose the redundancy that keeps you delivering when a forwarder breaks a signature.
Rate limits & sending caps
| Limit | Value | Behaviour when exceeded |
|---|---|---|
| Maximum message size | 40 MB total | 552 5.3.4 Message too big for system |
| Recipients per message | 500 | Message rejected, split the recipient list |
| Simultaneous SMTP connections | 20 per account | 421 4.4.5 Too many connections from your host |
| Messages per connection | 50 recommended | No hard error, throughput guidance, pair with pipelining |
| Hourly or per-minute send ceiling | Not published | New accounts carry an unquantified warm-up throttle |
The first four rows are hard, published numbers. The fifth is the one that surprises migrations: SocketLabs throttles new accounts during warm-up without stating the figure, lifts it automatically as mailbox providers become familiar with your domain and IP pairing, and prolongs it when complaint or bounce rates run high. The docs say outright that the throttle is unnecessary for some businesses and can be adjusted by support ticket. If you are moving an established high-volume stream, open that ticket before cutover rather than after your queue backs up. Commercial volume is enforced by monthly allowance plus overage, not by an hourly cap, so plan sizing and throughput are separate conversations.
Common setup gotchas
Three credentials coexist and none of them substitutes for another
SocketLabs issues an SMTP username and password pair, an Injection API credential (numeric serverId plus APIKey, what every SDK constructor takes), and a bearer token for the v2 management API. They are generated separately and are not interchangeable. The most common failure is pasting an Injection API key into an SMTP password field, which returns 501 5.7.0 Authentication failed. User name or password is invalid. Before debugging TLS or ports, confirm the credential came from Configuration › SMTP Credentials and nowhere else.
The DKIM CNAME points at email-od.com, and your DNS reviewer will question it
The documented record delegates dkim._domainkey.yourdomain.com to dkim._domainkey.email-od.com. That target is a legacy SocketLabs domain, and security reviewers routinely flag it as an unexplained third-party delegation, sometimes removing it, which kills DKIM signing silently, with no bounce and no alert. Document the mapping before it reaches a change board, and monitor the record for drift.
Sending from an unverified domain fails at the SMTP conversation, not at delivery
Only verified domains can send. An unverified From domain is rejected during the SMTP transaction with 554 5.1.0 The Sender's Address Was Not Allowed, which application logs often surface as a generic connection failure rather than a policy rejection. If your first test fails and the credentials are provably correct, check verification before anything else, including for subdomains used only by internal notifications.
Two hostname generations appear in current docs with no deprecation notice
The general help center documents smtp.socketlabs.com. The newer v2 set references smtp-cx.socketlabs.com, returned as the gateway field by the subaccount credential endpoint. Neither is marked deprecated. Treat them as two generations rather than aliases: use the hostname issued alongside your specific credential, pin it in configuration management, and do not mix a v2-provisioned credential with the classic endpoint.
Migrating SMTP setups
Moving to SocketLabs
Sequence the DNS work ahead of the traffic cutover. Add both CNAMEs, wait out the 24-48 hour propagation window, and confirm the domain shows verified before you repoint anything. Because SocketLabs requires no SPF edit, your existing record stays untouched during a parallel run, a real advantage when the old provider’s include: is still needed. Then provision SMTP credentials, dial concurrency down to the 20 connection ceiling, and shift a low-risk stream such as internal notifications first. If you are coming from a platform with deeper marketing tooling such as SendGrid, inventory which of those features you actually use before assuming parity: SocketLabs is strongest on relay reliability, on-premise MTA support and analytics, not campaign building. Warm-up throttling applies regardless of sending history elsewhere, so raise it during planning.
Moving away from SocketLabs
The exit is mechanically simple because nothing SocketLabs asked you to publish is entangled with your SPF record: removing the two CNAMEs severs the relationship cleanly, with no shared include: to edit out of a record other senders depend on. Do it in order, stand up the new relay, move traffic, confirm authentication passes on the new path in your DMARC aggregate reports for a full reporting cycle, and only then remove the SocketLabs records. Pull your suppression list out through the v2 API before closing the account, it does not travel with you, and re-mailing addresses that previously bounced or complained is the fastest way to poison a new IP reputation. For transactional-only workloads, Postmark is the closest comparison on delivery focus and diagnostics. One timing note: the Infobip acquisition closed on July 9, 2026 with no customer communication about brand, pricing, roadmap or endpoint longevity, and the product updates page has carried no 2026 entries. That is an absence of information, not evidence of change, but on a multi-year commitment, get pricing protection and support continuity in writing rather than inferring them from silence.
Frequently asked questions
What are the SocketLabs SMTP server settings?
Server smtp.socketlabs.com, port 587 with STARTTLS for most setups, 465 if your client needs implicit SSL, and 25 or 2525 as alternatives that also accept STARTTLS. The username is issued in the documented form server12345, with the password shown next to it under Configuration › SMTP Credentials. Your sending domain must be verified before the first message is accepted.
Which port should I use, 25, 587, 465 or 2525?
Use 587 with STARTTLS unless something prevents it. Use 465 only when your client requires implicit SSL, where the connection is encrypted before the SMTP conversation starts rather than upgraded mid-session. Use 2525 when a host blocks the standard submission ports, which is common on shared hosting. Port 25 works but is the most likely to be blocked upstream and offers no advantage.
Where do I find my SocketLabs SMTP username and password?
Under Configuration › SMTP Credentials, also called the Key Manager. Credentials are per server or per subaccount, not per user. For multi-tenant provisioning, create them through the v2 endpoint POST /v2/subaccount/:subaccountId/credentials/smtp, whose response returns username, password and gateway hostname together.
Why do I get 501 5.7.0 authentication failed when my credentials look correct?
Almost always because the password field holds an Injection API key rather than an SMTP password. SocketLabs issues three distinct credentials. SMTP username and password, Injection API serverId plus APIKey, and a v2 bearer token, and none works in place of another. Confirm the pair came from Configuration › SMTP Credentials, and that you are using the issued username rather than your account email address.
Do I need to change my SPF record for SocketLabs?
No. SocketLabs publishes no include: mechanism and its architecture deliberately avoids one. SPF alignment comes from the custom bounce domain: CNAME a subdomain such as email.yourdomain.com to tracking.socketlabs.com, which puts the Return-Path under your own organizational domain. Any include: value on a third-party DMARC blog is a guess, uncorroborated by SocketLabs documentation.
What are the SocketLabs SMTP limits?
Messages are capped at 40 MB, with 552 5.3.4 returned above that, and at 500 recipients each. SocketLabs allows 20 simultaneous connections per account and returns 421 4.4.5 beyond it, recommending roughly 50 messages per connection with pipelining. No hourly ceiling is published; new accounts carry an unquantified warm-up throttle that lifts automatically and can be adjusted by support ticket.
This review follows our email infrastructure testing methodology. We disclose affiliate relationships in our editorial independence policy.
