It is convenient to point a webhook at http://localhost, a private service name, or a URL containing a password. It is also a way to send correspondence metadata over an unprotected connection, leak credentials into logs, or make RelayLink connect somewhere no webhook should reach.
RelayLink posts only over HTTPS to publicly routable addresses. That is not one check pretending to solve every problem. TLS, URL rules, and connection-time address vetting each close a different gap.
HTTPS protects the envelope in transit
A package webhook is deliberately smaller than the package, but it is not empty metadata. It includes the sender's name and email address, the topic, package and thread identifiers, the time, and whether the package is a reply.
Plain HTTP exposes those fields to networks between RelayLink and the receiver. It also exposes the delivery id and signed request, which can be captured and replayed while the receiver still considers the timestamp fresh.
HTTPS provides confidentiality and integrity for the connection. It also lets RelayLink authenticate the hostname through the server certificate. A valid certificate does not prove the application behind it is your intended receiver, but it prevents ordinary network interception from silently becoming that receiver.
The webhook signature still matters. TLS tells RelayLink which host answered; HMAC tells your application that RelayLink produced these exact bytes for this subscription. Neither is a substitute for the other.
A webhook URL must not become an internal network probe
RelayLink is the machine making the outbound connection. If it accepted any address an account supplied, a URL could point it at loopback, a private database, a link-local service, or cloud instance metadata. The response does not have to be shown to the caller for that to be dangerous; causing requests to internal systems is already server-side request forgery.
The receiver must therefore resolve to a globally routable public address. A registration-time lookup gives the account holder a useful refusal when a hostname clearly points only to private space.
That first lookup is not the security boundary. A name that does not resolve yet may still be saved, and DNS can change after registration. No delivery bypasses the connection-time public-address check.
Connection-time checks resist DNS rebinding
DNS rebinding exploits that gap. A hostname can resolve to a public address when inspected, then resolve to a private address when the HTTP client connects. Code that validates once and later dials the hostname has checked one destination and contacted another.
RelayLink resolves the host for each attempt, keeps only publicly routable addresses, and connects to the vetted address. It does not simply hand the original hostname to an unconstrained client after validation.
Redirects are not followed either. A redirect could move the POST to another host whose address was never approved for that attempt. A 301, 302, or other redirect is a receiver failure to fix, not a path RelayLink follows.
This policy also explains why a receiver on localhost, a home LAN, or a private cloud subnet cannot receive RelayLink POSTs directly. Put a controlled public HTTPS ingress in front of it. That ingress should terminate TLS, preserve the raw request body for signature verification, and forward only after authentication.
URL credentials and fragments are the wrong controls
RelayLink refuses webhook URLs containing user information such as https://name:password@example.com/hook. Embedded credentials are copied into deployment settings, diagnostics, proxy data, shell history, and screenshots too easily. The subscription's whsec_ secret and signed headers are the authentication contract.
Fragments are refused as well. The #fragment portion of a URL is handled by a browser and is not sent in an HTTP request. Allowing one would suggest that it selects or protects a server route when the receiver never sees it.
A path may carry a routing token, and RelayLink treats webhook paths as sensitive for that reason: its logs use the subscription id, and account notices expose only the host. A path token can be defense in depth, but it must not be the only authentication. Verify the HMAC every time.
What the requirement does not promise
HTTPS does not make a receiver reliable, authorize it to fetch a package, or prove anyone read the message. Your endpoint must still verify the signature and timestamp, deduplicate delivery ids, and fetch through /mcp with a separate account credential.
The requirement provides a safer road to the receiver. What the receiver does after arrival remains your responsibility.