Five PoPs,
one map.

The five points of presence are Ljubljana (LJU, Slovenia, primary), Luxembourg City (LUX), Zurich (ZRH, Switzerland), Reykjavík (REK, Iceland), and Stockholm (ARN, Sweden). Frankfurt and Amsterdam are not points of presence in the dedicated sense — we do not operate cabinets there — but we maintain direct peering sessions at DE-CIX Frankfurt and AMS-IX Amsterdam with most major European mailbox providers. From a routing perspective, every packet that leaves a customer's MTA crosses our infrastructure for at most one or two hops before reaching the receiving network's edge — typically Gmail or Microsoft or Yahoo or ProtonMail or one of the smaller European providers we have direct peering with.

This is more important than it sounds. A typical hosting provider's path from a customer's MTA to Gmail looks like: customer → hosting provider's local switch → upstream carrier 1 → carrier 1's transit partner → carrier 1's transit partner's transit partner → Gmail. Five or six hops — three or four different operators — no single party with end-to-end visibility. When something throttles, the customer files a ticket and we begin the slow conversation with each upstream about which one of them changed something. Our path looks different: customer → BIG BOX local switch → BIG BOX backbone → direct peer (Gmail, at DE-CIX). Two hops, two operators, and we see every packet on our half of the path. When throttling appears, we can isolate it to either our side or Google's within minutes rather than days.

The most common question we get from prospects who have evaluated the standard cloud email infrastructure stack is why we operate five PoPs rather than thirty. The answer reveals a different philosophy. The big clouds optimise PoP count for marketing — "thirty PoPs across six continents" reads better in a procurement deck than "five PoPs across five EU jurisdictions" reads at first pass. The marginal latency improvement per added PoP after the first five is in the single digits of milliseconds for the major receiver clusters, which we showed in the latency map on the SMTP relay page. PoP count beyond five is decoration. It is not deliverability.

What matters operationally is jurisdictional diversity, not geographic count. Each of our five PoPs sits in a distinct legal regime — Luxembourg's Article 41 framework, Switzerland's non-EU adequacy, Iceland's IMMI press freedom, Sweden's Tryckfrihetsförordningen, Slovenia's post-U-I-65/13 retention-free profile. A buyer who needs legal-diversification redundancy can run a multi-jurisdiction deployment that genuinely covers different regulatory regimes, not just different physical locations within the same regime. Most "global edge networks" cannot offer this because they are built on AWS or GCP region maps, which optimise for technical redundancy within a single legal frame. We optimise the other dimension.

The cost of this choice is that we do not compete with hyperscale CDN networks on edge presence in every market. A buyer whose audience is concentrated in Singapore or São Paulo will see better latency from a vendor with edge in those regions. We tell them so during the discovery call. For senders whose audience is European or whose threat model values jurisdictional protection, the five-PoP shape is structurally correct. For senders whose audience is genuinely global and whose threat model does not care about jurisdiction, hyperscale providers are the better fit. The architectural choice produces a customer profile, not the other way round.

The BGP configuration we run is conservative by design. We announce the BIG BOX address space (a /22 IPv4 plus a /29 IPv6) from each of our five PoPs to the local internet exchange and to two transit providers per location. Each announcement carries the same AS-PATH prepending policy: zero prepends to the IX (preferred path), one prepend to transit (fallback), three prepends to backup transit (last resort). This produces the path selection behaviour that mailbox providers' BGP tables actually pick: when Google's edge router in Frankfurt sees our routes, it sees the IX path first because the AS-PATH is shorter, and it picks that path. Our packets land at Google's edge in roughly 8 milliseconds from Luxembourg via DE-CIX rather than the 24-30 millisecond round-trip a transit-routed path would take.

The asymmetric-path problem is the next-deepest layer. Our outbound path to Google is short (IX-direct). Google's inbound path back to us is whatever Google's BGP table prefers, and that path can be different from ours. For most providers this asymmetry is fine because the return-path performance does not affect SMTP throughput materially — SMTP is a request-response protocol where only one direction carries volume. For Microsoft and Yahoo specifically, we have observed return-path asymmetries that produce inconsistent connection-establishment behaviour during SMTP TLS negotiation; the fix is to maintain MED (multi-exit discriminator) values that signal Microsoft's BGP edge to prefer specific symmetric paths. We adjust MED per-peer as production behaviour reveals which return paths are problematic.

The last BGP detail worth mentioning is the IPv6 transition. We announce IPv4 and IPv6 from every PoP, and we configured both protocols with identical path-selection policies in 2019. By 2024, roughly 18 percent of our outbound mail to Gmail traverses IPv6 (matching Gmail's published IPv6 adoption curve). This matters operationally because IPv6 reputation is built differently from IPv4 reputation — Gmail in particular tracks the /64 prefix as the unit of reputation rather than the individual /128 address, which means a noisy IPv6 neighbour at the /64 prefix can affect everyone in that prefix. We allocate a /64 per dedicated IP customer to avoid this exact problem, which is a policy decision rather than a technical one.

We run two transit providers per PoP. The choice is calibrated against a specific failure mode: if one transit provider has a route leak or a peering dispute or a congestion event affecting traffic to a major mailbox provider, we want the second transit provider to give us a working path within the BGP convergence window (typically 30-90 seconds). The two providers are deliberately not the same Tier-1 carrier; we pair Cogent with GTT in some PoPs, Telia with Lumen in others, and rotate the second provider every 24 to 36 months as the transit market shifts. The rotation is operational hygiene — sticking with one provider for a decade produces silent path-quality degradation that is hard to notice without comparison.

The peering versus transit decision is per-prefix rather than per-provider. For Google or Microsoft or Yahoo or Apple plus most major European mailbox providers, we have direct peering at DE-CIX or AMS-IX or Locix; the IX path is preferred for those prefixes. For everything else (the long tail of receiving domains hosted by smaller ISPs or by self-managed mail servers), the transit path applies. About 78 percent of our outbound message volume traverses IX peering; the other 22 percent goes through transit. The 78/22 split varies by customer — a sender to enterprise B2B addresses sees a higher transit percentage because corporate mail servers are less likely to be at IX edges; a sender to consumer mailbox providers sees lower transit percentage.

Anycast is the technique most CDN networks use to give every PoP the same IP and let BGP routing pick the closest one. It is the right answer for HTTP-style workloads where any PoP can serve any request. It is the wrong answer for SMTP. SMTP has stateful connection establishment with TLS, and the connection lifecycle can outlast a BGP routing change; a TCP session that started at PoP A but had its return path shifted to PoP B mid-session breaks. For HTTP this is a TCP reset that the browser re-establishes silently. For SMTP this is a delivery failure that the receiving mailbox classifies as a soft bounce, which damages reputation. We use unicast IPs per PoP, with DNS-driven routing for new connections and stable per-PoP IPs for established sessions. This is the correct architecture for a transactional protocol with stateful connection behaviour, and it is one of the differences between an email-native network and a generic CDN network repurposed for email.