Benchmark Email SMTP Settings and Configuration (2026)

If you came here for Benchmark Email SMTP settings, the short answer is that they do not exist and no support ticket will produce them. The useful answer depends on what you meant to do with those credentials. If you wanted campaigns to authenticate and reach the inbox, that is domain authentication–two CNAME records plus a DMARC TXT record, and Benchmark does it well. If you wanted receipts, password resets or app notifications, you need a real relay alongside Benchmark: Amazon SES at volume, Postmark for transactional deliverability, or Brevo and Mailjet if the goal is really to collapse both jobs into one vendor. Peers differ here: Mailchimp sells SMTP as a paid add-on, MailerLite and AWeber ship relay endpoints, and Constant Contact sits closest to Benchmark’s position.

Quick reference

Why Benchmark Email has no SMTP relay

Benchmark is a marketing-first ESP built around a campaign composer, not a developer sending platform. The architecture assumes a human writes a campaign in the UI and sends it to an opt-in list stored inside Benchmark. There is no per-message injection path anywhere in the product: the REST API can create a campaign, set from, subject, body and target lists, and duplicate an existing campaign, then it stops. The official campaign guide is unambiguous that scheduling, sending, cancelling and test-sending are not available via API key. With no injection surface, there is no relay to expose and no credential to issue.

The second reason is reputation posture. Benchmark sends from a shared IP pool spread across its marketing customers, with a dedicated IP only as a paid add-on. A relay product needs the opposite: per-customer isolation, per-message telemetry and a support model tuned to developers debugging bounce codes. Benchmark has never claimed that market, and its own blog publishes roundups of transactional alternatives to other providers. Treat the absence as a deliberate scope decision, not a feature awaiting a roadmap slot: it is not paywalled, it does not exist.

What you actually need instead

Three intents account for nearly every “Benchmark SMTP settings” search. Each has a concrete path that needs no relay credential.

Sending transactional email

Receipts, password resets and order confirmations cannot go through Benchmark. Stand up a dedicated relay and point your application at it. Amazon SES is cheapest once volume is real and gives you a regional SMTP endpoint plus an API. Postmark and SparkPost give better per-message analytics and stricter separation between transactional and broadcast streams. Resend and MailerSend suit teams that keep templates in version control. Whichever you pick, send from a distinct subdomain such as txn.example.com so Benchmark’s marketing complaint rate never touches it.

Connecting a CMS or app

WP Mail SMTP, WooCommerce order mail, Laravel’s mail driver and every other mailer screen expect a host, a port and a credential pair. Benchmark supplies none of the three, so there is nothing to enter. The first-party Benchmark WordPress plugin does not fill the gap either: it embeds signup forms and mails formatted blog posts to a Benchmark list, and never touches wp_mail(). Configure your mailer plugin against a real relay such as SMTP2GO or Amazon SES for site mail, and keep the Benchmark plugin for subscriber capture only.

Routing notifications and alerts

Server alerts, form notifications, cron reports and internal digests are transactional in shape even at tiny volume, so do not force them through a campaign tool. A small relay account handles them for cents. Benchmark’s Zapier connector can write contacts and lists, but it cannot trigger a send, the ceiling is the one the API hits.

Sending domain authentication

This is the real work, and what most readers of this page actually need. Benchmark authenticates a sending domain with three DNS records: two CNAMEs delegating SPF and DKIM to Benchmark, plus one DMARC TXT record. Authentication will not complete without a valid DMARC record, which trips up most first-time setups. Free plans authenticate 1 domain; Pro allows 10.

SPF and DKIM setup

Benchmark migrated SPF and DKIM from TXT to CNAME delegation; the knowledge base states plainly that for both, the record type will be CNAME. Names and targets are generated per account and shown only in-app at Domain Authentication, and are published as static values in no official doc, so there is nothing to copy from this page or any other. Generate yours, then paste them exactly.

