Singtel and MyRepublic Finally Connected Their Networks Differently

The change happened without much fanfare. Sometime in early 2024, Singtel’s interconnection with MyRepublic shifted — a quiet peering adjustment that most residential users wouldn’t notice and that most coverage treated as a footnote in a larger infrastructure story. For anyone running email hosting out of a Singapore data center, the effect was something else entirely. Latency to certain routes dropped by double-digit milliseconds. Packet loss on some international hops flattened out. The kind of improvement that shows up not in a speed test but in how quickly an Outlook client syncs at 9 AM on a Monday morning.

The catch is that most local email hosting users never saw that improvement. By default, their traffic still routes through the older, slower paths — Singtel’s general transit, the same domestic peering that existed before the change, the routes that any residential broadband plan uses automatically. Getting the lower latency requires two deliberate actions: choosing an email hosting provider that peers with MyRepublic on the right exchange, and making sure your own connection isn’t bottlenecked at the last mile.

Three Millisecond Network Latency, Then One

The Singtel-MyRepublic peering adjustment was, at its technical level, a reconfiguration of how the two networks exchange traffic at the Singapore Internet Exchange (SGIX) and through private peering arrangements. Before 2024, traffic from Singtel’s residential and SMB customers bound for MyRepublic’s network — or traversing MyRepublic’s upstreams — went through a standard settlement-free peering arrangement at the exchange. The latency was acceptable by general internet standards: roughly 3-5 milliseconds within Singapore, climbing to 60-80 milliseconds for routes that passed through MyRepublic’s international transit paths.

After the reconfiguration, that latency dropped. Internal testing from several email hosting providers showed round-trip times falling to 1-2 milliseconds within Singapore for certain routes, and international paths via MyRepublic’s preferred upstreams shaving off 15-25 milliseconds compared to the same paths routed through Singtel’s general transit. The improvement was most pronounced for traffic heading to Japan and the US West Coast — two regions where MyRepublic has invested heavily in direct submarine cable capacity.

For email hosting, those milliseconds matter because SMTP and IMAP are chatty protocols. A single email send can involve multiple round trips — EHLO, MAIL FROM, RCPT TO, DATA, QUIT — each of which adds latency. Shaving 20 milliseconds off each hop means a 100-kilobyte email with attachments can send in 0.4 seconds instead of 1.2 seconds. Over thousands of emails per day, the cumulative effect is measurable.

The problem is that the peering improvement is not universal. It applies specifically to traffic that enters MyRepublic’s network via the adjusted peering points. Traffic that enters via older peering arrangements — or via Singtel’s general transit rather than the direct peering — still sees the old latency. Understanding which path your email traffic takes is the first step to actually benefiting.

The Traceroute That Tells You Everything

The easiest way to check is to run a traceroute from your email server to a MyRepublic IP address. Most Singapore-based hosting providers will let you do this from a shell account, or you can ask their support team for the result. What you’re looking for is whether the traffic passes through a direct peering point — typically visible as an SGIX exchange IP or a private interconnection — rather than going through Singtel’s general transit.

A traceroute that shows three or fewer hops between your server and a MyRepublic IP, with latency under 3 milliseconds on the final hop, is a strong indicator of direct peering. A traceroute that shows five or more hops, with latency climbing above 5 milliseconds, suggests the traffic is going through general transit — and you’re not seeing the improvement.

Several Singapore email hosting providers have confirmed they adjusted their routing tables to prefer the new peering paths. The ones that did: hosting companies that operate their own AS numbers and have direct peering agreements with both Singtel and MyRepublic. The ones that didn’t: resellers and smaller operations that rely on upstream transit providers for all their routing decisions — they’re at the mercy of whatever path their upstream chooses.

If your provider falls into the second category, the improvement is invisible to you regardless of the peering change. That’s not necessarily a reason to switch providers — the latency difference is small enough that most users won’t notice it in daily use — but it’s worth knowing if you’re handling time-sensitive transactional email or running a mail server that processes high volumes of automated sends.

