diff --git a/docs/configuring-well-known.md b/docs/configuring-well-known.md
index 53a353860..81caf04cb 100644
--- a/docs/configuring-well-known.md
+++ b/docs/configuring-well-known.md
@@ -15,7 +15,7 @@ All services created by this playbook are meant to be installed on their own ser
 
 As [per the Server-Server specification](https://matrix.org/docs/spec/server_server/r0.1.0.html#server-discovery), to use a Matrix user identifier like `@<username>:<your-domain>` while hosting services on a subdomain like `matrix.<your-domain>`, the Matrix network needs to be instructed of such delegation/redirection.
 
-Server delegation can be configured using DNS SRV records or by setting up a `/.well-known/matrix/server` file on the base domain (`<your-domain.com>`).
+Server delegation can be configured using DNS SRV records or by setting up a `/.well-known/matrix/server` file on the base domain (`<your-domain>`).
 
 Both methods have their place and will continue to do so. You only need to use just one of these delegation methods.
 For simplicity reasons, our setup advocates for the `/.well-known/matrix/server` method and guides you into using that.
@@ -116,12 +116,12 @@ With this method, you **don't need** to add special HTTP headers for [CORS](http
 **For nginx**, it would be something like this:
 
 ```nginx
-# This is your HTTPS-enabled server for DOMAIN.
+# This is your HTTPS-enabled server for example.com.
 server {
-	server_name DOMAIN;
+	server_name example.com;
 
 	location /.well-known/matrix {
-		proxy_pass https://matrix.DOMAIN/.well-known/matrix;
+		proxy_pass https://matrix.example.com/.well-known/matrix;
 		proxy_set_header X-Forwarded-For $remote_addr;
 	}
 
@@ -133,11 +133,11 @@ server {
 
 ```apache
 <VirtualHost *:443>
-	ServerName DOMAIN
+	ServerName example.com
 
 	SSLProxyEngine on
-	ProxyPass /.well-known/matrix https://matrix.DOMAIN/.well-known/matrix nocanon
-	ProxyPassReverse /.well-known/matrix https://matrix.DOMAIN/.well-known/matrix nocanon
+	ProxyPass /.well-known/matrix https://matrix.example.com/.well-known/matrix nocanon
+	ProxyPassReverse /.well-known/matrix https://matrix.example.com/.well-known/matrix nocanon
 
 	# other configuration
 </VirtualHost>
@@ -146,30 +146,10 @@ server {
 **For Caddy 2**, it would be something like this:
 
 ```caddy
-DOMAIN.com {
-   @wellknown {
-         path /.well-known/matrix/*:x
-   }
-
-   handle @wellknown {
-      reverse_proxy https://matrix.DOMAIN.com {
-          header_up Host {http.reverse_proxy.upstream.hostport}
-      }
-   }
-    # Configration for the base domain goes here
-  # handle {
-  #    header -Server
-  #     encode zstd gzip
-  #    reverse_proxy localhost:4020
-  # }
-}
-```
-
-**For Caddy 1**, it would be something like this:
-
-```caddy
-proxy /.well-known/matrix/ https://matrix.DOMAIN {
-    header_upstream Host {http.reverse_proxy.upstream.hostport}
+example.com {
+	reverse_proxy /.well-known/matrix/* https://matrix.example.com {
+		header_up Host {upstream_hostport}
+	}
 }
 ```
 
@@ -196,7 +176,7 @@ backend matrix-backend
 
 ```
 # In the _redirects file in the website's root
-/.well-known/matrix/* https://matrix.DOMAIN/.well-known/matrix/:splat 200!
+/.well-known/matrix/* https://matrix.example.com/.well-known/matrix/:splat 200!
 ```
 
 **For AWS CloudFront**
@@ -206,7 +186,7 @@ backend matrix-backend
 
 Make sure to:
 
-- **replace `DOMAIN`** in the server configuration with your actual domain name
+- **replace `example.com`** in the server configuration with your actual domain name
 - and: to **do this for the HTTPS-enabled server block**, as that's where Matrix expects the file to be