Mode Sandbox SES : Pourquoi vos emails n'arrivent pas chez vos clients et comment demander une augmentation des limites de production

Vous venez de configurer Amazon SES, vos emails de test arrivent parfaitement dans votre propre boîte, mais dès que vous essayez d'envoyer à un client réel, c'est le silence total — ou pire, une erreur MessageRejected. Ce comportement n'est pas un bug : c'est le mode Sandbox SES, et chaque nouveau compte AWS y est placé par défaut.

TL;DR — Mode Sandbox SES

AspectSandboxProduction
Destinataires autorisésAdresses et domaines vérifiés uniquementN'importe quelle adresse email valide
Volume d'envoiLimité (vérifier la documentation AWS)Augmenté après approbation
Cas d'usageTests et développementEnvois transactionnels et marketing en production
ActivationPar défaut sur tous les nouveaux comptesDemande manuelle via Service Quotas

Comment fonctionne le mode Sandbox SES

Amazon SES impose le mode Sandbox comme filet de sécurité contre les abus d'envoi massif depuis des comptes nouvellement créés. AWS protège ainsi la réputation de ses IP partagées — si n'importe qui pouvait envoyer des millions d'emails dès l'ouverture d'un compte, les taux de spam exploseraient et tout le monde en souffrirait.

En Sandbox, SES applique deux restrictions fondamentales. Premièrement, vous ne pouvez envoyer qu'à des adresses email ou des domaines que vous avez explicitement vérifiés dans SES. Deuxièmement, votre quota d'envoi quotidien et votre débit maximal sont limités. Ces deux contraintes disparaissent une fois que vous passez en production.

