Politiques de validation et listes
Le verdict result est le même pour tous les clients. Deux outils, réglés dans le tableau de bord, l'adaptent à vos règles : la politique de validation, qui produit finalDecision, et les listes blanche et noire, qui tranchent pour des adresses ou des domaines précis.
Politiques de validation
Une politique (Règles de validation dans le tableau de bord) liste ce que vous refusez. Elle s'applique à chaque appel et alimente deux champs de la réponse :
"finalDecision": "rejected",
"policy": {
"decision": "rejected",
"reasons": ["reject_disposable", "reject_role_account"],
"rejectedByClientConfig": true
}
| Règle | Code dans policy.reasons | Refuse quand |
|---|---|---|
| Refuser les jetables | reject_disposable | features.disposable signale une adresse jetable |
| Refuser les domaines malveillants | reject_malicious_domain | features.maliciousDomains signale le domaine |
| Refuser les domaines pièges | reject_typosquat | features.typosquat signale le domaine |
| Refuser les comptes génériques | reject_role_account | contact@, info@, support@… |
| Refuser les domaines accept-all | reject_catch_all | Le domaine accepte n'importe quelle adresse |
| Refuser les fournisseurs grand public | reject_free_provider | Gmail, Outlook, Orange… (formulaires B2B) |
| Refuser les non-concluants | reject_unknown | result vaut unknown |
| Refuser les termes injurieux | reject_on_profanity | features.profanity signale un terme |
| Refuser les parties locales aléatoires | reject_on_random_detection | features.randomDetection le signale |
| Score minimal | reject_low_quality_score | score sous le minimum choisi |
| Santé de domaine minimale | reject_low_domain_health | Santé du domaine sous le niveau choisi (excellent → critical) |
| Refuser VPN et Tor | reject_vpn_or_tor | L'appel vient d'un réseau anonymisant |
| Refuser les hébergeurs | reject_datacenter_ip | L'appel vient d'un hébergeur |
finalDecision ne remplace pas resultLa politique n'évalue que ses propres règles. Une adresse invalid qu'aucune règle ne vise ressort avec finalDecision: "accepted". Sans politique, finalDecision vaut toujours accepted. Décidez donc sur les deux : refusez si result vaut invalid ou si finalDecision vaut rejected.
Les règles reject_vpn_or_tor et reject_datacenter_ip regardent l'IP qui appelle l'API. Sur une clé serveur, c'est votre propre serveur, hébergé dans un datacenter : reject_datacenter_ip refuserait alors toutes les adresses. Réservez ces règles aux politiques des widgets.
Quelle politique s'applique
- La politique rattachée à la clé API, si la clé en a une.
- Sinon, la politique marquée par défaut dans l'organisation.
- Sinon, aucune : tout est
accepted.
Créez une politique par usage (formulaire B2C, formulaire B2B, widget de newsletter…) et rattachez-la à la clé correspondante.
Listes blanche et noire
Whitelist & Blacklist dans le tableau de bord. Chaque entrée vise une adresse précise ou un domaine entier.
| Liste | Effet sur la validation |
|---|---|
| Blanche | Le SMTP n'est pas exécuté (aucun crédit). Le score vaut au moins 95. Le verdict suit la syntaxe et le DNS. |
| Noire | Le SMTP n'est pas exécuté (aucun crédit). Le verdict est invalid, avec features.listCheck.details.isBlacklisted: true. |
Une même valeur ne peut pas figurer dans les deux listes : l'ajout est refusé avec le code LIST_CONFLICT et le tableau de bord propose de déplacer l'entrée.
Les listes s'appliquent aussi aux traitements par lots et au widget. Elles peuvent être ignorées par une clé en désactivant ses contrôles whitelist ou blacklist.