; Benchmark Email domain authentication - record SHAPES, not values.
; The two CNAME names and targets are ACCOUNT-SPECIFIC. Generate them at
; app.benchmarkemail.com/DomainAuthentication and copy them verbatim.

[spf-name-from-app].example.com.    IN  CNAME  [spf-target-from-app]
[dkim-name-from-app].example.com.   IN  CNAME  [dkim-target-from-app]

; DMARC is the one record you write yourself. It stays a TXT record
; and it is MANDATORY - authentication will not flip to Authenticated
; until a valid DMARC policy resolves on _dmarc.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

The flow, per the official knowledge base: verify the email address tied to your domain, open Domain Authentication and generate your records, add both CNAMEs at your DNS host, confirm a valid DMARC TXT record exists, then click Check Configuration and wait for the status to flip to Authenticated. Allow up to 48 hours for propagation before treating a failure as real. The April 2026 release added DNS copy warnings and longer retry timing, so a stalled check now explains itself better. Domain status is also readable via GET /api/email/domain with the domains:read scope.

DMARC alignment

Because SPF and DKIM are delegated by CNAME, alignment is handled on Benchmark’s side once the records resolve, you never pick a selector or maintain an include: mechanism. What you control is the policy: start at p=none with an rua address, confirm Benchmark traffic passes both mechanisms across a full reporting cycle, then move to p=quarantine and finally p=reject.

One trap deserves its own sentence. Benchmark inspects your existing DMARC during setup. If it already shows a green checkmark, do not also add Benchmark’s suggested record, a second _dmarc TXT record makes the policy ambiguous, receivers discard both, and DMARC breaks for every stream you send. Benchmark only suggests a value when your current record is missing or malformed, and then shows your existing value beside the correction.

Sending limits

These are platform throughput and quota numbers, not relay limits, there is no relay to limit. They matter when sizing a large campaign or budgeting API calls for a sync job.

Every response carries X-RateLimit-Remaining, X-RateLimit-Reset and X-Monthly-Remaining. Both walls return HTTP 429 with a Retry-After header, so the status code alone will not tell you which one you hit. Retry only on 429 with exponential backoff. Benchmark’s own sources also disagree on the Free send ceiling: the pricing page says 2,500 emails/month, the Starter Plan article says 3,500. Plan against the lower figure.

Common mistakes

Pairing Benchmark Email with an SMTP provider

Running Benchmark for campaigns and a dedicated relay for everything else is a normal architecture. It only gets fragile when the two systems share DNS assumptions or overlapping audiences.

Recommended setup

Split by subdomain. Authenticate mail.example.com for Benchmark and txn.example.com for the relay, each with its own DKIM delegation. Receivers then track two independent reputations under one organisational domain, so a bad campaign week cannot depress password-reset delivery. Pick the relay on need: Amazon SES when unit cost dominates, Postmark for transactional placement and message-level debugging, SparkPost for analytics at scale, SMTP2GO for plain SMTP with minimal setup, Resend or MailerSend for template-in-repo workflows. If the split itself feels like overhead, Brevo and Mailjet do both jobs in one account, that is a decision to leave Benchmark, not to pair with it.

Keeping the two systems from colliding

Three conflicts show up in practice. First, duplicate DMARC records: both vendors will offer to generate a _dmarc TXT record during onboarding, and publishing two makes the policy ambiguous enough that receivers discard both. There is exactly one _dmarc record per domain, write it once, list every rua destination in it, and decline both offers.

Second, double-sending. A Benchmark automation and your application can react to the same event, so a signup gets both a Benchmark welcome and an app confirmation. Decide per message type which system owns it, write that ownership down, and make the relay authoritative for anything the user is waiting on in real time.

Third, list drift and suppression. Unsubscribes in Benchmark do not propagate to your relay’s suppression list, and relay-side hard bounces do not clean Benchmark contacts. Reconcile both directions on a schedule-POST /api/contact/search and /api/contact/{id}/events expose enough to build it inside the 3,600 requests/hour budget.

Frequently asked questions