Vue d’ensemble
Domaines d’envoi
Pourquoi Emailit a besoin de votre propre domaine, quels enregistrements DNS il configure pour l’authentification, le suivi et les e-mails entrants, et comment les domaines restent vérifiés.
Chaque e-mail que vous envoyez via Emailit provient d’un domaine d’envoiDomaine d’envoiUn domaine qui vous appartient et que vous vérifiez avec des enregistrements DNS, pour qu’Emailit puisse envoyer des e-mails depuis ce domaine avec SPF, DKIM et un return-path personnalisé. qui vous appartient et que vous avez vérifié avec des enregistrements DNS. Cette page explique ce qu’Emailit configure sur ce domaine, comment fonctionne la vérification et combien de domaines votre forfait inclut.
Pourquoi un domaine d’envoi est nécessaire
Les fournisseurs de messagerie comme Gmail, Outlook et Yahoo ne font confiance qu’aux e-mails qui prouvent provenir du domaine de l’adresse From. Emailit le prouve grâce aux enregistrements SPF et DKIM de votre domaine : vos messages sont ainsi authentifiés comme étant les vôtres et construisent la réputation de votre domaine, et non une réputation partagée.
Tant qu’un domaine n’est pas vérifié, Emailit rejette les messages qui en proviennent. L’API renvoie 422 Domain not verified et SMTP répond 530 From/Sender domain is not verified for this workspace. Chaque adresse From doit utiliser un domaine vérifié du même espace de travail, et chaque sous-domaine compte comme un domaine à part entière.
Ce qu’Emailit configure
Quand vous ajoutez un domaine, Emailit génère une clé DKIM de 2 048 bits et vous fournit jusqu’à six enregistrements DNS. Trois sont obligatoires ; les autres activent des fonctionnalités facultatives.
| Enregistrement | Hôte | Rôle | Obligatoire |
|---|---|---|---|
| MX | emailit.<domain> |
Return-path. Reçoit les rebonds et les rapports de livraison de vos e-mails. | Oui |
| TXT (SPF) | emailit.<domain> |
Autorise les serveurs d’Emailit à envoyer pour le sous-domaine de return-path. | Oui |
| TXT (DKIM) | emailit._domainkey.<domain> |
Clé publique qui vérifie la signature DKIM de chaque message. | Oui |
| TXT (DMARC) | _dmarc.<domain> |
Indique aux serveurs destinataires que faire des e-mails qui échouent à l’authentification. | Non |
| CNAME | go.<domain> |
Domaine de suivi personnalisé pour le suivi des ouvertures et des clics. | Non |
| MX | inbound.<domain> |
Reçoit les e-mails entrants à n’importe quelle adresse sur inbound.<domain>. |
Non |
L’enregistrement SPF se trouve sur le sous-domaine de return-path, et non sur votre domaine racine : vous n’avez donc pas besoin de modifier un enregistrement SPF existant pour Google Workspace, Microsoft 365 ou un autre fournisseur. Pour toutes les valeurs et la raison de cette configuration, consultez Enregistrements DNS.
Fonctionnement
- Vous ajoutez le domaine dans le tableau de bord ou avec l’API. Emailit crée les enregistrements DNS correspondants.
- Vous publiez les enregistrements chez votre fournisseur DNS, ou vous laissez Emailit les créer dans Cloudflare.
- Vous lancez Check DNS. Emailit recherche les enregistrements. Quand SPF, DKIM et le return-path sont tous valides, le domaine est vérifié.
- Vous envoyez. Emailit signe chaque message avec votre clé DKIM et utilise
emailit.<domain>comme return-path : SPF et DKIM sont ainsi tous deux alignés avec votre domaineFrompour DMARC. - Emailit revérifie le DNS chaque jour. Si un enregistrement obligatoire n’est plus valide, le domaine cesse d’envoyer et le propriétaire de l’espace de travail reçoit un e-mail intitulé « Sending domain
<domain>is no longer verified ».
Statuts des domaines
| Statut | Signification |
|---|---|
| Verified | SPF, DKIM et le return-path sont valides. Vous pouvez envoyer depuis le domaine. |
| Not verified | Un ou plusieurs enregistrements obligatoires sont absents ou invalides, ou vous n’avez pas encore lancé Check DNS. |
| Pending verification | Le DNS est peut-être correct, mais le domaine attend un examen manuel. Cela concerne les domaines enregistrés depuis moins de 30 jours sur Pay as you go. |
| Sending paused | Le taux de rebond du domaine est trop élevé. Une bannière s’affiche sur la page du domaine. Consultez Santé d’envoi. |
La page Vérification des domaines explique chaque statut, les contrôles par enregistrement et la façon de corriger les échecs courants.
Limites
| Pay as you go | Pro | Business | Custom | |
|---|---|---|---|---|
| Domaines d’envoi | 3 (25 après votre premier achat de crédits) | 100 | 1 000 | Selon accord |
| Examen des domaines de moins de 30 jours | Oui | Non | Non | Oui |
Les licences AppSumo définissent leur propre nombre de domaines autorisés. Consultez Limites de domaines.
Domaine racine ou sous-domaine ?
Vous pouvez vérifier un domaine racine comme acme.com ou un sous-domaine comme mail.acme.com. Les deux fonctionnent. Choisissez selon votre façon d’envoyer :
- Utilisez un sous-domaine par type d’e-mail si vous envoyez à la fois des e-mails transactionnels et marketing, par exemple
notify.acme.compour les reçus et les réinitialisations de mot de passe, etnews.acme.compour les campagnes. Chaque sous-domaine construit sa propre réputation : une campagne qui suscite des plaintes ne nuit donc pas à vos reçus. - Utilisez le domaine racine si vous n’envoyez qu’un volume modeste d’e-mails transactionnels et voulez que votre adresse
Fromsoithello@acme.com. - Envoyez exactement depuis le domaine que vous avez vérifié. Vérifier
acme.comne vous permet pas d’envoyer depuismail.acme.com, et inversement.
Dans les deux cas, votre messagerie existante continue de fonctionner : les enregistrements d’Emailit se trouvent sur leurs propres hôtes (emailit., emailit._domainkey., go. et inbound.) et ne remplacent donc pas les enregistrements MX ou SPF de votre domaine racine.