graph TD A["Nouveau compte AWS"] --> B["Mode Sandbox SES
activé par défaut"] B --> C{"Destinataire vérifié dans SES ?"} C -- Oui --> D["Email accepté et livré"] C -- Non --> E["MessageRejected ou rejet silencieux"] B --> F["Demande production via Service Quotas"] F --> G{"Approbation AWS"} G -- Approuvé --> H["Accès Production Destinataires illimités"] G -- Refusé --> I["Motif fourni Correction requise"] I --> F
  1. Nouveau compte AWS : placé automatiquement en Sandbox à la création.
  2. Vérification d'identité : seules les adresses/domaines vérifiés peuvent recevoir vos emails en Sandbox.
  3. Tentative d'envoi à un destinataire non vérifié : SES rejette le message avec MessageRejected.
  4. Demande de production : soumise via Service Quotas, examinée par AWS.
  5. Accès production : les restrictions de destinataires et de volume sont levées.

Diagnostic : Confirmer que vous êtes en mode Sandbox

Avant de soumettre une demande, vérifiez votre statut actuel. La commande suivante interroge l'API SES v2 pour retourner l'état de votre compte dans la région cible.

aws sesv2 get-account \
  --region us-east-1

Dans la réponse JSON, cherchez le champ ProductionAccessEnabled. S'il vaut false, vous êtes en Sandbox. S'il vaut true, votre compte a déjà l'accès production pour cette région.

{
  "DedicatedIpAutoWarmupEnabled": true,
  "EnforcementStatus": "HEALTHY",
  "ProductionAccessEnabled": false,
  "SendQuota": {
    "Max24HourSend": 200.0,
    "MaxSendRate": 1.0,
    "SentLast24Hours": 0.0
  },
  "SendingEnabled": true
}

ProductionAccessEnabled: false avec Max24HourSend: 200 — c'est la signature exacte du Sandbox. Le quota de 200 emails par 24h et le débit d'1 email/seconde sont les valeurs par défaut du Sandbox, mais ces chiffres peuvent évoluer ; consultez toujours la documentation AWS pour les valeurs actuelles.

Vérifier vos identités SES existantes

En Sandbox, tout destinataire doit être une identité vérifiée. Listez vos identités actuelles pour savoir ce qui est déjà validé avant de tenter des envois de test.

aws sesv2 list-email-identities \
  --region us-east-1

Si l'adresse de votre client n'apparaît pas dans cette liste et que vous êtes en Sandbox, SES rejettera le message sans même tenter la livraison. C'est souvent là que les équipes perdent du temps — elles cherchent un problème de configuration SMTP alors que la cause est simplement l'absence de vérification du destinataire.

Demander l'accès production via Service Quotas

La sortie du Sandbox passe par une demande d'augmentation de quota dans AWS Service Quotas. Ce n'est pas un simple bouton on/off — AWS examine votre cas d'usage et votre configuration avant d'approuver.

Étape 1 : Identifier l'ID du quota SES

Le quota qui contrôle l'accès production SES dans Service Quotas s'appelle 'Sending emails per day'. Récupérez son identifiant dans votre région pour construire la demande correctement.

aws service-quotas list-service-quotas \
  --service-code ses \
  --region us-east-1 \
  --query 'Quotas[?QuotaName==`Sending emails per day`].{Name:QuotaName,Code:QuotaCode,Value:Value}'

Étape 2 : Soumettre la demande d'augmentation

La méthode recommandée est via la console AWS SES, car elle propose un formulaire structuré avec les champs que l'équipe AWS examine. Naviguez vers SES Console → Account dashboard → Request production access.

Vous pouvez également soumettre via la CLI Service Quotas, mais le formulaire console permet de fournir le contexte métier que AWS attend :

aws service-quotas request-service-quota-increase \
  --service-code ses \
  --quota-code L-804C8AE8 \
  --desired-value 50000 \
  --region us-east-1

Remplacez L-804C8AE8 par le code retourné à l'étape 1 si différent, et ajustez --desired-value selon votre volume cible réel.

Penser à la demande de production comme à une ouverture de compte bancaire professionnel : AWS veut comprendre votre activité, votre volume attendu, et comment vous gérez les bounces et les plaintes. Une demande vague ('j'ai besoin d'envoyer des emails') sera rejetée ou retardée. Une demande précise ('application transactionnelle, 10 000 emails/jour, SPF/DKIM configurés, SNS configuré pour les bounces') est approuvée rapidement.

Ce qu'AWS examine dans votre demande

AWS évalue plusieurs signaux avant d'approuver l'accès production. Assurez-vous que ces éléments sont en place avant de soumettre — une demande incomplète allonge inutilement le délai de traitement.

  • Type d'emails : transactionnel (confirmations, réinitialisations de mot de passe) ou marketing. Les deux sont acceptés, mais le cas d'usage doit être clair.
  • Gestion des bounces et plaintes : AWS vérifie que vous avez configuré des notifications SNS pour les bounces et les plaintes via les configuration sets SES. Un taux de bounce non géré est le signal d'alarme principal.
  • Conformité opt-in : pour les emails marketing, AWS s'attend à ce que vous décriviez votre mécanisme de consentement.
  • Authentification email : SPF et DKIM configurés sur votre domaine d'envoi.

Configurer les notifications de bounce avant la demande

Ne soumettez pas votre demande sans avoir configuré la gestion des bounces. C'est le point qui fait échouer le plus de demandes — AWS peut voir si votre configuration SES inclut un mécanisme de feedback, et une absence totale est un signal négatif fort.

Créer un topic SNS pour les bounces

aws sns create-topic \
  --name ses-bounce-notifications \
  --region us-east-1

Créer un configuration set SES

aws sesv2 create-configuration-set \
  --configuration-set-name production-config \
  --region us-east-1

Associer les notifications SNS au configuration set

aws sesv2 create-configuration-set-event-destination \
  --configuration-set-name production-config \
  --event-destination-name bounce-destination \
  --event-destination '{"Enabled": true, "MatchingEventTypes": ["BOUNCE", "COMPLAINT"], "SnsDestination": {"TopicArn": "arn:aws:sns:us-east-1:123456789012:ses-bounce-notifications"}}' \
  --region us-east-1

Une fois ce configuration set en place, référencez-le dans votre demande de production. Cela démontre à AWS que vous avez une infrastructure de gestion de réputation opérationnelle, pas juste une intention.

Politique IAM minimale pour les opérations SES v2

Si vous automatisez le diagnostic ou la configuration via un rôle IAM dédié, voici la politique minimale couvrant les opérations décrites dans cet article. Notez que sesv2:GetAccount est l'action correcte pour l'API SES v2 — ses:GetAccount appartient à l'API v1 et ne fonctionnera pas avec les commandes aws sesv2.

🔽 Politique IAM minimale SES v2 (cliquer pour développer) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SESv2ReadAndConfigure",
      "Effect": "Allow",
      "Action": [
        "sesv2:GetAccount",
        "sesv2:ListEmailIdentities",
        "sesv2:CreateConfigurationSet",
        "sesv2:CreateConfigurationSetEventDestination",
        "sesv2:SendEmail"
      ],
      "Resource": "*"
    },
    {
      "Sid": "SNSTopicCreate",
      "Effect": "Allow",
      "Action": [
        "sns:CreateTopic",
        "sns:Subscribe"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ServiceQuotasRead",
      "Effect": "Allow",
      "Action": [
        "servicequotas:ListServiceQuotas",
        "servicequotas:RequestServiceQuotaIncrease"
      ],
      "Resource": "*"
    }
  ]
}

Les actions sesv2:GetAccount et sesv2:ListEmailIdentities ne supportent pas les restrictions ARN au niveau ressource — "Resource": "*" est requis pour ces actions. Vérifiez toujours dans la Service Authorization Reference SES v2 avant de restreindre davantage.

Cas réel : l'erreur silencieuse qui fait perdre des heures

Voici un pattern que l'on voit régulièrement en production. L'équipe configure SES, les tests internes fonctionnent, le déploiement se fait, et les premiers clients ne reçoivent rien. Pas d'erreur dans les logs applicatifs — l'appel API SES retourne un MessageId, ce qui ressemble à un succès.

