Home/Blog/How PEPPOL SMP and SML discovery works

How PEPPOL SMP and SML discovery works

The DNS-based participant lookup chain that allows PEPPOL access points to find each other without a central broker.

One of the common questions about PEPPOL is: how does one access point know where to deliver a document? If you are a Swiss supplier connected to access point A, and your German customer is connected to access point B, how does A find B — and the exact URL to send to?

The answer is a two-level directory system built on top of standard DNS. Understanding it helps when troubleshooting a delivery failure, registering as a new participant, or building software that sends PEPPOL documents.

The two components: SML and SMP

SML (Service Metadata Locator) is a central DNS-based registry operated by OpenPEPPOL. It knows which SMP is responsible for each registered PEPPOL participant. It does not hold delivery details itself — it just points you to the right place to ask.

SMP (Service Metadata Publisher) is a registry run by each access point provider for its own participants. The SMP knows which document types each participant can receive and the endpoint URL where messages should be delivered.

The lookup chain: SML tells you which SMP to ask, and the SMP gives you the actual delivery address. Two steps, and you can reach any participant on the network without a central system that handles live traffic.

Step 1: From participant ID to SMP hostname via DNS

Every PEPPOL participant has an identifier. For Swiss businesses, this is typically 0209:CHE1162817100 — scheme 0209 (Swiss UID) followed by the nine-digit UID without separators.

To find the SMP for a participant, the lookup process hashes the participant ID with MD5 and constructs a DNS hostname:

B-<MD5 hash of participant ID>.<SML domain>

For the production SML, the domain is edelivery.tech.ec.europa.eu. A lookup for participant 0209:CHE1162817100 becomes a DNS query for something like:

B-9a3b1c2d4e5f6a7b8c9d0e1f.iso6523-actorid-upis.edelivery.tech.ec.europa.eu

The DNS response is a CNAME record pointing to the SMP hostname responsible for that participant. This is a regular DNS lookup — no special protocol, no API key. The participant ID just gets turned into a deterministic hostname.

Step 2: Querying the SMP for endpoint details

Once you have the SMP hostname, you query it over HTTPS. The SMP exposes a REST API defined in the PEPPOL specification. A typical request looks like:

GET https://<smp-hostname>/0209:CHE1162817100/services/<document-type-identifier>

The document type identifier is the full PEPPOL string for the document you want to send — for a PEPPOL BIS Billing 3.0 invoice it is a long URN that specifies the UBL schema, the EN 16931 customisation, and the billing profile.

The SMP responds with an XML document that includes:

<ServiceEndpoint>
  <transportProfile>busdox-transport-as4-v2p0</transportProfile>
  <EndpointURI>https://ap.example-provider.ch/as4</EndpointURI>
  <Certificate>MIIBxDCCAW6gAwIBAgIJ...</Certificate>
  <ServiceActivationDate>2024-01-01</ServiceActivationDate>
  <ServiceExpirationDate>2026-12-31</ServiceExpirationDate>
</ServiceEndpoint>

The endpoint URL is where the actual invoice will be delivered. The certificate is used to verify the receiving access point and encrypt the message in transit. With these two pieces of information, the sending access point can deliver the document directly to the receiving access point using AS4 transport.

What happens when a participant is not found

If the DNS lookup in step 1 returns NXDOMAIN, the participant is not registered in the SML. Either they are not on the PEPPOL network, or their registration has been removed.

If the DNS lookup succeeds but the SMP query in step 2 returns nothing for the requested document type, the participant is registered but does not support that document type. You cannot send them an invoice via PEPPOL. They would need to update their SMP registration to add that document type, or you use a different delivery channel.

Both situations surface as errors in your access point logs. Most providers translate them into plain messages like "participant not found" or "document type not supported for this recipient", but the underlying cause is always the same: a missing SML entry or a missing SMP service record.

Registering as a PEPPOL participant

When you sign up with a PEPPOL access point provider in Switzerland, they handle the SML and SMP registration for you. They:

  1. Register your participant ID in the SML, which creates the DNS entry
  2. Publish an SMP record for you listing the document types you accept
  3. Set the delivery endpoint to their AS4 server

You do not touch the SML or SMP directly. What you provide is your PEPPOL participant ID (your UID) and the document types you want to support. The guide to registering as a PEPPOL participant in Switzerland covers the practical steps with your access point provider.

Caching and propagation delays

DNS records have a TTL. SML entries typically have a TTL of several hours. If a participant registers today, sending access points that already cached an NXDOMAIN response will not see the new registration until their cache expires — which can take a few hours.

SMP records are not DNS-cached. Each SMP query fetches live data from the access point's SMP server. However, sending access points often cache SMP responses locally for performance. If a participant switches access point providers, some senders may keep routing to the old endpoint until their SMP cache clears. Most migrations allow a grace period on the old provider's side to handle this.

Why DNS instead of a central lookup API

The design is intentional. The SML only answers directory queries — it never handles live document traffic. Once a sender has the endpoint from the SMP, documents flow directly between the two access points with no central intermediary. This keeps the network decentralised and avoids a bottleneck at the centre.

It also means that if the SML were temporarily unavailable, access points could still deliver to participants whose endpoint addresses they have already cached. The DNS foundation makes the directory resilient without requiring complex infrastructure.

For what happens after the endpoint is found — how the AS4 message is constructed and delivered — the PEPPOL AS4 transport post covers that step. For the bigger picture of how a four-corner PEPPOL delivery works, see the four-corner model explained.