docs: expand reference pages and fix children shortcode rendering

Enable Goldmark block-level attributes so the relearn `children`
shortcode applies its CSS classes instead of printing them literally
in the table-of-contents pages. Also expand the deploy, plugins,
records, and email reference docs and add the checks pages.

content/reference/services/email.en.md

@@ -2,8 +2,57 @@
 date: 2021-01-12T21:38:49+02:00
 author: Frederic
 title: E-Mail
+description: "Declare the mail servers of a zone (MX records) and the related anti-spoofing services (SPF, DKIM, DMARC) that govern how mail is sent and received."
 aliases:
     services/email
 ---
 
-The E-Mail service allows you to define an e-mail server on the zone, as well as the zone settings for sending/receiving e-mails.
+The **E-Mail** service lets you declare the mail servers responsible for a zone, and points you to the companion services that control how mail is sent and authenticated for that domain.
+
+In happyDomain, this service is named **E-Mail servers**: its single job is to publish the `MX` records that tell the rest of the Internet *where* to deliver mail addressed to your domain. Everything that protects *outgoing* mail (proving that a message really comes from you) is handled by separate, dedicated services described further down.
+
+## Receiving mail: MX records
+
+An `MX` (Mail eXchanger) record names a host that accepts mail for the domain. A zone usually publishes several of them so that delivery keeps working if one server is unavailable.
+
+Each entry has two parts:
+
+- **Priority** — a number that orders the servers. Sending servers try the **lowest** number first; higher numbers are used only as fallbacks. Two records sharing the same priority are treated as equivalent and load-balanced.
+- **Mail server** — the hostname of the machine that receives the mail (for example `mx1.example.com.`). This host must itself resolve to an address; it should not be a bare IP.
+
+A common setup looks like this:
+
+| Priority | Mail server |
+|---|---|
+| 10 | `mx1.example.com.` |
+| 20 | `mx2.example.com.` |
+
+Here `mx1` is tried first, and `mx2` is the backup.
+
+{{% notice style="info" title="One E-Mail service per subdomain" %}}
+The E-Mail servers service is *single*: a given subdomain can hold only one such service, which gathers all of its `MX` records together. To declare mail servers for both the apex (`example.com`) and a subdomain (`mail.example.com`), add the service to each of them separately.
+{{% /notice %}}
+
+## Sending mail: authentication and anti-spoofing
+
+Publishing `MX` records is enough to *receive* mail, but it says nothing about which servers are allowed to *send* mail on your behalf. Without that, anyone can forge messages using your domain. happyDomain offers several dedicated services, each managing its own DNS records, to establish that posture:
+
+- **SPF** (*Sender Policy Framework*) — a `TXT` record, usually at the zone apex, that lists the servers authorized to send mail for the domain. Receivers compare the sending server against this list.
+- **DKIM** (*DomainKeys Identified Mail*) — publishes the public half of a signing key as a `TXT` record under a `._domainkey` selector. Your mail servers sign outgoing messages, and receivers verify the signature against this published key.
+- **DMARC** (*Domain-based Message Authentication, Reporting and Conformance*) — a `TXT` record at `_dmarc` that tells receivers what to do with messages failing SPF or DKIM checks (let them through, quarantine, or reject), and where to send aggregate reports.
+
+Two further services cover transport security and reporting:
+
+- **MTA-STS** — declares that mail to your domain must be delivered over a secured (TLS) connection.
+- **TLS-RPT** — collects reports about TLS delivery problems encountered by sending servers.
+
+These services are independent of the E-Mail servers service. You can add only the ones you need, but a complete and well-protected mail configuration typically combines `MX`, SPF, DKIM and DMARC.
+
+## In the zone editor
+
+To configure mail for a subdomain in the happyDomain zone editor:
+
+1. Add the **E-Mail servers** service to the subdomain and fill in one line per mail server, with its priority and hostname.
+2. Add **SPF**, **DKIM** and **DMARC** as their own services on the relevant subdomain (SPF and DMARC usually at the apex). Each one presents a dedicated form rather than raw record text.
+
+Because each of these is a distinct abstract service, you manage them separately even though they all work together to make mail for your domain both deliverable and trustworthy. See the {{< relref "/reference/services" >}} chapter for the full list of available services.

content/reference/services/email.fr.md

@@ -1,8 +1,57 @@
 ---
 date: 2020-12-15T01:01:08+01:00
 title: E-Mail
+description: "Déclarez les serveurs de courrier d'une zone (enregistrements MX) ainsi que les services complémentaires (SPF, DKIM, DMARC) qui encadrent l'envoi et la réception des courriels."
 aliases:
     services/email
 ---
 
