MessageGears SMTP Settings and Configuration (2026)

Read that as a design decision rather than an oversight. MessageGears is a warehouse-native platform sold on quotation, with no self-service signup and no public price list, and its SMTP endpoint is a bridge for systems that speak SMTP and nothing else. A WordPress installation, a Jira notifier or an old ERP will work fine. Anything needing attachments, warehouse-driven personalisation or CC and BCC semantics is expected to move to the API. Buyers who want a full SMTP surface with published DNS values, dedicated IP tiers and documented throughput ceilings will find it in a transactional-first vendor such as Postmark, SendGrid or Amazon SES.

Quick reference

These are the values MessageGears publishes in its SMTP Relay support article. Anything absent from this table is absent from the public documentation.

Two absences are worth naming, because almost every SMTP client defaults to them. Port 587, the RFC 6409 submission port, is not documented. Neither is port 465, the implicit-TLS port most libraries reach for when you tick “SSL”; MessageGears puts implicit TLS on 4525 instead. If your library, egress firewall or container network policy only allows 587 and 465, you need a firewall change before a single message leaves your infrastructure. That is the most common reason a MessageGears integration appears to hang at connect time.

SMTP configuration

Authentication

This is where MessageGears diverges most sharply from the rest of the market. Nearly every SMTP vendor gives you a DNS screen: you paste a domain, the console returns an SPF include, one or two DKIM CNAMEs and a suggested DMARC record, and a verification button turns green. MessageGears publishes a solid conceptual explainer on email authentication and DMARC, and no values at all. Provisioning runs through the Support Team.

SPF

MessageGears documents SPF the way a standards primer does: a TXT record at the apex of your sending domain listing the hosts permitted to send on its behalf, terminated by a qualifier. The documented example is the generic hard-fail terminator:

v=spf1 -all

That record authorises nothing and merely illustrates syntax. The value you actually need, the MessageGears include: mechanism, or the egress IP ranges, is not published anywhere in the public support corpus. You obtain it from Support during onboarding.

Two consequences follow. You cannot pre-stage DNS before signing, and SPF permits only ten DNS lookups per evaluation: if you already run Klaviyo, a helpdesk and Google Workspace on that domain, you will not know whether MessageGears breaks the ceiling until Support hands you the mechanism.

DKIM

MessageGears describes DKIM correctly, as a public key published in DNS and a signature receivers verify on arrival. What it does not publish is the detail you need to file a DNS ticket: the selector name, whether the record is a pasted TXT or a CNAME delegating to MessageGears-managed DNS, and the key length.

That distinction is not cosmetic. A CNAME delegation lets the vendor rotate keys without touching your zone, which is how Postmark and MailerSend handle it. A pasted TXT record pins the key in your zone and makes every rotation a change request on your side. Establish which model MessageGears uses before you design the runbook.

DMARC and domain alignment

MessageGears documents DMARC properly, including the three policy values and what each instructs a receiver to do with a failing message:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

The documentation puts unusual emphasis on domain alignment, and it is right to. DMARC does not simply ask whether SPF or DKIM passed; it asks whether the domain that passed matches the domain in the visible From header. A message can carry a valid DKIM signature and a clean SPF result and still fail DMARC, because both authenticated a bounce or relay domain rather than the one your recipient sees. That is the failure mode behind the ticket reading “our email is signed but Gmail still marks it as spam”.

Start at p=none with an rua address collecting aggregate reports, read them for at least two weeks to inventory every system sending as your domain, then move to quarantine and only then to reject. Since February 1, 2024 Google and Yahoo have required a DMARC record for bulk senders, so p=none is a staging posture, not a destination.

Custom bounce domains and return-path configuration are the usual lever for fixing SPF alignment. MessageGears does not document either publicly, and BIMI is likewise absent from the support corpus.

Rate limits and sending caps

There is no table here, and the honest reason is that there is nothing to put in one. MessageGears publishes no messages-per-hour ceiling, no recipients-per-message limit, no concurrent-connection count, no maximum SMTP message size and no dedicated-IP tiering. That is consistent with how the product is sold: throughput is a term in a negotiated contract, not a public specification.

Two figures are documented, and both come from the API side. A production request is submitted by POST and accepts up to 2 MB; the GET form is capped near 2 KB and is marked demonstration-only. That 2 MB ceiling bounds how much HTML plus recipient XML fits in one transactional submission, and it is the closest thing to a published size limit in the documentation.

The second documented constraint is structural rather than numeric, and it changes your volume arithmetic. When an SMTP message carries several addresses in the TO header, MessageGears delivers one individual message per recipient. A submission addressed to 50 people is 50 messages against your contracted volume and 50 items in reporting. Recipients will not see each other, which is usually what you wanted, but the accounting is not what the submission count suggests.

Guidance in the absence of numbers: get contracted throughput, burst allowance and concurrent-connection ceiling written into the order form before signature. Vendors that publish limits let you design against them; vendors that negotiate them let you discover them in production. Amazon SES and SMTP2GO document theirs.

Common setup gotchas

Migrating SMTP setups

To MessageGears

Assume the relay is a compatibility layer, not a destination. Inventory everything currently sending through your existing provider and sort it into two piles: messages that are a subject line plus an HTML body addressed to one person, and everything else. The first pile ports cleanly by changing hostname, port and credentials. The second, attachments, CC, BCC, or a multi-recipient TO that must stay visible as a group, needs rework against the v3.1 API before you can decommission the old path.

Sequence the DNS work first, because it is the only step with an external dependency. Request the values from Support, publish them alongside your existing provider’s records, and keep both senders authenticated during the overlap. Then move traffic stream by stream, lowest-stakes first, watching DMARC reports for alignment failures before you touch anything revenue-bearing.

Settle one thing before signature: with no self-service tier and no published pricing, an SMTP-only use case is an expensive way to buy MessageGears. Organisations adopt it to activate warehouse-resident data without copying it into a vendor database, as they might with Customer.io, and the relay comes along. If the relay is the whole reason you are looking, price it against SocketLabs or Elastic Email first.

From MessageGears

Leaving is mechanically simpler than arriving, because the relay uses so few provider-specific features. Point your client at the new hostname and port, swap credentials, and the SMTP layer is done. The friction is everywhere else.

Budget the most time for authentication. Removing the MessageGears SPF mechanism means finding the original support correspondence first, since the value never appeared in a console, or you risk deleting a mechanism belonging to another system. Retire the DKIM record only after the final message has cleared: in-flight mail signed with a retired key fails verification. Keep DMARC reporting on throughout.

Then take advantage of the move. A destination with published DNS values, documented rate limits and native attachment support removes every workaround the relay forced on you. Postmark is the usual landing spot for transactional traffic, Amazon SES for teams already on AWS, and SendGrid or Brevo for the mixed transactional-plus-marketing case. Re-test the attachment, CC and BCC paths you disabled: they work again, and the code routing around them is now dead weight.

Frequently asked questions