The relay is real — smtp.api.createsend.com on ports 587, 25, 465 and 2525 — but it is gated behind Campaign Monitor Transactional (classic transactional email), which needs the transactional permission, a monthly plan and verified authentication. No separate per-email price is published: volume is bundled into your plan allowance. Marketing campaigns never relay over SMTP.
Two traps break most first attempts: the relay carries classic transactional email only, and username and password are the same token string — not your login, not your API key. Legacy credit-billed accounts cannot use it at all and need a dedicated provider such as Postmark, Brevo, SMTP2GO or Mailgun. Comparing marketing platforms instead? See Mailchimp, Constant Contact and GetResponse.
| SMTP server | smtp.api.createsend.com — single global endpoint, no regional variants documented |
| Port (STARTTLS) | 587 RECOMMENDED |
| Port (TLS on 465) | 465 — supported, but you still negotiate TLS; implicit SSL is not offered |
| Alternative ports | 25 and 2525 — all four published ports support TLS |
| Username | Any valid SMTP token generated in the account — not your login email, not your v3.3 API key |
| Password | Identical to the username — the same token string goes in both fields |
Source: the classic transactional email article, plus billing for transactional for the plan gate.
Classic transactional email only — password resets, order confirmations, receipts, system notifications. Marketing campaigns are not accepted on this endpoint.
The relay reads X-Cmail-* headers mirroring the API’s JSON fields: X-Cmail-GroupName buckets sends for reporting, X-Cmail-TrackOpens and X-Cmail-TrackClicks toggle tracking, X-Cmail-InlineCSS inlines your stylesheet. Set both tracking headers false on security mail and anything outliving the 90-day tracking window.
Two unrelated layers apply. Connection auth is the SMTP token. Domain auth is DNS, and Campaign Monitor blocks transactional sending until it verifies — the records below are a dependency of the integration, not a deliverability upgrade.
Every account gets a default sending domain and SPF record, which is why campaigns send before you touch DNS. To send as your own domain, publish three records: a DKIM key on the cm selector, an SPF include, and a DMARC policy. Use a TTL of at least 300 seconds, then verify in the app after propagation.
; SPF - one record only per domain. If you already have an SPF record, ; add the include to it rather than publishing a second record. example.com. TXT "v=spf1 include:_spf.createsend.com ~all" ; DKIM - selector is "cm". The public key is generated inside Campaign ; Monitor and is account-specific; copy it from the app. cm._domainkey.example.com. TXT "k=rsa; p=YOUR_ACCOUNT_PUBLIC_KEY" ; DMARC - the minimal record Campaign Monitor publishes for ; Google and Yahoo bulk sender compliance. _dmarc.example.com. TXT "v=DMARC1; p=none;"
Sending from mail.example.com makes the DKIM host cm._domainkey.mail.example.com. Campaign Monitor flags the DNS-host quirk: some providers want the fully qualified name, others append the zone and want only the cm._domainkey part. Get it wrong and the record lands one zone too deep, where verification never passes. Click-tracking and view-in-browser links use a separate, account-specific CNAME shown in the app.
Alignment is where the two products quietly diverge. Once cm._domainkey is verified, campaigns and transactional mail both sign with your domain and alignment holds. It breaks when the relay sends from a different subdomain than campaigns do, or when only one stream is authenticated: p=quarantine then files legitimate receipts while newsletters sail through — the hardest failure to spot, because half your mail looks fine.
Start at p=none with an rua address, read two weeks of aggregate reports, and confirm both streams show DKIM pass on the right domain before tightening. If a CRM, helpdesk or Google Workspace also sends as the domain, get those into SPF and DKIM-signed first — otherwise enforcement suppresses your own mail.
| Limit | Value | Notes |
|---|---|---|
| Recipients per message | 25 | Counted across To, CC and BCC combined. Fan-out beyond this must be chunked client-side. |
| Attachments | PDF only, 25 MB | No CSV, ICS or image attachments. Over SMTP, filenames must use standard Latin characters only. |
| Monthly transactional allowance | Plan-bound | On the entry monthly plan, transactional counts against the plan’s combined send limit for your pricing tier; on Unlimited and Premier monthly plans the transactional limit is 10x the tier’s subscriber limit. |
| Request rate limit | Not published | Transactional endpoints are rate limited and return HTTP 429 with X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. Read the headers rather than assume a ceiling. |
| Message log page size | 50 default, 200 max | The message timeline uses cursor pagination via sentBeforeID and sentAfterID rather than page numbers. |
No hourly throughput or concurrent-connection cap is published, so the practical governor is the 429 response — back off against X-RateLimit-Reset, not a fixed sleep. Exceeding the monthly allowance does not bounce mail either: Campaign Monitor applies an automatic waiver and moves the account to a higher pricing tier without asking.
Campaign Monitor splits transactional into two products and only one speaks SMTP. Classic transactional, where your app supplies the entire MIME body, is documented as sent via API or SMTP. Smart transactional, where the template lives in Campaign Monitor and you pass a variable payload, is triggered by POST /transactional/smartEmail/{id}/send and has no SMTP path. Choosing smart emails so marketers can edit copy without a deploy rules out SMTP by definition. Decide before you plumb a client in: switching later is a code change, not a config change.
The documented format is: username is any valid SMTP token, password is the same as the username. Every other major ESP uses a distinct pair — often a literal apikey username — so muscle memory fails here. Pasting your account email or v3.3 API key returns an auth error that looks like a permissions problem and is not. Generate a dedicated SMTP token and put that same token in both fields. Related trap: TLS is required and SSL is not supported, so a client set to implicit SSL on 465 hangs. Use STARTTLS on 587.
Two prerequisites are documented and both fail silently. The account needs the transactional permission, and per the billing article you must use email authentication and be on a monthly plan. Legacy pay-as-you-go credit accounts — common among agencies and low-frequency senders — cannot send transactional email at all, and there is no fix short of changing billing model. An account missing cm._domainkey or the _spf.createsend.com include is blocked the same way, so do the DNS first.
Retention is short and asymmetric: content 30 days, delivery and engagement data 90 days, and tracked links stop resolving after 90 days. That last one bites long-lived mail — a customer opening an invoice four months later follows a dead redirect. Set X-Cmail-TrackClicks to false there so the raw URL survives. Resends cover sent messages and soft bounces under 30 days only, and silently drop attachments.
Mechanically the move is small — Campaign Monitor frames switching provider as changing the server, username and password. Do the DNS first: publish cm._domainkey, add include:_spf.createsend.com to your existing SPF record rather than creating a second one, and verify. Then swap host to smtp.api.createsend.com, port to 587, and put the token in both credential fields.
The audit that matters is the payload, not the connection. Check every existing template against three hard limits: more than 25 recipients across To, CC and BCC; any attachment that is not a PDF; any link that must still work 90 days after send. CSV exports, ICS invites and PNG receipts all fail, with no workaround beyond linking to a hosted file. If several templates fail, leave those streams on a dedicated relay such as Postmark or SMTP2GO and move only what fits.
The usual triggers are the PDF-only attachment policy, the 25-recipient ceiling, 90-day log retention that fails compliance, and no dedicated IP pools per stream. Export from the message log before cutting over: content is gone at 30 days, everything but metadata at 90.
Run both relays in parallel for a full billing cycle. Keep the Campaign Monitor SPF include and DKIM record published throughout — pulling them early strands in-flight mail — and add the new provider’s records alongside. Send transactional from a distinct subdomain such as mail.example.com while campaigns stay on the root, so DMARC reports name the failing source. Retire the old records after a clean week of aligned delivery.
Yes, at smtp.api.createsend.com, but only for classic transactional email. It is part of the Campaign Monitor Transactional feature and requires the transactional permission, a monthly plan and verified email authentication. The marketing product — newsletters, journeys, segments — has no SMTP path and never has.
Server smtp.api.createsend.com; ports 587, 25, 465 and 2525, all of which support TLS; username is any valid SMTP token; password is the same token string. Use STARTTLS — the documentation states TLS is required and SSL is not supported, so implicit SSL on 465 will not connect.
A dedicated send credential created in the Transactional area of the account, separate from your login and your v3.3 API key. The same string serves as both SMTP username and password. Anyone holding it can send as your authenticated domain, so keep it in a secrets manager and rotate it if it leaks into a repo or a ticket.
In order of frequency: you used your account email or API key instead of an SMTP token; you put a different value in the password field instead of repeating the token; the account is on legacy credit-based billing, which cannot use transactional at all; domain authentication has not been verified; or the client is set to implicit SSL on 465 instead of STARTTLS. Work through those five before opening a ticket.
No. The relay accepts classic transactional messages only, capped at 25 recipients across To, CC and BCC. Bulk campaigns are built in the app or through the REST API at https://api.createsend.com/api/v3.3/. Fanning a newsletter through the relay is blocked by the recipient cap and outside how the feature is licensed.
Install an SMTP plugin such as WP Mail SMTP, pick the generic Other SMTP mailer, and enter host smtp.api.createsend.com, port 587, encryption TLS, auth on, then the token in both credential fields. Set From to a mailbox on the domain you authenticated with cm._domainkey, never a Gmail or Outlook address, or alignment fails. Send the test message and confirm it lands in the transactional log.
This review follows our email infrastructure testing methodology. We disclose affiliate relationships in our editorial independence policy.