Sender.net operates a first-party relay at smtp.sender.net for transactional email. It is not an add-on and there is no separate SKU to buy, the Free Forever plan ships full SMTP and REST API access, and transactional email spans Free through Enterprise. TLS is mandatory, and the documented default is port 587 with STARTTLS.
Sender.net is a marketing-first ESP that bolted on a competent transactional relay, rather than an infrastructure vendor that grew a campaign builder. That shapes what it is good at: if you already run lists, automations and popups in Sender and simply need your WordPress site, your billing system or your app to emit receipts and password resets from the same authenticated domain, the relay is a clean fit at zero incremental cost. If transactional volume is the whole job and marketing is irrelevant, a dedicated relay will give you deeper logs and published throughput numbers. Among the ESPs in the same bracket, MailerLite and Brevo are the closest direct comparisons, Moosend sits nearby on price, and EmailOctopus is the cheaper campaign-only option that does not try to be a relay at all.
Values below come from Sender’s SMTP vs REST API help article, the authoritative surface for the relay. Credentials are created under Transactional emails › Setup instructions › SMTP › Add SMTP user-not in the API section.
| SMTP server | smtp.sender.net |
| Port (STARTTLS) | 587 RECOMMENDED |
| Alternative port | 2525-documented fallback when a host or ISP blocks 587 |
| Legacy port | 25-accepted, but commonly blocked outbound by cloud providers |
| Username | Generated SMTP user handle, e.g. Gabrielle_e736w1-not your login email, not the literal string apikey |
| Password | One-time secret shown only at SMTP-user creation, store it immediately, it cannot be revealed again |
Single endpoint for all accounts. Sender does not publish regional hostnames, so there is no EU/US split to choose between at connection time.
Sender enforces domain authentication at the point of verification rather than deferring it, and it requires DMARC as well as SPF and DKIM. That is stricter than most competitors in this price bracket, and it is the most common reason a first send fails.
Publish these three records at your DNS host, then return to Account settings › Domains and click Check SPF, DKIM and DMARC records. Propagation is usually minutes, occasionally up to 48 hours.
; SPF, merge into your existing record, do not add a second one @ IN TXT "v=spf1 include:sendersrv.com ?all" ; DKIM, published as a CNAME, not as a TXT public key sender._domainkey IN CNAME dkim.sendersrv.com. ; DMARC, Sender's documented starting policy _dmarc IN TXT "v=DMARC1; p=none;"
Two details differ from the usual ESP pattern. First, DKIM is a CNAME pointing at dkim.sendersrv.com rather than a TXT record containing a public key, which means key rotation happens on Sender’s side and you never have to touch DNS again for it. Second, a domain may carry only one SPF TXT record. If you already send through another provider, edit the existing record to add include:sendersrv.com inside it; publishing a second v=spf1 record makes SPF permerror and breaks both senders at once.
Because DKIM is signed on the sending domain and SPF authorises sendersrv.com under your own record, both identifiers align with the From domain in relaxed mode, which is what v=DMARC1; p=none; is checking. Start at p=none as Sender documents, collect aggregate reports for a couple of weeks, and confirm that Sender-originated mail is passing both mechanisms before tightening to p=quarantine and then p=reject.
The hard constraint to plan around: the From address must sit on the verified domain. Free mailbox domains such as gmail.com or outlook.com cannot be used at all, because you cannot publish the required records for a domain you do not control. If your application currently sends receipts from a Gmail address, that has to change before the relay will accept the message.
Sender deliberately does not publish fixed numeric throughput figures. Limits are enforced per minute and tracked per account, and the value in force for your account is returned in the response headers on every API call. The practical ceiling for most users is the plan’s monthly email allowance, not a per-hour throttle.
| Limit | Value | Notes |
|---|---|---|
| Monthly volume (Free) | 15,000 emails | Free Forever, alongside up to 2,500 subscribers. Paid tiers scale with subscriber count. |
| Per-minute rate limit | Per-account, unpublished | Read X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset from any API response to learn yours. |
| Throttle response | HTTP 429 | Returned with a Retry-After header. All API tokens on one account share a single window. |
| Attachment size | 25 MB | Per individual file. Total MIME message size is not published. |
| Transactional log retention | 1 / 5 / 30 days | 1 day on Free and Standard, 5 on Professional, 30 on Enterprise. |
Two consequences for capacity planning. If you are migrating a queue that bursts, a nightly digest, a Black Friday receipt spike, instrument the X-RateLimit-Remaining header on a low-volume API call first and size your worker concurrency from the real number, because there is no documented figure to design against. And on Free or Standard, budget for a webhook sink from day one: with 1-day log retention, a delivery failure you investigate on Wednesday about Monday’s send has already left no trace on Sender’s side.
Sender’s Email API feature page states that SMTP operates on ports 25, 465 and 587. Every help-centre article that actually configures the relay. Getting Started, Setting Up Transactional Emails, SMTP vs REST API, Common Transactional Issues, lists 25, 2525 or 587 with TLS/STARTTLS and never mentions 465. Treat 587 with STARTTLS as the supported configuration and 2525 as the fallback. If a client only offers implicit SSL on 465, test it against a throwaway address before wiring it into production.
Clicking Add SMTP user generates the username and password together, and the password is displayed only on that screen. Sender’s docs say it plainly: it will only be shown once. There is no reveal, no reset, no support path. Losing it means deleting the SMTP user and creating a new one, which then means updating every application still holding the old credential. Create one SMTP user per consuming application so that a lost secret costs you one redeploy rather than all of them.
The relay authenticates with the generated SMTP username and password from Transactional emails › Setup instructions. The REST API authenticates with a Bearer token from Account settings › API access tokens. They are not interchangeable: an API token pasted into a WordPress SMTP plugin’s password field fails authentication, and an SMTP password returns 401 against api.sender.net. This trips up almost everyone arriving from a provider that uses the literal string apikey as the SMTP username. Sender does not.
Verification gates sending, not signup. Account settings › Domains must show three green checkmarks for SPF, DKIM and DMARC, and the From address must be a mailbox on that same verified domain. If it is not, the API rejects the request or the message fails to deliver. Requiring DMARC at verification time is stricter than most competitors, so a setup that worked elsewhere with SPF and DKIM alone will stall here until you publish the _dmarc record too.
The credential model is the main thing to rewrite. Providers such as Brevo and MailerLite hand you either an account email as the username or a fixed sentinel string; Sender issues a generated handle instead, so a find-and-replace on the password alone will not work, you must change the username field too. Sequence it as: publish include:sendersrv.com into your existing SPF record and the DKIM CNAME while the old provider is still live (both can coexist), verify the domain in Sender, create one SMTP user per application, then flip hosts application by application rather than all at once. Keep the old provider’s DKIM record in place for a week after the last message so that in-flight and forwarded copies still validate.
Export what you need before you cancel: with 1-day log retention on Free and Standard there is effectively no historical send record to take with you, so if you need delivery evidence, stream events to your own store via account webhooks (paid plans) ahead of the migration. On the DNS side, remove include:sendersrv.com from your SPF record only after the final Sender-originated message has cleared, and leave the sender._domainkey CNAME published for a couple of weeks so that delayed and forwarded mail still passes DKIM. Delete the SMTP users in Sender last, that is the actual kill switch, and doing it first will produce authentication failures in applications you forgot were still pointed at the relay.
Host smtp.sender.net, port 587 with STARTTLS, authentication enabled using AUTH PLAIN or LOGIN. TLS is required. The username and password are the generated SMTP-user credentials created under Transactional emails, and the From address must be on a domain verified in Account settings.
Use 587 with STARTTLS. If your host or ISP blocks it, Sender documents 2525 as the fallback, which most cloud providers leave open. Port 25 is accepted but is blocked outbound by default on AWS, Google Cloud, Azure and most VPS providers, so it is rarely usable. Port 465 appears on Sender’s marketing page but not in any setup article, do not rely on it without testing.
Neither is your login email. Go to Transactional emails › Setup instructions › SMTP and click Add SMTP user. Sender generates a handle from a base name you choose plus a random suffix, and shows the password once at creation. Save it immediately, it cannot be revealed or reset later, only replaced by deleting the user and creating a new one.
Install an SMTP plugin such as WP Mail SMTP and choose the generic “Other SMTP” mailer. Set host smtp.sender.net, port 587, encryption STARTTLS, authentication on, then paste the generated SMTP username and one-time password. Set the From email to an address on your verified domain and enable the force-From option so plugins cannot override it with the WordPress default, which is usually wordpress@yourdomain and will not match.
Yes. Sender’s Free Forever plan lists full API and SMTP access, and the company states that transactional email is available across all plans from Free to Enterprise. There is no separate SMTP add-on SKU at any tier. Free covers up to 2,500 subscribers and 15,000 emails per month, with Sender branding, 1 user seat, 1 event webhook and 1-day transactional log retention.
Two causes account for nearly all of them. Either the domain is not fully verified, all three of SPF, DKIM and DMARC must show green in Account settings › Domains, and the From address must be on that domain, or you are presenting the wrong credential. An API Bearer token will not authenticate an SMTP session. Confirm you are using the SMTP username and password generated in the Transactional emails section, not the token from Account settings.
This review follows our email infrastructure testing methodology. We disclose affiliate relationships in our editorial independence policy.