OpenPeppol has taken over the Peppol SML: why lookups against the old EC zone are silently stale

On 2 September 2026 OpenPeppol completed the takeover of the Service Metadata Locator (SML), the DNS-based directory that tells a sending Access Point where a recipient's metadata is published. Until then the SML had been hosted by the European Commission under edelivery.tech.ec.europa.eu. It is now operated by OpenPeppol under participant.sml.prod.tech.peppol.org. The change is technically small - a different DNS zone - but it has a side effect that is easy to miss: the old zone still answers, and its answers are increasingly wrong.

What changed, and when

• 19 March 2026 - migration window opens; the new OpenPeppol zone starts to mirror the EC zone.
• 31 May 2026 - deadline for SMP providers to move their registration (management) calls to the OpenPeppol endpoint.
• 31 August 2026 - deadline for Access Points and other lookup clients to switch DNS lookups to the new zone.
• 2 September 2026 - the OpenPeppol SML becomes the primary system; the EC environment is no longer part of the production chain.
• September 2026 - the EC zone is to be decommissioned at the Commission's discretion.

Why the old zone is dangerous rather than just obsolete

A decommissioned zone would fail loudly: every lookup would return "not found" and any monitoring would notice within minutes. The legacy EC zone does something worse. It keeps returning records, but SMP providers that have completed their migration no longer write to it. From the point of view of a client that still queries the old zone, three things happen silently:

• participants registered through a migrated SMP after its cut-over do not exist - the lookup returns "not registered";
• participants that moved from one provider to another appear to be with their old provider;
• participants deregistered by a migrated SMP still appear registered.

Nothing errors out. The data just stops moving for a growing share of the network, one SMP at a time.

What it looked like in our own data

We are writing this because it happened to us. Our provider attribution and the "routable / not routable" flag on every participant page are derived from SML lookups. Between 2 and 14 September 2026 those lookups still went to the legacy zone. We found out when Michael Walther from The Invoicing Hub sent us three examples where our page disagreed with the reference lookup at peppol.helger.com - a participant shown as not routable although it clearly was (registered through a migrated SMP on 13 September), and two participants shown with a previous provider after moving to Pennylane and to ITEMS respectively.

On 14 September we switched every lookup to the OpenPeppol zone and re-resolved the network overnight. The numbers give a sense of how quickly the two zones drift apart:

• Of about 183,000 participants we had marked as "not routable" and re-checked overnight, 3,532 (about 1.9 %) were in fact registered in the network - invisible to us only because their SMP had already migrated.
• Among participants registered in the week before the fix, the picture was far worse: in a sample of recent "not found" results, 9 out of 10 were false.
• Day on day, the number of participants with a provider attribution rose by about 39,000 - roughly three times a normal day - and 18,800 participants that had been listed as "unknown" received a provider. The largest gains were Pennylane (+8,558), Indy (+6,826), Banqup/Jefacture (+6,719), Saphety (+3,089) and Axway (+2,362); part of that is ordinary daily growth, the rest is the two zones catching up with each other.

The SMPs where the two zones differed most in our data were those that migrated early - among them Pennylane, Jefacture (Banqup), peppolint (ITEMS), eezi, Odoo, Storecove and Myflowin. Registrations made through SMPs that migrated late, or through the large national SMPs, were still identical in both zones.

Two consequences for readers of our statistics: the provider counts and the "not routable" figures moved on 15 September for technical reasons, not because of organic growth or churn; and any comparison of our data from 2-14 September with the live network should be treated with that in mind.

If you run your own Peppol lookups

Anyone who built participant verification, monitoring or analytics on the SML - integrators, ERP vendors, ID checkers, researchers - should check which zone their code queries. The production zone is iso6523-actorid-upis.participant.sml.prod.tech.peppol.org; the test zone (SMK) is iso6523-actorid-upis.participant.sml.test.tech.peppol.org. The hashing of the participant identifier (Base32 of SHA-256, U-NAPTR record) is unchanged, so the switch is a one-line configuration change. A quick way to verify a result is the participant lookup tool at peppol.helger.com, which already queries the OpenPeppol zone.

The lesson we take from it is broader than one migration: a discovery service that keeps answering after it stops being authoritative is a data-quality problem, not an availability problem, and it needs a different kind of check than uptime monitoring. On our side we now re-query the SML immediately whenever an SMP no longer knows a participant, refresh any participant page that is opened with data older than three days within the hour, and show a "Last verified" date on every participant page.

Acknowledgement

Our thanks go to Michael Walther from The Invoicing Hub, who for the second time took the trouble to compare our participant pages against the live network and to send precise, reproducible examples. Without them we would have noticed the drift only once the Commission switched the old zone off.