diff --git a/dist/assets/site.css b/dist/assets/site.css
index 8ae4f48..0d9752b 100644
--- a/dist/assets/site.css
+++ b/dist/assets/site.css
@@ -39,6 +39,14 @@ a.brand {
   color: #050505;
 }
 
+h3:target {
+  background-color: #ffa;
+}
+
+h3 a, h3 a:visited {
+  color: #050505;
+}
+
 span.brand {
   font-family: monospace;
   font-size: large;
diff --git a/dist/templates/about/faq.html.hbs b/dist/templates/about/faq.html.hbs
index aee5839..01a8c12 100644
--- a/dist/templates/about/faq.html.hbs
+++ b/dist/templates/about/faq.html.hbs
@@ -3,14 +3,32 @@
 
     <center><h2><a href="/about">About</a> | <a href="/about/usage">Usage</a> | FAQ | <a href="/about/privacy">Privacy Policy</a> | <a href="/about/api">API</a></h2></center>
 
-    <h3>Why not sign keys after verification?</h3>
+    <h3 id="no-sign-verified"><a href="#no-sign-verified">Why not sign keys
+            after verification?</a></h3>
 
     The <span class="brand">keys.openpgp.org</span> service is meant for key
     distribution and discovery, not as a de-facto CA.  Client implementations
     that want to offer verified communication should rely on their own trust
     model.
 
-    <h3>Why not encrypt verification e-mails?</h3>
+    <h3 id="non-email-uids"><a href="#non-email-uids">Why is there no support
+            for UserIDs that aren't e-mail addresses?</a></h3>
+
+    <p>
+        We require explicit consent to distribute identity information.
+        Identities that aren't e-mail addresses, such as pictures or addresses,
+        offer no simple way for us to acquire this consent.
+    </p>
+
+    <p>
+        Note: Some OpenPGP software creates keys with incorrectly formatted
+        e-mail addresses.  These addresses might not be recognized correctly on
+        <span class="brand">keys.openpgp.org</span>.
+    </p>
+
+
+    <h3 id="encrypt-verification-emails"><a href="#encrypt-verification-emails">
+            Why not encrypt verification e-mails?</a></h3>
 
     Various reasons:
     <ol>
@@ -23,7 +41,9 @@
             upload keys that can only sign.</li>
     </ol>
 
-    <h3>Is <span class="brand">keys.openpgp.org</span> part of the "SKS" pool?</h3>
+    <h3 id="sks-pool"><a href="#sks-pool">Is
+            <span class="brand">keys.openpgp.org</span> part of the "SKS" pool?</a>
+    </h3>
 
     <p>No. The "append-only" federation model of the SKS pool leads to various
         problems, that make both operation and use of those servers very
diff --git a/dist/templates/upload/upload-ok.html.hbs b/dist/templates/upload/upload-ok.html.hbs
index c8e72f8..b02db92 100644
--- a/dist/templates/upload/upload-ok.html.hbs
+++ b/dist/templates/upload/upload-ok.html.hbs
@@ -53,12 +53,18 @@
       {{#if count_unparsed_one}}
     <p style="padding-top: 1em;">
       This key contains one identity that could not be parsed as an email
-      address, which is not published.
+      address.<br />
+      This identity can't be published
+      on <span class="brand">keys.openpgp.org</span>.
+      (<a href="/about/faq#non-email-uids" target="_blank">Why?</a>)
     </p>
       {{else}}
     <p style="padding-top: 1em;">
       This key contains {{count_unparsed}} identities that could not be parsed
-      as an email address, which are not published.
+      as an email address.<br />
+      These identities can't be published
+      on <span class="brand">keys.openpgp.org</span>.
+      (<a href="/about/faq#non-email-uids" target="_blank">Why?</a>)
     </p>
       {{/if}}
     {{/if}}