SendGrid Sandbox Mode validiert einen Mail-Send-API-Request, ohne eine E-Mail zuzustellen. Damit lässt sich weder Inbox- noch Spamplatzierung feststellen. Dafür benötigen Sie einen zulässigen echten Versand über den vorgesehenen Anwendungsweg an die LDM-Testadressen. Halten Sie Requestvalidierung, Versandereignisse und beobachtete Postfachordner auseinander, damit ein erfolgreicher API-Test nicht mit Zustellung verwechselt wird.
„Die API meldet Erfolg, aber das Testpostfach bleibt leer“ kann ein völlig erwartetes Ergebnis sein. Bevor Sie Absenderauthentifizierung oder Betreff ändern, klären Sie, welche Art von Erfolg protokolliert wurde. Ein gültiger Request, eine angenommene echte Übermittlung und eine gefundene Empfängerkopie sind drei verschiedene Belege.
Eine erfolgreiche Suche ohne Kopie unterscheidet sich von einem nicht lesbaren Postfach und einer ausstehenden Prüfung.
Was Sandbox Mode prüft
SendGrid dokumentiert Sandbox Mode als Mail-Send-Einstellung unter mail_settings. Geprüft werden Struktur und Parametertypen des Requests. Eine erfolgreiche Sandbox-Validierung liefert 200 OK; eine erfolgreiche Übermittlung außerhalb der Sandbox normalerweise 202 Accepted. Sandbox-Requests stellen keine Nachrichten zu und erzeugen keine Event-Webhook- oder Email-Activity-Ereignisse. Diese Unterschiede beschreibt die Sandbox-Mode-Dokumentation.
Für Vorlagen besteht eine zusätzliche Einschränkung: Enthält der Request template_id, nimmt die Validierung an, dass die Vorlage Betreff und Inhalt enthält. Diese Inhalte werden nicht validiert. Ein gültiger Request beantwortet deshalb auch die Frage nach einer korrekt erzeugten fertigen Nachricht nur teilweise.
Nutzen Sie die Validierung, um Integrationsfehler früh zu erkennen. Prüfen Sie anschließend den tatsächlich erzeugten Inhalt und führen Sie bei Bedarf einen begrenzten echten Versand durch.
Den Übergang zum echten Versand begrenzen
Schalten Sie nicht pauschal sämtliche Entwicklungssicherungen ab, um einen Platzierungswert zu erhalten. Bestimmen Sie den konkreten Request oder isolierten Auftrag und begrenzen Sie dessen Empfänger auf die aktuellen Testadressen.
Dokumentieren Sie Absender, Umgebung, Vorlagenversion, Personalisierungsdaten, Tracking und gegebenenfalls Versandkonto oder Subuser. Halten Sie genügend Konfigurationsdaten zur Reproduktion fest, ohne API-Schlüssel in Berichte oder Screenshots zu kopieren.
Verwenden Sie geeignete Testdaten statt privater Kundendaten. Erforderliche Abmeldefunktionen und Header bleiben erhalten. Eine Werbenachricht ohne ihren üblichen Fußbereich wäre ein anderer Testgegenstand als die geplante Kampagne.
Der Test in sechs Schritten
1. Request und Vorlagenausgabe prüfen
Validieren Sie den vorgesehenen Request zunächst im Sandbox-Modus. Beheben Sie Strukturfehler, bevor Sie fortfahren. Kontrollieren Sie davon getrennt die mit denselben Testdaten erzeugte Ausgabe: Betreff, Textalternative, wichtige Links und bedingte Inhaltsabschnitte.
Dokumentieren Sie diese Phase als Request- und Inhaltsprüfung. Bezeichnen Sie sie nicht als zugestellt, auch wenn Ihre Anwendung bisher jede erfolgreiche HTTP-Antwort so protokolliert.
2. Den repräsentativen Versandweg wählen
Nutzt Ihre Anwendung die Mail Send API, testen Sie diesen Anwendungsweg. Versendet sie gewöhnlich per SMTP, prüfen Sie den tatsächlichen SMTP-Pfad. Ein API-Versuch ersetzt nicht automatisch einen SMTP-Auftrag mit anderer Inhaltserzeugung oder anderen Headern.
Behalten Sie Absenderidentität, Rendering, Linkverarbeitung und relevante Routingkonfiguration bei. Dokumentieren Sie bewusst eingeführte Unterschiede, damit später klar ist, welchen Ablauf das Ergebnis beschreibt.
3. Einen eigenen LDM-Test anlegen
Geben Sie die tatsächliche Absenderadresse bei LDM Inbox Placement ein und beziehen Sie die aktuellen Testempfänger. Behandeln Sie diese Gruppe als temporär. Sie gehört weder in einen dauerhaften Verteiler noch in Warmup-Aktivitäten oder fortlaufende Sequenzen.
Prüfen Sie, ob Konto und Empfängerworkflow den Versand erlauben. Umgehen Sie keine Suppression oder andere Beschränkung, nur um einen vollständigen Bericht zu erzeugen.
4. Die wirksame Einstellung kontrollieren
Prüfen Sie für die Mail Send API unmittelbar vor der Übermittlung den tatsächlichen Wert von mail_settings.sandbox_mode.enable. Die API-Referenz definiert einen Boolean. false und die Zeichenfolge "false" sind nicht austauschbar. Verwenden Sie für diesen einzelnen echten Versand die unterstützte Konfiguration außerhalb des Sandbox-Modus.
Eine Prüfung des sichtbaren Quellcodes kann umgebungsspezifische Überschreibungen übersehen. Kontrollieren Sie die wirksame Einstellung, ohne Zugangsdaten offenzulegen. Andere Entwicklungsaufträge bleiben von echten Empfängern getrennt.
5. Eine Originalnachricht erzeugen
Lassen Sie die Anwendung direkt für die Testempfänger eine neue Nachricht erzeugen. Leiten Sie keine bereits empfangene Kopie aus einem anderen Postfach weiter: Das würde Versandweg und Nachrichtenkontext verändern.
Sichern Sie Übergabeergebnis, Zeitpunkt, verfügbare Nachrichtenreferenz, Vorlagenrevision und Auftragskennung. Ziehen Sie die anschließenden Versandereignisse hinzu. Eine erfolgreiche Übermittlung eröffnet die Nachverfolgung; sie misst noch keinen Ordner.
6. Postfachbefund und Versanddatensatz zusammen lesen
Wenden Sie die Unterscheidungen der LDM-Methodik an. Fehlende oder unbekannte Ergebnisse sind nicht Spam. Promotions ist eine empfangene Kategorie, getrennt von Primary Inbox und Spam. Bestätigte Beobachtungen und unvollständige Prüfungen bleiben im Bericht sichtbar.
Das 24-Stunden-Fenster beobachtet dieselbe empfangene Kopie und sendet sie nicht erneut. Eine später übermittelte überarbeitete Vorlage gehört zu einem neuen Experiment, nicht zu einem weiteren Prüfpunkt der ursprünglichen Nachricht.
Hypothetisches Beispiel: Erfolg ohne Zustellung
Ein Entwickler setzt Seed-Empfänger in einen Staging-Request ein. Die Antwort lautet 200 OK, im Anwendungsprotokoll steht „E-Mail erfolgreich“, doch bei den Empfängern erscheint nichts. Das Team beginnt, die Absenderdomain zu untersuchen.
Dann zeigt die wirksame Konfiguration, dass Sandbox Mode weiterhin aktiviert war. In diesem hypothetischen Fall erklärt der nicht zustellende Request die Abwesenheit. Eine Spamplatzierung wurde überhaupt nicht beobachtet. Das Protokoll sollte präziser unterscheiden, ob die Validierung oder die echte Übermittlung erfolgreich war.
Ein anschließender zulässiger Versand mit begrenzten Empfängern liefert erstmals Kopien, deren Ordner untersucht werden können. Diese Ergebnisse machen die vorherige Sandbox-Validierung rückwirkend nicht zu einer fehlgeschlagenen Zustellung.
Auf der richtigen Ebene nach Ursachen suchen
Prüfen Sie bei unklaren Ergebnissen zuerst, welcher Auftrag ausgeführt wurde, was er übermittelte und ob Zustellung vorgesehen und erlaubt war. Lesen Sie danach Transportereignisse und Postfachbeobachtung samt Zeitpunkt. Requestfehler, verhinderter Versand und fehlgeschlagene Beobachtung benötigen unterschiedliche Erklärungen.
Ändern Sie Vorlage, Domain, Tracking und Route nicht gleichzeitig, wenn Sie eine einzelne Ursache eingrenzen möchten. Ein Test einer vollständig neuen Konfiguration kann betrieblich sinnvoll sein, isoliert jedoch nicht die Wirkung ihrer einzelnen Bestandteile. Das Seed-Ergebnis beschreibt die beobachteten Kopien und ist keine Zusage für die gesamte Zielgruppe.
Häufige Fragen
Zeigt Sandbox Mode, ob die Nachricht in Spam landet?
Nein. Es existiert keine zugestellte Kopie für diese Beobachtung. Für eine Ordnerprüfung brauchen Sie einen gesonderten zulässigen echten Versand an ein externes Postfach.
Warum fehlen Webhook-Ereignisse für den Sandbox-Request?
Das entspricht dem dokumentierten Verhalten. Kontrollieren Sie die wirksame Sandbox-Einstellung, bevor Sie einen Instrumentierungsfehler vermuten. Ein solcher Request prüft nicht die gesamte Ereigniskette eines echten Versands.
Belegt die Validierung eine korrekte dynamische Vorlage?
Nein. Prüfen Sie erzeugten Inhalt und Testdaten separat. Fehlende Personalisierung, falsche bedingte Abschnitte oder unbeabsichtigte Links erfordern eine Inhaltsprüfung unabhängig von der Gültigkeit des Requests.
Sollte ich alle Seed-Adressen sichtbar in To eintragen?
Behalten Sie die Empfängerstruktur des untersuchten Ablaufs bei. Mehrere sichtbare Empfänger bilden keine Anwendung nach, die normalerweise eine eigene Nachricht pro Empfänger erzeugt. Begrenzen Sie den Test trotzdem ausdrücklich.
Was bedeutet eine fehlende Kopie neben einer Spamkopie?
Halten Sie beide Befunde getrennt fest. Untersuchen Sie die fehlende Kopie anhand von Versanddaten und Beobachtungsstatus. Die bestätigte Spamplatzierung der anderen Kopie beweist nicht, wo die fehlende Nachricht liegt.
Nach der Validierung die echte Nachricht messen
Starten Sie einen LDM-Platzierungstest, wenn Request und Inhalt für den begrenzten echten Versand bereit sind. Die Oberfläche ist auch auf Deutsch verfügbar. Dokumentieren Sie Validierung, Übermittlung und Postfachbefund als getrennte Schritte.