Guide
Port 587 is the correct port for sending email from an application or client, using STARTTLS for encryption. Port 465 is an older alternative that uses implicit TLS and is still widely supported. Port 25 is for mail transfer between mail servers, and is blocked for outbound submission by most hosting, cloud and consumer networks. Port 2525 is an unofficial fallback offered by some providers for when 587 is blocked.
Last reviewed September 2026
The four ports
Three of these four ports are registered with IANA for mail and defined by an RFC. One is a provider convention with no standing at all. The distinction matters, because it decides whether a port works everywhere or only where a particular vendor decided to listen on it.
| Port 25 | Port 587 | Port 465 | Port 2525 | |
|---|---|---|---|---|
| What it is for | Mail transfer between mail servers | Message submission from an application or client | Message submission over implicit TLS | A fallback submission port where a provider offers one |
| IANA service name | smtp, "Simple Mail Transfer" | submission, "Message Submission" | submissions, "Message Submission over TLS protocol", sharing the port with urd | ms-v-worlds, which has nothing to do with email |
| Defined by | RFC 5321 | RFC 6409 | RFC 8314 | Nothing. It is a convention |
| Encryption | Opportunistic STARTTLS, negotiated per connection | STARTTLS, upgrading a plaintext connection | Implicit TLS, before any SMTP command | Whatever the provider offers, usually STARTTLS |
| Authentication | None for inbound transfer | Required by default | Required, on the same submission rules | Set by the provider, normally identical to 587 |
| Blocked outbound? | Yes, by most cloud, hosting and consumer networks | No. RFC 5068 says access providers must not block it | Rarely | Rarely, which is the entire reason it is offered |
| Use it when | You are a mail server, sending to or receiving from another mail server | Always, unless something specific rules it out | The client only speaks implicit TLS, or a cleartext phase is unacceptable | 587 is blocked and your provider explicitly supports 2525 |
| Omnivery | Inbound only. Mail for your domain arrives here and is routed by rules | Outbound submission at smtp.omnivery.net | Not offered for submission | Not offered for submission |
Sources: IANA Service Name and Transport Protocol Port Number Registry; RFC 5321, RFC 6409, RFC 8314 and RFC 5068. Omnivery values are from the SMTP and inbound routing documentation linked below.
Port 587 is where an application, a client or a device hands a message to a mail system for the first time. RFC 6409, Message Submission for Mail, is short and unambiguous about it:
"Port 587 is reserved for email message submission as specified in this document. Messages received on this port are defined to be submissions."
RFC 6409, section 3.1. Published November 2011, obsoleting RFC 4409.
Two things follow from that, and they are the reason 587 is the default answer rather than merely one option among several.
The submission role is not just a different port number for the same protocol. It carries a different set of obligations, and the first of them is that the sender identifies itself:
"The MSA MUST, by default, issue an error response to the MAIL command if the session has not been authenticated using [SMTP-AUTH], unless it has already independently established authentication or authorization."
RFC 6409, section 4.3. The MSA is the Message Submission Agent, the server accepting the message.
This is what separates submission from transfer at the level of the standard rather than the level of the port number. A message arriving on port 25 from another mail server is anonymous by design, because the sending server has no account with the receiving one. A message arriving on port 587 belongs to somebody, and that somebody can be rate limited, filtered, held to an acceptable use policy, and identified afterward. Every operational control a sending platform applies depends on knowing whose message it is.
RFC 5068, which is BCP 134, is the operational counterpart to RFC 6409. It puts one hard requirement on the networks in between:
"Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587."
RFC 5068, section 4.1. The same document says at section 3.1 that "MUAs SHOULD use the SUBMISSION port for message submission".
M3AAWG's current best practices go one step further than the RFC and cover both submission ports, telling providers to "allow customer hosts to connect to port 465 and 587 submission servers on your network and on other networks".
The requirement is honored in practice by the providers that block port 25 hardest. Google Cloud states that it "does not place any restrictions on traffic sent to external destination IP addresses using destination TCP ports 587 or 465". Microsoft says connections to authenticated relay services "are typically on TCP port 587 and isn't blocked", regardless of Azure subscription type. Amazon says a sender can "connect to Amazon SES using ports 465 or 587, neither of which is restricted". The three largest clouds block 25 and deliberately leave 587 open.
Omnivery's servers at smtp.omnivery.net listen on port 587. The connection authenticates with AUTH LOGIN using an SMTP credential. Insecure connections are supported, but upgrading to TLS with STARTTLS is strongly recommended. The MAIL FROM address must be on a configured sending domain and the From header has to align with it, which is a constraint your DMARC policy already imposes.
Where the integration is yours to choose, choose the API. SMTP submission is for systems that cannot reasonably take an API client - appliances, legacy billing and notification engines, anything where the sending code is not open for change. It is not a reduced version of the platform: the relay carries full parity with the REST API through X-OV-* headers, and the SMTP relay page covers what happens to a message after submission. But if you are writing the integration from scratch, the API is the more efficient path, and it takes port configuration out of the picture entirely.
Port 465 carries submission over implicit TLS: the TLS handshake completes before any SMTP command is exchanged, so there is no plaintext phase at all. It is the other correct answer for submission, and the reason it is usually presented as second choice is a history that most explanations of it get wrong.
You will read that port 465 is deprecated. You will also read that it was un-deprecated. Both statements are describing the same set of events badly, and RFC 8314 tells the story itself:
"Historically, port 465 was briefly registered as the 'smtps' port. This registration made no sense, as the SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used. As a result, the registration was revoked and was subsequently reassigned to a different service. In hindsight, the 'smtps' registration should have been renamed or reserved rather than revoked."
RFC 8314, section 7.3.
What was revoked was a registration for something else. "SMTPS" meant SMTP transport over TLS - server-to-server delivery - and that was a genuinely broken idea, because an MX record names a host and carries no port, so a delivering mail server has no way to be told to use 465. Nothing about submission was withdrawn, because submission was never what the registration described.
What happened next is that mail software ignored the distinction. RFC 8314 again: "some widely deployed mail software interpreted 'smtps' as 'submissions' and used that port for email submission by default when an end user requested security during account setup." A decade of clients and servers shipped implicit-TLS submission on 465 while the registry said the port belonged to a directory service.
RFC 8314, Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access, was published in January 2018 on the Standards Track. Rather than assign a new port and force a migration, it registered the real-world usage:
Service Name: submissions
Transport Protocol: TCP
Description: Message Submission over TLS protocol
Reference: RFC 8314
Port Number: 465
The IANA registration made by RFC 8314, section 7.3, described in the RFC itself as "a one-time procedural exception to the rules in [RFC6335]" requiring explicit IESG approval.
The registry today shows two live entries on TCP port 465: urd, the service the port was reassigned to, and submissions. The RFC calls that "a 'wart' in the registry documenting real-world usage of a port for two purposes", and judged it the least bad of the available options.
The industry guidance followed. M3AAWG's current best practices for managing port 25, updated August 2023, open by telling providers to "Provide email submission services on ports 465 and 587 as described in RFC 6409 and the updates in RFC 8314", and go on to say that client software should be configured "to use port 465 or 587 and authentication for email submission". The two ports are named together, as alternatives of equal standing. Whatever the folklore says, the body whose members are the mailbox providers treats 465 as a current submission port.
RFC 8314's recommendation for the transition is that "clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465", and the document as a whole prefers implicit TLS on the grounds that it is deployed more consistently. Two cases where it is the right call:
One case where it is the wrong call: the provider has to be listening on it. A registration says the port is the correct one for the job. It says nothing about whether a particular server accepts connections there, and providers differ. Microsoft states that a device recommending or defaulting to port 465 does not support the TLS versions required for client SMTP submission, so 465 will not work with Microsoft 365. Omnivery accepts submission on port 587 and does not offer 465. Confirm the port in your provider's own connection details before configuring it, because a port nobody is listening on fails exactly like a blocked one.
Port 25 is registered with IANA as smtp, "Simple Mail Transfer", and it is the port on which one mail server hands a message to the next. When a message leaves a sending platform for Gmail, it arrives on port 25 at a host named by gmail.com's MX records. Every mail server on the internet that accepts mail accepts it there.
It is not the port an application submits on, and RFC 6409 draws the line by role rather than by port number: a site "MAY choose to use port 25 for message submission by designating some hosts to be MSAs and others to be MTAs". The port is a convention that follows the role. What makes something submission is that an identified sender is handing over a message it originated; what makes something transfer is that one server is relaying a message it received.
Transfer on port 25 is anonymous by necessity - a delivering server has no account with the receiving one - and for years that made a compromised desktop machine an ideal spam cannon. It could open connections directly to every recipient's mail server, with no provider in the path applying rate limits, filtering or an acceptable use policy. The industry response was to close the path.
M3AAWG published the recommendation in 2005 and has maintained it since. It is one item in a seven-part set of email transmission best practices for providers:
"Block access to port 25 from all hosts on your network other than those that you explicitly permit to operate as SMTP relays. Such hosts will certainly include your own email submission servers and may also include the legitimate email submission servers of your responsible customers."
M3AAWG Best Common Practices for Managing Port 25 for IP Networks, original recommendation published 2005, updated August 2023.
The other items in that list are the reason the recommendation is not simply "close the port". A provider blocking 25 is required by the same document to provide email submission services on ports 465 and 587, to require authentication for it, and to allow customer hosts to connect to submission servers "on your network and on other networks". Blocking transfer is only defensible alongside supplying an authenticated route out, which is what makes the blocked port an anti-abuse measure rather than a restriction on sending.
The major cloud platforms apply the same policy to their own compute, and document it:
This is the single most common cause of an application that "cannot send email". The symptom is a connection that hangs and then times out rather than an error, because a dropped packet produces silence, not a refusal. Nothing is wrong with the credentials, the mail server or the code.
Worth being precise here, because port-25 blocking is often described as though a standard mandates it. It does not. RFC 5068, the BCP on email submission operations, declines to take a position:
"This document offers no recommendation concerning the blocking of SMTP port 25 or similar practices for controlling abuse of the standard anonymous mail transfer port."
RFC 5068, section 4. The same document's only hard requirement on access providers runs the other way: they "MUST NOT block users from accessing the external Internet using the SUBMISSION port 587".
So the blocking is an operator practice, adopted very widely and recommended by M3AAWG, while the standards-level obligation is the one that keeps 587 open. That is a distinction with a practical consequence: a network blocking port 25 is behaving normally and there is no standard to appeal to, whereas a network blocking port 587 is misconfigured and can be told so.
The step most explanations skip. Outbound port 25 being blocked on your machine says nothing about port 25 as a protocol.
Every mail server on the internet still receives on port 25. The block is on your machine sending out, not on mail servers accepting in.
Blocking is applied at the edge of end-user, hosting and cloud networks. It is not applied to the mail infrastructure those networks send through, which would stop mail working entirely.
Your provider's outbound servers deliver on port 25, to hosts named by the recipient domain's MX records, because there is no other way for mail to be delivered. That is one half of what port 25 is doing. The other half is the direction almost nobody writing about SMTP ports covers, and it is next.
Sending and receiving are different problems that happen to share a protocol. A sender needs 587 outbound. A domain that also accepts mail needs something listening on 25 inbound, at whichever host its MX records name. Those two requirements are met by different software, on different ports, under different rules, and a guide that only covers submission has covered half of SMTP.
The case comes up more often than it sounds. An application sending transactional mail generally also needs to catch what comes back: replies to a notification, a customer answering an order confirmation, a partner responding to an automated report. Running a mailbox server to receive them is a large amount of infrastructure for a small requirement.
Omnivery receives inbound mail for a configured domain and applies routes to it. A route is a rule, and the model is small enough to describe completely:
mail_from, mail_to or subject - using a regular expression, so the pattern can be as broad or as specific as the case needs.That last point is what makes a broad rule safe to write. The traffic you most need never to lose is the traffic the routing layer never sees.
Inbound routing is the piece that lets an application send transactional mail from an address that can also be replied to, without operating a mailbox server for the replies.
A reply arrives on port 25, matches a rule, and is forwarded to a real mailbox or a ticketing address. The sending application is unchanged.
Configuration is documented at domain routes. Outbound submission is documented separately at sending over SMTP.
Port 2525 is not an SMTP port. It is not assigned to mail by IANA, no RFC mentions it, and there is no sense in which a mail server is expected to be listening there. The registry entry for TCP 2525 is ms-v-worlds, "MS V-Worlds", which is unrelated to email.
What it is, is a convention. Some providers listen on 2525 in addition to the registered ports, for one reason: it is a high, unremarkable port that networks blocking 25 have no reason to block. Mailgun documents its servers on ports 25, 465, 587 and 2525, and gives exactly that rationale, noting that Google Compute Engine allows 2525 for SMTP submission. Google's own Compute Engine documentation uses 2525 as its worked example when explaining how to open a custom port for mail.
Two things follow, and both are reasons to treat it as a fallback rather than a default.
Reaching for 2525 is a symptom worth reading. It means something in the path is blocking a registered submission port, and that is usually the thing to fix.
Port 25 being blocked is normal and expected. Port 587 being blocked is a misconfiguration on a network that has an obligation under RFC 5068 not to do it, and it is worth raising with whoever runs that network before working around it.
Omnivery accepts submission on port 587 and does not offer 2525. Where 587 is genuinely unavailable and cannot be opened, we encourage customers to reach out to our support.
This is the distinction underneath the 587-versus-465 question. The two ports differ in when encryption starts, and that difference has one security consequence.
EHLO, the server advertises its extensions, and if STARTTLS is among them the client issues the command and the two negotiate TLS on the connection they already have. RFC 3207 specifies that "upon completion of the TLS handshake, the SMTP protocol is reset to the initial state", so the conversation starts again inside the encrypted channel. This is port 587.The weakness in an opportunistic upgrade is that the client learns TLS is available by being told so, over a channel that is not yet protected. RFC 3207 names it in its own security considerations:
"A man-in-the-middle attack can be launched by deleting the '250 STARTTLS' response from the server. This would cause the client not to try to start a TLS session."
RFC 3207, section 6. Published February 2002.
An attacker positioned on the path does not have to break TLS. It removes the offer, the client concludes the server does not support encryption, and the session continues in the clear with credentials and message content in it. The attack works on any client that treats TLS as desirable rather than required, which is the default behavior in a surprising amount of mail software.
Configure the client to require TLS and to fail the send if it cannot get it. A client that requires TLS is not vulnerable to stripping, because a removed offer produces a refusal to send rather than a cleartext send. RFC 3207 leaves the choice to the client - "if the client receives the 454 response, the client must decide whether or not to continue the SMTP session" - and that decision is yours to make in configuration.
Most SMTP libraries express this as a distinction between two settings that sound similar and behave very differently: something like "use TLS if available" against "require TLS". Only the second one is a security control. Where the library offers only the first, port 465 removes the question, which is the practical case for implicit TLS.
RFC 8314 is titled Cleartext Considered Obsolete for this reason, and its recommendation for the transition period is that clients and servers support both: "clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465".
One point that gets conflated. Encrypting your submission to the relay and encrypting the relay's delivery to the recipient's mail server are separate decisions on separate connections.
smtp.omnivery.net on port 587. Omnivery supports insecure connections and strongly recommends upgrading with STARTTLS. This is the leg you control with client configuration.X-OV-Require-TLS header, so a message that must not be delivered in the clear is not delivered in the clear.Requiring TLS on submission does nothing about the second leg, and a great many discussions of "is email encrypted" are two people each talking about a different one of these.
The short version, in order of how often each applies.
If you are choosing a port, the answer is 587. If 587 does not work, the problem is almost never the port number.
A connection that fails on 587 is far more often blocked outbound, failing authentication or failing certificate validation than it is aimed at the wrong port number.
Most reports of an SMTP port failure are not about the port. The port number is the most visible setting in the configuration, so it collects the blame, but the failures below account for the large majority of cases and only one of them is fixed by changing a number.
AUTH before the connection is encrypted where the server requires encryption first. Some clients surface all of these as "could not connect".EHLO or strips the STARTTLS capability. This is the same shape as the stripping attack, arriving from your own security equipment rather than an adversary.Each step below only makes sense if the one before it passed, which is what makes the order worth keeping.
EHLO, advertise STARTTLS. If it opens but the banner is wrong or STARTTLS is absent, something is in the path.Both platforms accept application mail, and both do it on their own terms: their own hostnames, their own supported ports, their own authentication models and their own documented limits. Those limits, rather than the port numbers, are what usually decide whether the arrangement works.
smtp.office365.com on port 587 and requires a licensed mailbox; port 465 is not supported at all. Two of the four methods cannot reach external recipients.smtp-relay.gmail.com and accepts 25, 465 or 587, with 587 for TLS. Authentication is by IP allowlist, SMTP AUTH or both. There is a separate, much smaller service on smtp.gmail.com, and a third endpoint that reaches Google addresses only.Neither platform is built to be an application sending platform, and the documented throughput limits are usually what settles it: Microsoft caps client submission at 10,000 recipients a day and 30 messages a minute, and Google allows 10,000 recipients per user per 24 hours with a hard limit of 100 recipients per SMTP transaction.
At a glance
submission, "Message Submission", referencing RFC 6409.submissions on TCP port 465 in January 2018, describing the registration as a one-time procedural exception made to document widespread existing practice.urd and submissions.smtp, "Simple Mail Transfer", and is used for mail transfer between mail servers rather than for application submission.mail_from, mail_to or subject using regular expressions.ms-v-worlds, which is unrelated to email.smtp.omnivery.net on port 587, authenticating with AUTH LOGIN.X-OV-Require-TLS header, which is a separate control from the encryption used on the submission connection.Questions
SMTP uses four ports in common practice, for two different jobs. Port 587 is the submission port, used by an application or client to hand a message to a mail system, and it is the one to configure unless something specific rules it out. Port 465 is the alternative submission port, using implicit TLS. Port 25 is the transfer port, used between mail servers, and is blocked for outbound submission on most networks. Port 2525 is an unofficial fallback that only works where a provider explicitly supports it.
When encryption starts. Port 587 opens in cleartext and upgrades to TLS using the STARTTLS command, so there is a brief unencrypted phase in which the client and server exchange greetings. Port 465 completes the TLS handshake on connect, before any SMTP command is sent, so nothing at all crosses the network in the clear. Both are registered with IANA for submission and both are correct. RFC 8314 recommends that clients and servers support both, and 587 is the wider default because more providers listen on it.
Not from an application. Port 25 is for mail transfer between mail servers, and an application submitting a message it originated is doing something different. In practice the attempt usually fails anyway, because most consumer, hosting and cloud networks block outbound port 25 as an anti-abuse measure. Use port 587.
Because transfer on port 25 is anonymous by design, which for years made a compromised machine an ideal spam source: it could connect directly to every recipient's mail server with no provider in the path applying rate limits or an acceptable use policy. M3AAWG recommends that providers block port 25 from all hosts other than those explicitly authorized to relay, and the major clouds apply the same policy to their own compute. Google Cloud blocks port 25 to destinations outside the customer VPC, Azure blocks it for deployed VMs outside Enterprise Agreement and MCA-E subscriptions, and Amazon EC2 restricts it by default. Note that no standard requires this: RFC 5068 explicitly declines to make a recommendation about blocking port 25.
Because the block is on end-user, hosting and cloud networks sending out, not on mail servers accepting in. Every mail server on the internet still receives on port 25, and your sending provider still delivers to those servers on port 25. What changed is the shape of the path: instead of your machine connecting directly to the recipient's mail server, it submits on port 587 to a provider that is authorized to relay, and that provider does the port 25 delivery.
Port 25. Mail for a domain is delivered to the host named by that domain's MX records, on port 25, by whichever mail server is sending it. This is a different job from retrieving mail from a mailbox, which uses IMAP or POP3 on their own ports and is not SMTP at all.
Yes. Omnivery receives inbound mail on port 25 for configured domains and routes it based on rules. That is useful in the common case where an application sends transactional mail from an address people can also reply to, and running a mailbox server for those replies would be a large amount of infrastructure for a small requirement.
With a route, which is a rule matching on one of three fields - mail_from, mail_to or subject - using a regular expression. A matching message gets either a forward action, which sends it on to a destination email address, or a stop action, which discards it. The stop action is final. System messages such as bounces and feedback loop reports are excluded from routing and handled separately, so a broad pattern cannot capture them by accident. Configuration is documented at domain routes.
Nothing standard. Port 2525 is not assigned to email by IANA - the registration on that port is ms-v-worlds, which is unrelated - and no RFC mentions it. Some providers listen on it as a fallback because it is a high, unremarkable port that networks blocking 25 have no reason to block. Mailgun documents it alongside 25, 465 and 587 for that reason. It works only where a provider explicitly supports it, and the chosen fallback port varies: Amazon SES offers 2465 and 2587 instead.
No, and the confusion is worth unpicking because it is repeated everywhere. Port 465 was briefly registered as "smtps", meaning SMTP transport over TLS between mail servers. RFC 8314 says that registration "made no sense, as the SMTP transport MX infrastructure has no way to specify a port", so it was revoked and the port reassigned. But mail software had already adopted 465 for implicit-TLS submission, so RFC 8314 registered the service name submissions on the same port in January 2018 to document the existing practice. What was deprecated was a registration for server-to-server transfer. Submission on 465 was never deprecated, and today it is standards-registered.
STARTTLS upgrades a connection that already opened in cleartext: the client connects, the server advertises STARTTLS among its extensions, the client issues the command, and the two negotiate TLS on the existing connection. RFC 3207 specifies that the SMTP protocol is then reset to its initial state inside the encrypted channel. Implicit TLS establishes encryption on connect, before any SMTP command is exchanged, so there is no cleartext phase to upgrade from.
Port 465 has a marginal structural advantage, because it has no cleartext phase for an attacker to act on. RFC 3207 documents the corresponding weakness in STARTTLS directly: "A man-in-the-middle attack can be launched by deleting the '250 STARTTLS' response from the server. This would cause the client not to try to start a TLS session." But that attack only works against a client that treats TLS as optional. A client on port 587 configured to require TLS, and to fail the send rather than continue without it, is not vulnerable to stripping. The security control is the client setting, not the port number.
Port 587, at smtp.omnivery.net, authenticating with AUTH LOGIN. Insecure connections are supported but upgrading to TLS with STARTTLS is strongly recommended. The MAIL FROM address must be on a configured sending domain and the From header has to align with it. Inbound mail is a separate path and arrives on port 25. Where the integration is open to change, the API is the better path; SMTP submission is for systems that cannot reasonably take an API client, and carries full parity with the REST API through X-OV-* headers.
A timeout rather than a rejection almost always means the packets are not arriving, which points at outbound blocking on the sending network rather than at the mail server. If the port is 25, that is the expected behavior on nearly every cloud and hosting platform. Other frequent causes that present as connection problems: authentication failing and being reported by the client as a connection error, TLS negotiation failing on certificate validation, a firewall opening the TCP connection but interfering with the SMTP conversation, and receiver-side rate limiting producing slow responses and dropped connections. Check outbound connectivity first, then the greeting and advertised extensions, then TLS, then authentication, then provider-side limits.
Outbound, no, unless the machine is a mail server delivering directly to other mail servers. An application submitting through a relay needs outbound 587 and nothing else. Inbound, only if the machine is itself receiving mail for a domain, which means it is named by that domain's MX records. Most systems that send transactional email need neither, because both directions are handled by the sending platform.
Technically often yes, and it is a bad idea. Omnivery supports insecure SMTP connections but strongly recommends upgrading with STARTTLS, and an unencrypted submission puts your credentials and your message content on the network in the clear. Configure the client to require TLS rather than to use it if available, so that a failure to negotiate encryption fails the send instead of silently falling back. Note that this covers the submission leg only: TLS on delivery from the relay to the recipient's mail server is a separate decision, controlled per message through the X-OV-Require-TLS header.
Every external claim on this page traces to one of these. Where a statement describes Omnivery's own platform rather than a published standard, it is linked to the documentation instead.
submissions service registration and its description as a one-time procedural exception, and of the recommendation that clients and servers implement both STARTTLS on port 587 and implicit TLS on port 465.smtp on 25, submission on 587, urd and submissions both on 465, and ms-v-worlds on 2525. Checked September 2026.smtp.omnivery.net, port 587, AUTH LOGIN, the support for insecure connections alongside the strong recommendation to upgrade with STARTTLS, and the statement that sending using APIs should always be preferred where integration allows.mail_from, mail_to or subject with regular expressions, the forward and stop actions, the finality of stop, and the exclusion of bounces, feedback loop reports and other system-to-system messages from routing.Port assignments and vendor policies change. The IANA registry entries and the three cloud providers' port 25 policies were checked in September 2026. Omnivery's documentation lists port 587 for submission and no other; where this page describes ports 465 and 2525 it is describing the protocol and other providers' practice rather than an Omnivery capability.
The port is the first configuration value and the least interesting one. These cover what happens to a message after the connection is open.
X-OV-* headers.Point the sending system at smtp.omnivery.net on port 587 with STARTTLS and an SMTP credential. Three configuration values, no SDK and no deployment, on infrastructure Omnivery owns end to end. Inbound mail for the same domain can be received and routed on port 25 without running a mailbox server.