Avant de modifier SPF, identifiez le domaine que votre service d'envoi utilise pour son adresse envelope-from. Cette adresse reçoit les rebonds et peut différer de l'adresse From que votre destinataire voit.
Quel domaine SPF vérifie-t-il ?
SPF vérifie le domaine dans SMTP MAIL FROM, l'adresse envelope-from, ou l'identité HELO du serveur. HELO est le nom d'hôte qu'un serveur d'envoi présente à l'ouverture de la conversation SMTP.
Le récepteur connaît déjà l'IP de connexion lorsqu'il reçoit MAIL FROM, donc SPF peut s'exécuter avant l'arrivée du corps du message. Quand l'expéditeur d'enveloppe est vide, comme dans MAIL FROM:<>, SPF utilise l'identité HELO. RFC 7208, le standard SPF, recommande aussi de vérifier HELO séparément.
SPF ne vérifie pas l'adresse From visible. L'alignement DMARC relie un domaine authentifié à cette adresse.
À quoi ressemble un enregistrement SPF ?
Un enregistrement SPF est un enregistrement DNS TXT dont la valeur commence par v=spf1, suivi de règles d'autorisation.
example.com TXT "v=spf1 include:mailprovider.example ~all"Ici, include:mailprovider.example autorise les IP qui satisfont la politique SPF de ce fournisseur. ~all produit un softfail pour les autres IP. Remplacez le fournisseur d'exemple par la politique que votre service d'envoi publie.
Que signifient les mécanismes et les modificateurs ?
Les mécanismes testent l'IP de connexion par rapport à une condition. Le modificateur redirect délègue l'évaluation quand aucun mécanisme ne correspond.
| Terme | Effet |
|---|---|
ip4, ip6 | Correspond à une adresse ou un réseau écrit directement dans l'enregistrement. |
a | Correspond à une adresse renvoyée pour le domaine nommé, en utilisant la famille IP de la connexion. |
mx | Correspond à une adresse d'un échangeur de courrier pour le domaine nommé. |
include | Correspond quand la politique référencée renvoie pass pour cette IP. |
exists | Correspond quand le nom DNS spécifié possède un enregistrement A ; les macros peuvent construire ce nom à partir de la connexion. |
redirect= | Évalue la politique d'un autre domaine quand aucun mécanisme ne correspond ; un mécanisme all le rend inopérant. |
ptr | Vérifie les noms DNS inversés validés ; ne l'ajoutez pas à de nouveaux enregistrements car la requête est lente et peu fiable. |
all | Correspond à toute IP restante, le qualificateur déterminant le résultat. |
Les mécanismes d'adresse s'écrivent ip4 et ip6. Une entrée ptr peut apparaître dans une politique plus ancienne, mais RFC 7208 en déconseille l'usage tout en exigeant que les validateurs la prennent en charge.
Que changent les qualificateurs de all ?
Le qualificateur définit le résultat SPF pour une IP qui atteint all ; le récepteur décide du traitement du message.
| Terminaison | Résultat |
|---|---|
-all | Fail : le domaine n'autorise pas l'IP. |
~all | Softfail : le domaine considère l'IP comme probablement non autorisée. |
?all | Neutral : le domaine ne fait aucune assertion. |
+all | Pass pour toute IP, supprimant la restriction que SPF fournirait autrement. |
Comment les enregistrements d'exemple sont-ils évalués ?
Chaque exemple ci-dessous illustre une politique distincte. Les IP et les domaines sont des exemples de documentation, pas des valeurs à publier pour votre expéditeur.
| Enregistrement | Ce qu'il autorise |
|---|---|
v=spf1 mx ip4:192.0.2.10 ip4:198.51.100.0/24 ~all | Les échangeurs de courrier du domaine, une IP et le réseau indiqué ; les autres IP reçoivent un softfail. |
v=spf1 a ip4:192.0.2.0/25 ip4:198.51.100.0/26 -all | Les enregistrements d'adresse du domaine et deux réseaux ; les autres IP échouent. |
v=spf1 -all | Aucune IP ; toute tentative d'utilisation de ce domaine échoue à SPF. |
v=spf1 +all | Toute IP, donc aucune restriction d'envoi. |
v=spf1 redirect=_spf.example.com | Ce que la politique à _spf.example.com autorise. |
v=spf1 exists:%{i}._spf.example.com ~all | Les IP dont le nom de recherche développé renvoie un enregistrement A ; les autres IP reçoivent un softfail. |
Pour l'exemple exists, une connexion depuis 192.0.2.10 produit le nom de recherche 192.0.2.10._spf.example.com. Vous devez gérer les enregistrements DNS qui font fonctionner une telle politique ; le motif n'autorise pas un fournisseur à lui seul.
Combien de requêtes DNS SPF peut-il utiliser ?
SPF autorise dix termes évalués nécessitant une requête DNS dans l'ensemble de la politique et des évaluations imbriquées. Un onzième produit permerror, donc ajouter un fournisseur supplémentaire peut casser l'évaluation au lieu de l'autoriser.
Les termes comptabilisés sont include, a, mx, ptr, exists et redirect. Les termes littéraux ip4, ip6 et all ne consomment pas cette allocation. Ce sont les termes qui sont comptés, pas simplement chaque paquet DNS. Le CNAME du return-path fournit l'autorisation SPF de Bird sans ajouter un include à l'apex.
Pourquoi un courrier transféré peut-il échouer à SPF ?
Un redirecteur ou une liste de diffusion peut renvoyer un courrier légitime depuis une IP que le domaine envelope-from d'origine n'autorise pas. Par exemple, une boîte aux lettres d'anciens élèves transférant vers une boîte personnelle change le serveur de connexion vu par le récepteur final.
Si l'adresse envelope-from reste inchangée, SPF évalue ce nouveau serveur par rapport à la politique du domaine d'origine. Un redirecteur peut réécrire l'adresse envelope-from en utilisant le Sender Rewriting Scheme (SRS) pour authentifier son propre domaine. Cela n'aligne pas à soi seul SPF avec l'adresse From visible d'origine.
Une signature DKIM intacte et alignée peut toujours fournir un pass DMARC. L'authentification n'établit pas qu'un message est souhaité et ne garantit pas le placement en boîte de réception.
Que devez-vous publier pour Bird ?
Vous publiez le CNAME de return-path fourni pour votre domaine d'envoi. Il pointe vers l'infrastructure de rebonds de Bird, qui fournit déjà l'autorisation SPF. Vous n'avez pas besoin d'un include SPF supplémentaire à votre domaine apex pour envoyer via Bird.
Conservez un enregistrement SPF existant à l'apex pour les autres expéditeurs sans le modifier. Copiez le dns_records du domaine. Vérifiez capabilities.return_path.status ; contrôlez capabilities.sending.status pour la disponibilité sur l'ensemble des exigences d'envoi. Les deux champs de statut utilisent ces valeurs :
| Statut | Signification et action |
|---|---|
pending | La vérification n'a pas été lancée ou est en cours ; attendez son résultat. |
verified | Les enregistrements DNS de la capacité correspondent aux valeurs attendues. |
warning | Des enregistrements précédemment vérifiés ne correspondent plus ; corrigez-les avant la fin du délai de grâce. L'envoi n'est pas encore affecté. |
failed | Une valeur DNS est incorrecte ; corrigez-la. |
temporary_failure | Une requête DNS a échoué de manière transitoire ; la vérification réessaye automatiquement. |
not_configured | La capacité n'est pas configurée pour ce domaine. |
Vous vérifiez DKIM, le return-path et DMARC avant d'envoyer. Vous pouvez modifier le nom d'hôte du return-path. Si une valeur DNS TXT nécessite plusieurs chaînes entre guillemets, le découpeur d'enregistrements DNS formate ces chaînes sans modifier l'allocation de requêtes de SPF.