Le diagnostic initial pointe vers un problème de livraison côté destinataire — SPF, DKIM, réputation IP. On passe des heures à vérifier les enregistrements DNS, à tester avec des outils externes, tout semble correct.

La vraie cause : l'appel API SES accepte le message en Sandbox même pour un destinataire non vérifié dans certaines configurations SDK, mais le rejette silencieusement en interne sans déclencher d'événement de bounce visible immédiatement. Le MessageId retourné crée une fausse impression de succès.

La vérification correcte : interroger aws sesv2 get-account en premier, confirmer ProductionAccessEnabled: false, puis vérifier que le destinataire est dans list-email-identities. Ces deux commandes auraient résolu le problème en deux minutes.

Un MessageId SES ne garantit pas la livraison — il confirme seulement que SES a accepté le message dans sa file. En Sandbox, 'accepté' et 'livré' ne sont pas synonymes.

Suivre le statut de votre demande de production SES

Après soumission, AWS traite généralement les demandes en quelques jours ouvrés, mais le délai varie. Suivez l'état via Service Quotas :

aws service-quotas list-requested-service-quota-changes-by-service \
  --service-code ses \
  --region us-east-1 \
  --query 'RequestedQuotas[*].{Status:Status,Desired:DesiredValue,Created:Created}'

Les statuts possibles incluent PENDING, APPROVED, DENIED, et CASE_OPENED. Si votre demande est refusée, AWS fournit un motif — lisez-le attentivement, car il indique précisément ce qui manque dans votre configuration ou votre description de cas d'usage.

Conclusion et prochaines étapes pour quitter le mode Sandbox SES

Le mode Sandbox SES n'est pas un obstacle arbitraire — c'est un mécanisme de protection de la réputation d'envoi qui bénéficie à tous les utilisateurs SES. La sortie du Sandbox est directe si vous préparez correctement votre demande : vérifiez votre statut avec sesv2:GetAccount, configurez la gestion des bounces via SNS et les configuration sets, puis soumettez une demande détaillée via la console SES.

Ressources officielles :

Glossaire

TermeDéfinition
Sandbox SESEnvironnement restreint par défaut pour les nouveaux comptes SES, limitant les destinataires aux identités vérifiées et imposant des quotas d'envoi réduits.
Identité vérifiéeAdresse email ou domaine dont la propriété a été confirmée dans SES via un processus de vérification DNS ou email.
Configuration SetEnsemble de règles SES appliquées aux emails envoyés, permettant notamment de router les événements (bounces, plaintes) vers SNS, CloudWatch ou Kinesis.
BounceNotification indiquant qu'un email n'a pas pu être livré. Les bounces permanents (hard bounces) impactent directement la réputation d'envoi.
Service QuotasService AWS centralisé pour visualiser et demander des augmentations de limites de service, y compris les quotas SES d'envoi quotidien.

Related Posts

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Structure de base d'une politique IAM : Effect, Action, Resource et Condition expliqués

La première fois qu'on ouvre une politique IAM JSON en production pour diagnostiquer un accès refusé, les quatre éléments Effect , Action , Resource et Condition semblent évidents — jusqu'au moment où une permission ne se comporte pas comme prévu et qu'on réalise qu'on avait mal compris la portée d'un seul de ces champs. Comprendre la structure d'une politique IAM, c'est comprendre comment AWS évalue chaque requête API avant de l'autoriser ou de la rejeter. TL;DR — Structure d'une politique IAM Élément Rôle Obligatoire Effect Autorise ( Allow ) ou refuse ( Deny ) explicitement Oui Action Quelle(s) opération(s) API sont ciblées Oui Resource Sur quel(s) objet(s) AWS s'applique la règle Oui Condition Contraintes contextuelles supplémentaires (IP, MFA,...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

EBS vs EFS pour plusieurs instances EC2 : partager un dossier entre 5 serveurs

Vous venez de concevoir une architecture multi-instances et vous réalisez que cinq EC2 doivent lire et écrire dans le même répertoire — uploads utilisateurs, fichiers de configuration partagés, assets statiques. La première question qui vient : est-ce que EBS peut faire ça, ou faut-il absolument passer par EFS ? La réponse change radicalement selon le type de volume EBS et le mode d'accès souhaité. TL;DR — EBS vs EFS pour le partage entre instances EC2 Critère EBS (volume standard) EBS Multi-Attach (io1/io2) EFS Instances simultanées 1 seule Jusqu'à 16 (même AZ) Illimité, multi-AZ Portée géographique 1 AZ 1 AZ uniquement Toute la région Système de fichiers ext4, xfs, ntfs… Cluster-aware requis (GFS2, OCFS2) NFS v4.1 natif Compatibilité OS Linux, Windows ...
Lire la suite