diff --git a/docs/pages/application-access/getting-started.mdx b/docs/pages/application-access/getting-started.mdx
index 9b107f121a734..7fcd5304f3da4 100644
--- a/docs/pages/application-access/getting-started.mdx
+++ b/docs/pages/application-access/getting-started.mdx
@@ -15,7 +15,11 @@ Let's connect to Grafana using Teleport Application Access in three steps:
 ## Prerequisites
 
 - We will use Docker to launch Grafana in a container. Alternatively, if you have another web application you'd like to protect with App Access, you can use that instead.
-- We will assume your Teleport cluster is accessible at `teleport.example.com` and `*.teleport.example.com`. Configured DNS records are required to automatically fetch a [Let's Encrypt](https://letsencrypt.org) certificate.
+- We will assume your Teleport cluster is accessible at `teleport.example.com` and `*.teleport.example.com`. Configured DNS records are required to automatically fetch a [Let's Encrypt](https://letsencrypt.org) certificate. 
+
+<Admonition type="note" title="Teleport and Wildcard Certificates">
+Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you need to create a DNS A record with a wildcard subdomain (e.g., `*.teleport.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
+</Admonition>
 
 ## Step 1/3. Start Grafana
 
@@ -41,6 +45,10 @@ using Let's Encrypt [ACME](https://letsencrypt.org/how-it-works/) protocol.
 We will assume that you have configured DNS records for `teleport.example.com`
 and `*.teleport.example.com` to point to the Teleport node.
 
+<Admonition type="note" title="Why do I need a wildcard certificate?">
+Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so the wildcard certificate enables clients to verify your Teleport hosts regardless of application.
+</Admonition>
+
 (!docs/pages/includes/permission-warning.mdx!)
 
 Let's generate a Teleport config with ACME enabled:
diff --git a/docs/pages/application-access/guides/connecting-apps.mdx b/docs/pages/application-access/guides/connecting-apps.mdx
index 4468d6544d894..282af90dd8c3c 100644
--- a/docs/pages/application-access/guides/connecting-apps.mdx
+++ b/docs/pages/application-access/guides/connecting-apps.mdx
@@ -54,6 +54,10 @@ applications. When setting up Teleport, the minimum requirement is a certificate
 for the proxy and a wildcard certificate for its sub-domain. This is where
 everyone will log into Teleport.
 
+<Admonition type="note" title="Why do I need a wildcard certificate?">
+Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so the wildcard certificate enables clients to verify your Teleport hosts regardless of application.
+</Admonition>
+
 In our example:
 
 - `teleport.example.com` will host the Access Plane.
diff --git a/docs/pages/database-access/getting-started.mdx b/docs/pages/database-access/getting-started.mdx
index 51e4f6ff3cc42..376313ecee750 100644
--- a/docs/pages/database-access/getting-started.mdx
+++ b/docs/pages/database-access/getting-started.mdx
@@ -83,8 +83,13 @@ our [downloads page](https://goteleport.com/teleport/download).
 Teleport requires a valid TLS certificate to operate and can fetch one automatically
 using Let's Encrypt [ACME](https://letsencrypt.org/how-it-works/) protocol.
 
-We will assume that you have configured DNS records for `teleport.example.com` and
-`*.teleport.example.com` to point to the node where you're launching Teleport.
+We will assume that you have configured a DNS record for `teleport.example.com` to point to the node where you're launching Teleport.
+
+<Details opened={false} title="Using Application Access?">
+Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you need to create a DNS A record with a wildcard subdomain (e.g., `*.teleport.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
+
+[Learn more about Teleport Application Access](../application-access/getting-started.mdx)
+</Details>
 
 Let's generate a Teleport config with ACME enabled:
 
diff --git a/docs/pages/getting-started/linux-server.mdx b/docs/pages/getting-started/linux-server.mdx
index f6a450cbd9872..d464173db3c6d 100644
--- a/docs/pages/getting-started/linux-server.mdx
+++ b/docs/pages/getting-started/linux-server.mdx
@@ -30,7 +30,13 @@ Take a look at the [Installation Guide](../installation.mdx) for more options.
 
 ### Configure DNS
 
-Teleport uses TLS to provide secure access to its Proxy Service and Auth Service, and this requires a domain name that clients can use to verify Teleport's certificate. To get started, set up two `A` records for `tele.example.com` and `*.tele.example.com` pointing to the IP/FQDN of the machine with Teleport installed.
+Teleport uses TLS to provide secure access to its Proxy Service and Auth Service, and this requires a domain name that clients can use to verify Teleport's certificate. To get started, set up a DNS `A` record for `tele.example.com` pointing to the IP/FQDN of the machine with Teleport installed.
+
+<Details opened={false} title="Using Application Access?">
+Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you will also need to create a DNS A record with a wildcard subdomain (e.g., `*.tele.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
+
+[Learn more about Teleport Application Access](../application-access/getting-started.mdx)
+</Details>
 
 <Admonition
   type="tip"
diff --git a/docs/pages/includes/database-access/start-auth-proxy.mdx b/docs/pages/includes/database-access/start-auth-proxy.mdx
index c9492a4a29472..c94cacfe6682c 100644
--- a/docs/pages/includes/database-access/start-auth-proxy.mdx
+++ b/docs/pages/includes/database-access/start-auth-proxy.mdx
@@ -17,6 +17,18 @@ Download the latest version of Teleport for your platform from our
 [downloads page](https://goteleport.com/teleport/download) and follow the
 installation [instructions](../../installation.mdx).
 
+<Details opened={false} title="Using Application Access?">
+Teleport assigns a
+subdomain to each application you have configured for Application Access (e.g.,
+`grafana.teleport.example.com`), so you will also need to create a DNS A record
+with a wildcard subdomain (e.g., `*.tele.example.com`).
+
+This way, Let's Encrypt can issue a wildcard certificate, enabling clients to
+verify your Teleport hosts regardless of the application they are accessing.
+
+[Learn more about Teleport Application Access](../../application-access/getting-started.mdx)
+</Details>
+
 Generate a Teleport configuration file with ACME enabled:
 
 ```code
diff --git a/docs/pages/kubernetes-access/getting-started/cluster.mdx b/docs/pages/kubernetes-access/getting-started/cluster.mdx
index 9e90424bd37b4..f83ae3b50dd0d 100644
--- a/docs/pages/kubernetes-access/getting-started/cluster.mdx
+++ b/docs/pages/kubernetes-access/getting-started/cluster.mdx
@@ -131,8 +131,13 @@ to create a public IP for Teleport.
   </TabItem>
 </Tabs>
 
-Set up two `A` DNS records - `tele.example.com` for UI and `*.tele.example.com`
-for web apps using [application access](../../application-access/introduction.mdx).
+You will also need to create a DNS A record for `tele.example.com` so clients can verify the TLS certificate of your Teleport hosts.
+
+<Details opened={false} title="Using Application Access?">
+Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you will also need to create a DNS A record with a wildcard subdomain (e.g., `*.tele.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
+
+[Learn more about Teleport Application Access](../../application-access/getting-started.mdx)
+</Details>
 
 <Tabs>
   <TabItem label="GCP Cloud DNS">
@@ -142,7 +147,6 @@ for web apps using [application access](../../application-access/introduction.md
 
     $ gcloud dns record-sets transaction start --zone="${MYZONE?}"
     $ gcloud dns record-sets transaction add ${MYIP?} --name="${MYDNS?}" --ttl="30" --type="A" --zone="${MYZONE?}"
-    $ gcloud dns record-sets transaction add ${MYIP?} --name="*.${MYDNS?}" --ttl="30" --type="A" --zone="${MYZONE?}"
     $ gcloud dns record-sets transaction describe --zone="${MYZONE?}"
     $ gcloud dns record-sets transaction execute --zone="${MYZONE?}"
     ```
diff --git a/docs/pages/kubernetes-access/helm/guides/aws.mdx b/docs/pages/kubernetes-access/helm/guides/aws.mdx
index 1e54b39653183..843acdb8bdfb2 100644
--- a/docs/pages/kubernetes-access/helm/guides/aws.mdx
+++ b/docs/pages/kubernetes-access/helm/guides/aws.mdx
@@ -302,9 +302,13 @@ $ kubectl --namespace teleport get all
 
 ## Step 6. Set up DNS
 
-You'll need to set up two DNS `A` records: `teleport.example.com` for the web UI, and `*.teleport.example.com`
-for web apps using [application access](../../../application-access/introduction.mdx). In our example, both records are
-aliases to an ELB.
+You'll need to set up a DNS `A` record for `teleport.example.com`. In our example, this record is an alias to an ELB.
+
+<Details opened={false} title="Using Application Access?">
+Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you will also need to create a DNS A record with a wildcard subdomain (e.g., `*.tele.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
+
+[Learn more about Teleport Application Access](../../../application-access/getting-started.mdx)
+</Details>
 
 Here's how to do this in a hosted zone with AWS Route 53:
 
@@ -340,18 +344,6 @@ $ jq -n --arg dns "${MYDNS?}" --arg elb "${MYELB?}" --arg elbz "${MYELB_ZONE?}"
                 "EvaluateTargetHealth": false
               }
             }
-          },
-          {
-            "Action": "CREATE",
-            "ResourceRecordSet": {
-              "Name": ("*." + $dns),
-              "Type": "A",
-              "AliasTarget": {
-                "HostedZoneId": $elbz,
-                "DNSName": ("dualstack." + $elb),
-                "EvaluateTargetHealth": false
-              }
-            }
           }
       ]
     }' > myrecords.json
diff --git a/docs/pages/kubernetes-access/helm/guides/gcp.mdx b/docs/pages/kubernetes-access/helm/guides/gcp.mdx
index 74b02029d3c48..91d7e6a99a2b6 100644
--- a/docs/pages/kubernetes-access/helm/guides/gcp.mdx
+++ b/docs/pages/kubernetes-access/helm/guides/gcp.mdx
@@ -346,8 +346,13 @@ $ kubectl --namespace teleport get all
 
 ## Step 6. Set up DNS
 
-You'll need to set up two DNS `A` records: `teleport.example.com` for the web UI, and `*.teleport.example.com`
-for web apps using [application access](../../../application-access/introduction.mdx).
+You'll need to set up a DNS `A` record for `teleport.example.com`.
+
+<Details opened={false} title="Using Application Access?">
+Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you will also need to create a DNS A record with a wildcard subdomain (e.g., `*.tele.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
+
+[Learn more about Teleport Application Access](../../../application-access/getting-started.mdx)
+</Details>
 
 Here's how to do this using Google Cloud DNS:
 
@@ -362,7 +367,6 @@ $ MYDNS="teleport.example.com"
 
 $ gcloud dns record-sets transaction start --zone="${MYZONE?}"
 $ gcloud dns record-sets transaction add ${MYIP?} --name="${MYDNS?}" --ttl="300" --type="A" --zone="${MYZONE?}"
-$ gcloud dns record-sets transaction add ${MYIP?} --name="*.${MYDNS?}" --ttl="300" --type="A" --zone="${MYZONE?}"
 $ gcloud dns record-sets transaction describe --zone="${MYZONE?}"
 $ gcloud dns record-sets transaction execute --zone="${MYZONE?}"
 ```
diff --git a/docs/pages/kubernetes-access/helm/reference.mdx b/docs/pages/kubernetes-access/helm/reference.mdx
index d803ae51ad29f..4b0aae9ae7ff0 100644
--- a/docs/pages/kubernetes-access/helm/reference.mdx
+++ b/docs/pages/kubernetes-access/helm/reference.mdx
@@ -44,8 +44,9 @@ This reference details available values for the `teleport-cluster` chart.
 
   (!docs/pages/kubernetes-access/helm/includes/kubernetes-externaladdress.mdx!)
 
-  You will need to manually add DNS records pointing `teleport.example.com` and `*.teleport.example.com` to either the IP or hostname
-  of the Kubernetes load balancer.
+  You will need to manually add a DNS A record pointing `teleport.example.com` to either the IP or hostname of the Kubernetes load balancer.
+
+  If you are using Teleport Application Access, you will also need to add a DNS A record for `*.teleport.example.com`. This is because Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so the wildcard enables clients to verify your Teleport hosts regardless of application.
 
   If you are not using ACME certificates, you may also need to accept insecure warnings in your browser to view the page successfully.
 </Admonition>