diff --git a/django/conf/global_settings.py b/django/conf/global_settings.py
index 8e57f5f5db..544cbc10cb 100644
--- a/django/conf/global_settings.py
+++ b/django/conf/global_settings.py
@@ -452,7 +452,7 @@ SESSION_CACHE_ALIAS = 'default'
 SESSION_COOKIE_NAME = 'sessionid'
 # Age of cookie, in seconds (default: 2 weeks).
 SESSION_COOKIE_AGE = 60 * 60 * 24 * 7 * 2
-# A string like ".example.com", or None for standard domain cookie.
+# A string like "example.com", or None for standard domain cookie.
 SESSION_COOKIE_DOMAIN = None
 # Whether the session cookie should be secure (https:// only).
 SESSION_COOKIE_SECURE = False
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
index 6a9a06e7f7..850a30dfc9 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -752,10 +752,9 @@ Methods
       in UTC. If ``expires`` is a ``datetime`` object, the ``max_age``
       will be calculated.
     * Use ``domain`` if you want to set a cross-domain cookie. For example,
-      ``domain=".lawrence.com"`` will set a cookie that is readable by
-      the domains www.lawrence.com, blogs.lawrence.com and
-      calendars.lawrence.com. Otherwise, a cookie will only be readable by
-      the domain that set it.
+      ``domain="example.com"`` will set a cookie that is readable by the
+      domains www.example.com, blog.example.com, etc. Otherwise, a cookie will
+      only be readable by the domain that set it.
     * Use ``httponly=True`` if you want to prevent client-side
       JavaScript from having access to the cookie.
 
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 3e171c8d3d..4c1b5eb0d7 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -309,7 +309,7 @@ Default: ``None``
 The domain to be used when setting the CSRF cookie.  This can be useful for
 easily allowing cross-subdomain requests to be excluded from the normal cross
 site request forgery protection.  It should be set to a string such as
-``".example.com"`` to allow a POST request from a form on one subdomain to be
+``"example.com"`` to allow a POST request from a form on one subdomain to be
 accepted by a view served from another subdomain.
 
 Please note that the presence of this setting does not imply that Django's CSRF
@@ -1733,8 +1733,8 @@ The age of the language cookie, in seconds.
 Default: ``None``
 
 The domain to use for the language cookie. Set this to a string such as
-``".example.com"`` (note the leading dot!) for cross-domain cookies, or use
-``None`` for a standard domain cookie.
+``"example.com"`` for cross-domain cookies, or use ``None`` for a standard
+domain cookie.
 
 Be cautious when updating this setting on a production site. If you update
 this setting to enable cross-domain cookies on a site that previously used
@@ -2958,8 +2958,8 @@ The age of session cookies, in seconds.
 Default: ``None``
 
 The domain to use for session cookies. Set this to a string such as
-``".example.com"`` (note the leading dot!) for cross-domain cookies, or use
-``None`` for a standard domain cookie.
+``"example.com"`` for cross-domain cookies, or use ``None`` for a standard
+domain cookie.
 
 Be cautious when updating this setting on a production site. If you update
 this setting to enable cross-domain cookies on a site that previously used
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index 2112926cc0..ce5d8019bd 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -653,7 +653,7 @@ you'll be logged in as the attacker and might inadvertently enter your
 sensitive personal data (e.g. credit card info) into the attackers account.
 
 Another possible attack would be if ``good.example.com`` sets its
-:setting:`SESSION_COOKIE_DOMAIN` to ``".example.com"`` which would cause
+:setting:`SESSION_COOKIE_DOMAIN` to ``"example.com"`` which would cause
 session cookies from that site to be sent to ``bad.example.com``.
 
 Technical details