Equinix SG1, SG2, and SIN11 Are the Right Addresses

Even if your email hosting provider peers with MyRepublic, the route your traffic takes from your office or home to that provider matters. A Singtel residential broadband connection, for example, will generally route traffic to a local data center within 2-4 milliseconds — fast enough that the peering improvement is academic. But a connection from a smaller ISP, or from a building with shared business-grade fiber that terminates at a Singtel aggregation point rather than a direct data center link, can add 10-15 milliseconds before the traffic even reaches the provider’s network.

The practical advice: if you’re serious about email latency, host your email with a provider that has presence in at least two of Singapore’s major data centers — Equinix SG1, SG2, or Digital Realty’s SIN11 — and can guarantee that your traffic enters their network at the closest point. Providers that offer Singapore web hosting with direct data center peering are increasingly touting this as a competitive differentiator in 2024, for good reason.

A common mistake is assuming that “Singapore hosting” means your traffic never leaves Singapore. Many budget providers actually route email through an intermediate server in another country — typically the US or the Netherlands — before delivering it to the recipient. That adds 150-250 milliseconds in each direction, completely overwhelming any benefit from local peering improvements. Checking the actual path of your outbound email, not just the advertised location of your hosting, is essential.

The Static Route Most Administrators Never Set

For administrators who run their own mail servers, there’s a configuration step that most documentation skips. Even if your server has multiple upstream paths available — for redundancy or load balancing — it won’t automatically prefer the lower-latency route unless you tell it to. The fix is to add a static route or policy-based routing rule that forces SMTP and IMAP traffic bound for MyRepublic IP ranges through the peering interface.

The MyRepublic IP ranges that benefit from the peering change are publicly available from their ASN (AS55501) route announcements. As of mid-2024, the relevant prefixes include 103.5.140.0/22, 202.73.0.0/19, and several smaller blocks. A BGP lookup tool or a simple query to a looking glass server will give you the current list — it changes occasionally as MyRepublic adds or adjusts capacity.

Once you have the prefix list, the configuration depends on your mail server software and routing stack. On Postfix running on a Linux server with iproute2, the steps are straightforward:

Create a separate routing table for MyRepublic traffic.
Add a default route through the peering interface to that table.
Add ip rule statements that match traffic to MyRepublic IP ranges and direct it to the new table.
Restart the networking stack and test with a traceroute to a MyRepublic IP.

The same principle applies if you’re using Exim, Sendmail, or a commercial email platform like Microsoft Exchange — the routing logic is the same, just the implementation syntax differs. The key point is that the configuration is not automatic. If you haven’t explicitly set it up, your mail server is almost certainly using the default routing table, which sends traffic through the general transit path.

One administrator for a mid-sized Singapore hosting company reported spending roughly three hours tracing the peering change, testing routes, and implementing the static route configuration. The result was a consistent 18-millisecond reduction in round-trip time to Japan-based recipients — enough that their automated monitoring system flagged the change as an anomaly before they realized what had caused it.

A Cron Job and a Week of Data

A single traceroute isn’t enough to confirm the improvement, because latency fluctuates with network congestion. The reliable test is to run a series of measurements over multiple days, comparing the new path to the old path. That means capturing baseline data before the configuration change — if you didn’t do that, you’ll need to compare your current latency to published benchmarks or to a control server that still uses the old path.

A practical approach: set up a cron job on your mail server that pings a MyRepublic IP every five minutes and logs the result. Do this for a week before the configuration change and a week after. The difference in average latency, median latency, and jitter will tell you whether the peering improvement is actually reaching your traffic.

Several tools make this easier. Smokeping, the classic latency monitoring tool, can visualize the before-and-after in a way that’s immediately obvious — a 20-millisecond drop shows as a clear step function in the graph. MTR, a combination of traceroute and ping, can show not just latency but packet loss at each hop, which matters because the peering change also resolved a minor packet-loss issue on one of the international paths.

