CPS & EPP Poll Notifications

Overview

DNS Belgium provides two complementary mechanisms for delivering system notifications to registrars:

• EPP Poll (primary channel) – an asynchronous, machine-driven message queue

• CPS e-mails (fallback channel) – immediate, human-readable notifications

Both mechanisms are built on a shared event model, ensuring that the same events, data, and semantics are delivered regardless of transport.

Please find an overview of our notification in CPS and Poll Messages

EPP Poll

Purpose

The EPP Poll command allows registrars to retrieve messages asynchronously from the registry. Messages are generated whenever relevant actions occur, such as domain lifecycle events, contact updates, and operational notifications.

Poll is based on the standard EPP mechanism defined in RFC 4930 and is the recommended integration method.

How It Works

1. The registrar enables EPP Poll in their profile.

2. The registry queues all generated messages.

3. The registrar retrieves messages using <poll op="req">.

4. The oldest message in the queue is returned.

5. The registrar acknowledges the message using <poll op="ack">.

6. The message is removed and the next message becomes available.

The process continues until the queue is empty.

Key Characteristics

• Messages are processed in FIFO order.

• Every message has a unique server-generated identifier.

• Each message must be acknowledged exactly once.

• Unacknowledged messages remain available for up to one year.

• The same message is returned repeatedly until it has been acknowledged.

Poll Response Structure

A poll response typically contains:

• Number of pending messages.

• Unique message identifier.

• Queue timestamp (UTC).

• Event or action type.

• Status or return code.

• Transaction type.

Depending on the notification type, responses may additionally include:

• Domain name.

• Contact alias.

• Email address.

• Watermark value.

• Error details.

• Registry object identifiers.

Rate Limits

• Maximum of 60 poll requests per minute per IP address.

• Successfully acknowledging a message resets the poll request quota, allowing efficient processing of message queues.

Operational Recommendations

• Poll at least twice per day.

• Automate retrieval, processing and acknowledgement.

• Treat Poll as the authoritative notification channel.

CPS (Customer Processing System) E-mails

Purpose

CPS e-mails provide an alternative notification mechanism when EPP Poll is not enabled.

• If Poll is enabled, notifications are delivered through the Poll queue.

• If Poll is disabled, notifications are sent immediately via e-mail to the configured automated address.

Role in the System

CPS is intended for:

• Human-readable notifications.

• Operational monitoring.

• Fallback delivery.

While CPS messages contain equivalent information, Poll remains the preferred integration mechanism.

Consistency with Poll

CPS notifications mirror Poll messages:

• Identical event types.

• Identical lifecycle triggers.

• Consistent object identifiers.

To guarantee consistency:

• Structured CPS content uses A-labels.

• Human-readable subjects and message bodies use U-labels.

CPS Message Specification

A CPS e-mail consists of three logical sections:

1. Metadata

2. Human-readable content

3. Structured CPS section

Metadata

Standard e-mail headers include:

• Subject

• Recipient

• Date

Example:

Transfer Completed (example.be)

Human-readable Section

This section:

• Uses Unicode domain names (U-labels).

• Describes the event in natural language.

• May include operational guidance.

Structured CPS Section

This section ensures CPS messages can be parsed and correlated with Poll messages.

General rules:

• Is clearly delimited (e.g. header marker like [CPS])

• Contains A-label values

• Deterministic and stable

• Maps 1:1 with a Poll message event

Example:

[CPS]

eventType: TRANSFER_COMPLETED
objectType: domain
domainName: example.be
timestamp: 2026-01-15T10:12:45Z
status: SUCCESS
transactionId: ABC-12345

Field Definitions

Field	Required	Description
eventType	Yes	Type of event (e.g. TRANSFER_COMPLETED, CONTACT_DELETED)
objectType	Yes	Affected object.
domainName	Conditional	Domain name in A-label format.
contactAlias	Conditional	Contact identifier.
timestamp	Yes	Event time in UTC using ISO-8601 format.
status	Yes	Outcome or state change.
transactionId	Optional	Correlation identifier with the corresponding EPP transaction.

Relationship Between Poll and CPS

Poll and CPS represent the same underlying events but use different delivery mechanisms.

Poll

• Pull-based API.

• Intended for automation.

• Structured EPP XML.

• Authoritative source of notifications.

CPS

• Push-based e-mail.

• Intended for operators and monitoring.

• Human-readable with a structured section.

• Derived representation of Poll notifications.

Each CPS notification MUST correspond to a single Poll message.

This guarantees:

• Consistency across channels.

• Reliable event reconciliation.

• Predictable automation behaviour.

Supported Notifications

The notification framework covers, among others:

• Domain transfers.

• Domain revocations and restorations.

• Contact monitoring and verification.

• Name server and DNS changes.

• Domain Shield events.

• Domain Guard events.

• Watermark and hitpoint alerts.

• Email delivery failures.

• Registry operational notifications.

Best Practices

• Use Poll as the primary integration mechanism.

• Acknowledge messages as soon as possible.

• Implement idempotent message processing.

• Use CPS for monitoring and fallback alerting.

• Correlate events using:

  • Object identifiers.

  • Timestamps.

  • Transaction identifiers.

Summary

• EPP Poll is the authoritative asynchronous notification mechanism.

• CPS provides equivalent notifications via e-mail when Poll is disabled.

• Both channels rely on the same event model.

• CPS includes a structured section designed to mirror Poll data and support automated processing.