diff --git a/src/content/docs/byoip/service-bindings/magic-transit-with-cdn.mdx b/src/content/docs/byoip/service-bindings/magic-transit-with-cdn.mdx
index 372e8a427475be5..2a2b7fb08871772 100644
--- a/src/content/docs/byoip/service-bindings/magic-transit-with-cdn.mdx
+++ b/src/content/docs/byoip/service-bindings/magic-transit-with-cdn.mdx
@@ -11,7 +11,7 @@ import { Details, Example, TabItem, Tabs, GlossaryTooltip } from "~/components";
 
 [Magic Transit](/magic-transit/) customers using BYOIP can also benefit from the performance, reliability, and security that Cloudflare offers for HTTP-based applications.
 
-This documentation covers using the Cloudflare API to configure [service bindings](/byoip/service-bindings/) within Cloudflare's IP Address Management framework. Service bindings allow BYOIP customers to selectively route traffic on a per-IP address basis to the CDN pipeline (which includes [Cache](/cache/), [Web Application Firewal (WAF)](/waf/), and more).
+This documentation covers using the Cloudflare API to configure [service bindings](/byoip/service-bindings/) within Cloudflare's IP Address Management framework. Service bindings allow BYOIP customers to selectively route traffic on a per-IP address basis to the CDN pipeline (which includes [Cache](/cache/), [Web Application Firewall (WAF)](/waf/), and more).
 
 It is also possible to define service bindings to route traffic to the Spectrum pipeline selectively. However, this is not in the scope of this guide.
 
@@ -19,7 +19,7 @@ It is important to note that traffic routed to the CDN pipeline is protected at
 
 ## Before you begin
 
-Efficiency is paramount when planning how you will implement service bindings. Implementing service bindings through an aggregated CIDR block is strongly recommended.
+Although it is possible to add discrete bindings for non-contiguous CIDR blocks, implementing service bindings through an **aggregated** CIDR block is **strongly** recommended as it is more efficient.
 
   <Details header="Example" >
 
@@ -27,21 +27,24 @@ Efficiency is paramount when planning how you will implement service bindings. I
 
   **IPs to upgrade to the CDN:**
 
-  `203.0.113.16`
-  `203.0.113.17`
-  `203.0.113.18`
-  `203.0.113.19`
-  `203.0.113.20`
-  `203.0.113.21`
-  `203.0.113.22`
+  `203.0.113.16`<br />
+  `203.0.113.17`<br />
+  `203.0.113.18`<br />
+  `203.0.113.19`<br />
+  `203.0.113.20`<br />
+  `203.0.113.21`<br />
+  `203.0.113.22`<br />
   `203.0.113.23`
 
-  **Best practice:** Add one discrete CDN service binding for `203.0.113.16` with a `/29` netmask.
+	Add one discrete CDN service binding for `203.0.113.16` with a `/29` netmask.
 
   </Details>
 
-Once a service binding is created (or deleted), it will take four to six hours to propagate across Cloudflare's global network. Services for the IP addresses in scope will likely be disrupted during this window.
+Once a service binding is created (or deleted), it will take **four** to **six** hours to propagate across Cloudflare's global network. Services for the IP addresses in scope will likely be disrupted during this window.
 
+:::note
+This guide assumes that the prefix is tied to a single Cloudflare account that has both Magic Transit and CDN properties. If you are using [prefix delegations](/byoip/concepts/prefix-delegations/), the service bindings must be [created](#2-create-service-binding) on the parent account.
+:::
 
 ## 1. Get account information
 
@@ -129,7 +132,7 @@ You can choose between two different scopes:
 * Zone-level: uses the address map for all proxied DNS records within a zone.
 
 :::note
-If you need to map only specific subdomains to specific IP addresses - and not all proxied DNS records -, you can use a [Subdomain setup](/dns/zone-setups/subdomain-setup/).
+If you need to map only specific subdomains (and not all proxied DNS records) to specific IP addresses, you can use a [Subdomain setup](/dns/zone-setups/subdomain-setup/).
 :::
 
 <Tabs labels="Dashboard | API">
@@ -199,9 +202,9 @@ At this point, if an address map for a zone `example.com` specifies that Cloudfl
 4. As the HTTP response egresses the Cloudflare network back to the client side, the source IP address of the response becomes `203.0.113.100` (the IP address that the HTTP request originally landed on).
 
 </Details>
-
+:::note
 Having the same IP address as ingress IP (defined in the address map) and origin IP (listed in the DNS record) will not cause any loops.
-
+:::
 <Details header="Example" >
 
 Assuming `203.0.113.100` was also the origin IP, the DNS record would look like the following:
@@ -212,7 +215,7 @@ Assuming `203.0.113.100` was also the origin IP, the DNS record would look like
 
 </Details>
 
-## 5.(Optional) Add layer 7 functionality
+## 5. (Optional) Add layer 7 functionality
 
 Leverage other features according to your needs: