How the Peppol Network Works Technically (With DNS Logic)

While trying to understand Peppol, terms like SML, SMP, Access Point, Participant ID can seem like a lot to memorize. But the essence of it comes down to one basic question:

“How do I deliver an electronic document securely to the right organization and the right technical endpoint?”

This is exactly the problem the Internet has been solving for years with DNS. The Peppol architecture rebuilds the delegation and resolution chain we know from DNS for organizations and e-documents.


What is the Peppol Network?

Peppol is neither a centralized platform nor a single software product.
You can think of it like the internet: rules, roles, technical standards, and a trust framework are defined; everyone builds their system to comply with these rules. No one operates Peppol — yet everyone can exchange documents on the same network by being Peppol-compliant.


The Main Idea That Directly Maps to DNS

For DNS, the core question is:
“Where is this named thing on the network?”

In Peppol, the question is the same:
“Where is the document receiver endpoint for this Participant ID?”

A Participant ID — e.g., 0088:5790000435968 — is like example.com in DNS. No one thinks about IP addresses; everyone says “Send it to this participant”, and the rest is resolved by the lookup chain. 


SML: The Root Directory (Like DNS Root Servers)

When a Participant ID is given, the first question to answer is:

“Which SMP holds this organization’s technical records?”

SML holds that directory information. It doesn’t know about documents, access points, or formats — it only says “This participant’s records are at this SMP”.
This is exactly like DNS root zone → TLD delegation.


SMP: Authoritative Technical Record (Like Authoritative DNS)

SMP is where the authoritative records for a specific participant are kept. Here we find:

  • Supported document types and processes
  • Supported formats (e.g., UBL)
  • Which Access Point to use
  • Technical endpoint and protocol details

Just as DNS has IP/MX/SRV records, Peppol’s SMP contains this information — and it doesn’t have to be centrally hosted; each organization or service provider can host its own SMP.


Endpoint and Access Point

The final resolution informs the sender:

“This participant accepts documents through this Access Point with this AS4 endpoint.”

No data is ever sent before this resolution happens.
The Access Point layer handles the actual communication:

  • AS4 messaging
  • Certificate validation
  • Signing and encryption
  • Retries and delivery receipts
Link:  Essential Concepts for Modern Cloud Architecture: A Complete Technical Glossary

Sender and receiver systems never talk directly — just like email servers communicate with each other, it’s always Access Point → Access Point.


Peppol Flow (Like the DNS Resolution Chain)

  1. The system says “This document goes to this participant.”

  2. The sender’s Access Point checks SML.

  3. SML returns the relevant SMP.

  4. SMP provides Access Point + endpoint details.

  5. The sender’s Access Point connects to the receiver’s Access Point and delivers the message.

This flow mirrors DNS — no HTTP request is sent before resolution is complete.


Multiple Access Points & SMP Distribution

Just like DNS can support multiple IPs (for load balancing/failover) for the same domain, Peppol allows multiple Access Points or regional deployments for the same participant. Also, the SMP and Access Point do not need to be hosted by the same provider. In DNS, one company can host authoritative DNS while another hosts the web server — in Peppol, this separation is common too. 


Why Is It Designed This Way?

The goal is to ensure the network doesn’t stop when one country, company, or platform fails. There is no central system or single point of failure; everyone takes responsibility for their own part. While this may seem complex at first and require effort to set up, it provides a highly reliable distributed architecture in the long run.


Short Technical Summary

  • Peppol = DNS-like resolution + secure transport for e-documents
  • Participant ID = domain name
  • SML = root directory
  • SMP = authoritative technical record
  • Access Point = actual communication server
  • No data is ever sent before the lookup chain is completed

When viewed this way, you can clearly see why Peppol is so layered and structured: its goal is to build a reliable, distributed document delivery network on a global scale. F.M. Arslan