-Le service E-Mail permet de définir un serveur de courrier électronique sur la zone, ainsi que le paramétrage de la zone en vue d'envoyer/recevoir des courriels.
+Le service **E-Mail** permet de déclarer les serveurs de courrier responsables d'une zone. Il oriente également vers les services associés, qui régissent la manière dont le courrier est envoyé et authentifié pour le domaine.
+
+Dans happyDomain, ce service porte le nom de **E-Mail servers**. Son unique rôle consiste à publier les enregistrements `MX`, ceux qui indiquent au reste d'Internet *où* livrer les courriels adressés à votre domaine. Tout ce qui protège le courrier *sortant*, c'est-à-dire prouver qu'un message provient réellement de vous, relève de services dédiés et distincts, décrits plus bas.
+
+## Recevoir du courrier : les enregistrements MX
+
+Un enregistrement `MX` (*Mail eXchanger*) désigne une machine qui accepte le courrier du domaine. Une zone en publie généralement plusieurs, afin que la livraison continue de fonctionner si l'un des serveurs devient indisponible.
+
+Chaque entrée comporte deux parties :
+
+- **La priorité** : un nombre qui ordonne les serveurs. Les serveurs émetteurs essaient d'abord le nombre le **plus bas** ; les valeurs plus élevées ne servent que de secours. Deux enregistrements partageant la même priorité sont considérés comme équivalents et se répartissent la charge.
+- **Le serveur de courrier** : le nom d'hôte de la machine qui reçoit le courrier (par exemple `mx1.example.com.`). Cet hôte doit lui-même se résoudre vers une adresse ; il ne s'agit pas d'indiquer directement une adresse IP.
+
+Une configuration courante ressemble à ceci :
+
+| Priorité | Serveur de courrier |
+|---|---|
+| 10 | `mx1.example.com.` |
+| 20 | `mx2.example.com.` |
+
+Ici, `mx1` est contacté en premier et `mx2` sert de secours.
+
+{{% notice style="info" title="Un seul service E-Mail par sous-domaine" %}}
+Le service E-Mail servers est *unique* : un sous-domaine donné ne peut héberger qu'un seul service de ce type, qui rassemble l'ensemble de ses enregistrements `MX`. Pour déclarer des serveurs de courrier à la fois sur l'apex (`example.com`) et sur un sous-domaine (`mail.example.com`), on ajoute le service à chacun d'eux séparément.
+{{% /notice %}}
+
+## Envoyer du courrier : authentification et lutte contre l'usurpation
+
+Publier des enregistrements `MX` suffit pour *recevoir* du courrier, mais ne dit rien sur les serveurs autorisés à en *envoyer* en votre nom. Sans cette indication, n'importe qui peut forger des messages au nom de votre domaine. happyDomain propose plusieurs services dédiés, chacun gérant ses propres enregistrements DNS, pour établir cette protection :
+
+- **SPF** (*Sender Policy Framework*) : un enregistrement `TXT`, placé en général à l'apex de la zone, qui énumère les serveurs autorisés à envoyer du courrier pour le domaine. Les destinataires comparent le serveur émetteur à cette liste.
+- **DKIM** (*DomainKeys Identified Mail*) : publie la partie publique d'une clé de signature dans un enregistrement `TXT`, sous un sélecteur `._domainkey`. Vos serveurs signent les messages sortants, et les destinataires vérifient la signature à l'aide de cette clé publiée.
+- **DMARC** (*Domain-based Message Authentication, Reporting and Conformance*) : un enregistrement `TXT` placé sur `_dmarc`, qui indique aux destinataires comment traiter les messages échouant aux contrôles SPF ou DKIM (les laisser passer, les mettre en quarantaine ou les rejeter), et où envoyer les rapports agrégés.
+
+Deux autres services couvrent la sécurité du transport et la remontée d'informations :
+
+- **MTA-STS** : déclare que le courrier destiné à votre domaine doit être livré au travers d'une connexion sécurisée (TLS).
+- **TLS-RPT** : recueille les rapports relatifs aux problèmes de livraison TLS rencontrés par les serveurs émetteurs.
+
+Ces services sont indépendants du service E-Mail servers. On peut n'ajouter que ceux dont on a besoin, mais une configuration de courrier complète et bien protégée associe le plus souvent `MX`, SPF, DKIM et DMARC.
+
+## Dans l'éditeur de zone
+
+Pour configurer le courrier d'un sous-domaine dans l'éditeur de zone de happyDomain :
+
+1. On ajoute le service **E-Mail servers** au sous-domaine, puis on renseigne une ligne par serveur de courrier, avec sa priorité et son nom d'hôte.
+2. On ajoute **SPF**, **DKIM** et **DMARC** en tant que services à part entière sur le sous-domaine concerné (SPF et DMARC se placent généralement à l'apex). Chacun présente un formulaire dédié plutôt que le contenu brut de l'enregistrement.
+
+Comme chacune de ces abstractions constitue un service distinct, on les gère séparément, même si elles concourent toutes à rendre le courrier de votre domaine à la fois livrable et digne de confiance. Le chapitre {{< relref "/reference/services" >}} présente la liste complète des services disponibles.