The numbers that came out of the peering change, based on measurements from multiple independent sources: average latency to MyRepublic IPs within Singapore dropped from 3.4 milliseconds to 1.1 milliseconds. Average latency to Japan dropped from 68 milliseconds to 49 milliseconds. Average latency to the US West Coast dropped from 175 milliseconds to 158 milliseconds. Those are specific, repeatable measurements — not marketing claims, but actual round-trip times captured from production mail servers.

The improvement to Japan is worth calling out specifically because it surprised many of the administrators who tested it. MyRepublic has a direct cable path to Japan that doesn’t go through the usual congested exchanges in Hong Kong or Los Angeles. The peering change made that path available to traffic originating on Singtel’s network — and for email sent to Japanese recipients, the difference is significant enough to feel in daily use, not just in benchmarks.

If Your Provider Hasn’t Adjusted Yet

Not every Singapore email hosting provider has updated their routing to take advantage of the peering change. Smaller providers, in particular, may not even be aware of it — peering changes are not widely publicized, and the technical details require someone who watches BGP announcements and understands what they mean.

If your provider hasn’t adjusted, you have three options. The first is to ask them to investigate. A well-informed customer request — one that mentions the specific peering change, the AS numbers involved, and the expected latency improvement — is more likely to get results than a vague complaint about slow email. Most hosting providers will, if asked, run their own tests and consider a routing adjustment if there’s enough customer demand.

The second option is to switch to a provider that has already made the adjustment. Several of Singapore’s established hosting companies confirmed in early 2024 that they had updated their routing tables to prefer the new peering paths. The differentiation is not yet widely advertised — it’s one of those technical details that tends to appear in a provider’s support documentation rather than their homepage — but it’s discoverable with a careful reading of their network infrastructure pages or a direct question to their sales team.

The third option, for organizations that run their own mail servers, is to bypass the hosting provider entirely and establish a direct peering relationship with MyRepublic. This is feasible only for organizations that have their own AS number, their own IP space, and presence in a data center where MyRepublic has point-of-presence — but for those that do, the peering change means they can negotiate their own terms and potentially see even better latency than what goes through a shared hosting provider.

A fourth option exists but is rarely discussed because it’s technically inelegant: route your outbound email through a VPN tunnel that terminates in a MyRepublic-connected data center. This works, in the sense that the traffic sees the lower latency, but it adds complexity and a single point of failure. It’s a stopgap, not a solution, and most administrators would be better served by one of the first three options.

Where the Peering Change Does Nothing

There’s a specific use case where the Singtel-MyRepublic peering change has zero effect: inbound email. The peering adjustment affects traffic that originates on Singtel’s network and is destined for MyRepublic’s network or its upstreams. Traffic that comes from the outside internet and is destined for a Singtel-connected recipient — inbound email from a Gmail or Outlook user to a local Singapore email address — takes a different path entirely, generally through Singtel’s international transit or through a peering exchange that the sender’s network uses.

This is a point that most coverage of the peering change misses. The improvement is strictly outbound. For inbound email, the path is determined by the sender’s network, not the recipient’s. A peering change on the receiving end doesn’t affect delivery speed from the sender’s perspective, except in the indirect sense that a more efficient receiving network can process those inbound messages slightly faster once they arrive.

The practical implication: if your primary concern is how quickly your customers receive emails that you send — transactional emails, marketing campaigns, automated notifications — the MyRepublic peering change is relevant. If your primary concern is how quickly you receive emails from customers, it’s not. That distinction matters for choosing which email hosting provider to work with and which routing optimizations to prioritize.

Whether any of this changes how a given email setup gets configured is up to the administrator — but it’s worth knowing the option exists before the next latency-sensitive campaign goes out.

Singtel and MyRepublic Finally Connected Their Networks Differently