← RFC Reference

RFC 6652 : Rapport d'échec d'authentification SPF

Pourquoi cela existe

SPF (RFC 7208) valide qu'une adresse IP d'envoi est autorisée pour le domaine expéditeur de l'enveloppe. Lorsque SPF échoue, cela peut signifier :

• Un usurpateur forge votre domaine
• Un expéditeur tiers légitime (plateforme marketing, CRM) manque dans votre enregistrement SPF
• Un serveur de transfert relaye votre courrier (cassant l'alignement SPF)
• Votre enregistrement SPF a une erreur de syntaxe ou dépasse la limite de 10 recherches

Sans rapports d'échec, vous êtes aveugle à ces événements. Les rapports agrégés DMARC (RFC 7489) vous donnent des résumés quotidiens, mais RFC 6652 fournit des rapports médico-légaux par message spécifiquement pour les échecs SPF. Ces rapports utilisent le format ARF (RFC 5965) avec le type de retour auth-failure étendu par RFC 6591.

Comment cela fonctionne

Le propriétaire du domaine publie un enregistrement TXT DNS spécial à _spf._report.<domain> qui indique aux destinataires où envoyer les rapports d'échec SPF.

Enregistrement DNS

; Demandez l'envoi de rapports d'échec SPF à cette adresse
_spf._report.example.com.  IN TXT  "v=spf-report1; ra=spf-reports; rp=100; rr=all"

Champs d'enregistrement

Exemple de rapport d'échec (format ARF)

From: arf-generator@receiver.example
To: spf-reports@example.com
Subject: SPF failure report for example.com
Content-Type: multipart/report; report-type=feedback-report;
    boundary="SPF-REPORT-001"

--SPF-REPORT-001
Content-Type: text/plain

SPF authentication failure report for a message
claiming to be from example.com.

--SPF-REPORT-001
Content-Type: message/feedback-report

Feedback-Type: auth-failure
User-Agent: Receiver-MTA/2.0
Version: 1
Auth-Failure: spf
Authentication-Results: receiver.example;
    spf=fail smtp.mailfrom=example.com
Original-Mail-From: user@example.com
Source-IP: 198.51.100.50
Reported-Domain: example.com
Delivery-Result: reject

--SPF-REPORT-001
Content-Type: text/rfc822-headers

From: user@example.com
To: recipient@receiver.example
Subject: Important update
Message-ID: <msg-001@example.com>

--SPF-REPORT-001--

Détails techniques clés

Valeurs du champ Auth-Failure pour SPF

Le champ Auth-Failure distingue les rapports SPF des rapports d'échec DKIM ou DMARC qui utilisent également le type de retour auth-failure (défini dans RFC 6591).

Relation avec la création de rapports DMARC

DMARC (RFC 7489) dispose de son propre mécanisme de rapport avec deux types :

• Rapports agrégés (rua) — résumés XML quotidiens des résultats d'authentification, envoyés à l'adresse de l'enregistrement DMARC.
• Rapports médico-légaux (ruf) — rapports d'échec par message. Les rapports médico-légaux DMARC couvrent à la fois les échecs d'alignement SPF et DKIM.

Les rapports RFC 6652 sont spécifiques à SPF et indépendants de DMARC. En pratique, la plupart des destinataires génèrent des rapports agrégés DMARC (largement supportés) mais peu génèrent des rapports RFC 6652 ou DMARC médico-légaux en raison de préoccupations relatives à la vie privée. Cependant, lorsqu'ils sont supportés, les rapports RFC 6652 fournissent les données par-échec les plus détaillées pour SPF spécifiquement.

Considérations de confidentialité

Les rapports d'échec peuvent contenir des adresses de destinataires et des en-têtes de message, soulevant des préoccupations en matière de confidentialité. De nombreux destinataires limitent ce qu'ils incluent ou ne génèrent pas du tout ces rapports. La balise rp permet au propriétaire du domaine de demander un pourcentage inférieur à 100 pour réduire le volume de rapport.

Erreurs courantes

• S'attendre à une adoption généralisée. Très peu de destinataires génèrent des rapports RFC 6652 en pratique. La plupart de la visibilité des échecs SPF provient plutôt des rapports agrégés DMARC. Publiez l'enregistrement de rapport, mais ne vous y fiez pas comme seule source de visibilité des échecs SPF.
• Ne pas surveiller la boîte aux lettres de rapport. Si vous publiez une adresse de rapport, surveillez-la. Les rapports non lus n'ont aucune valeur. Analysez-les automatiquement ou utilisez un service de rapport DMARC/SPF.
• Confondre avec les rapports DMARC ruf. Les rapports médico-légaux DMARC (ruf) et les rapports RFC 6652 sont des mécanismes distincts. Les deux utilisent le format ARF, mais ils sont déclenchés par des enregistrements différents et peuvent être générés par des destinataires différents.
• Définir rp=100 sur les domaines à fort volume. Pour les domaines qui envoient des millions de messages, demander 100 % de rapport d'échec peut générer un volume accablant. Commencez par un faible pourcentage et augmentez selon les besoins.
• Oublier le préfixe _spf._report. L'enregistrement DNS doit être à _spf._report.yourdomain.com, pas dans l'enregistrement SPF lui-même. C'est un enregistrement TXT distinct de votre politique SPF.

Impact sur la délivrabilité

• Identifie les expéditeurs non autorisés. Les rapports d'échec révèlent quelles adresses IP envoient du courrier avec votre domaine dans l'expéditeur de l'enveloppe mais échouent SPF. Cela pourrait être de l'usurpation ou un service légitime oublié.
• Prend en charge l'affinage de l'enregistrement SPF. Avant de resserrer votre politique SPF de ~all à -all, les rapports d'échec vous aident à identifier tout expéditeur légitime que vous n'avez pas encore autorisé.
• Complète la création de rapports DMARC. Tandis que les rapports agrégés DMARC vous indiquent les ratios pass/fail, les rapports médico-légaux RFC 6652 vous donnent les en-têtes spécifiques et les adresses IP sources pour les échecs individuels — critiques pour enquêter sur les nouvelles campagnes d'usurpation.
• Avertissement précoce pour la cassure de transfert. Lorsqu'une liste de diffusion ou un service de transfert relaye vos messages, SPF échouera parce que l'adresse IP du serveur de transfert ne se trouve pas dans votre enregistrement SPF. Les rapports d'échec vous aident à identifier ces cas afin que vous puissiez ajuster votre stratégie d'authentification (par exemple, vous fier à DKIM pour le courrier transféré).

Related RFCs