E-Mail Prompt Injection

Was ist E-Mail Prompt Injection?

E-Mail Prompt Injection ist die mailspezifische Form der indirekten Prompt Injection: anweisungsartiger Text in einer eingehenden Nachricht erreicht ein KI-System, weil dieses System die Nachricht im Rahmen eines menschlichen oder automatisierten Workflows liest. Triage-Assistenten, Thread-Zusammenfassungen, Ticket-Klassifikation, CRM-Übernahme und Assistenzagenten für Führungskräfte holen Mail-Inhalte konstruktionsbedingt in den Modellkontext. Genau das ist die Zustellfläche.

Das prägende Merkmal gilt auf jedem indirekten Pfad, aber E-Mail verschärft es. Eingehende Post ist Inhalt, der außerhalb der Organisation verfasst wurde, und sie bleibt extern und nicht vertrauenswürdig, auch wenn sie über eine vertrauenswürdige Mail-Plattform, einen authentifizierten Connector oder eine eigene API ankommt. Der Transport kann einwandfrei sein, während der Nachrichteninhalt bösartig oder angreiferkontrolliert sein kann. Angreifer brauchen kein Konto im AI-System, müssen nie mit dem Assistenten sprechen und wissen oft nicht einmal, dass es ihn gibt: eine Nachricht an eine Adresse zu senden, die ein Workflow liest, genügt als Erreichbarkeit.

Zwei Fragen gehören von Anfang an getrennt. Ob Mail-Inhalte das Modell beeinflussen, ist eine Frage des Modellverhaltens. Ob diese Beeinflussung eine Sicherheitsfolge hat, ist eine Architekturfrage: Sie hängt davon ab, ob ein Fähigkeits- oder Datenpfad existiert und ob eine anwendungsseitige Kontrolle fehlt, zu weit gefasst ist oder versagt. Die meiste Beeinflussung sollte in einem seltsamen Entwurf enden. Zur Schwachstelle wird sie, wenn der Workflow beeinflusste Ausgaben senden, weiterleiten, offenlegen oder schreiben lässt.

Die Zustellkette von Ende zu Ende

Mail erreicht ein Modell über mehr Stationen, als das Bild vom Postfach mit angeschlossenem Assistenten nahelegt. Jede Station ist zugleich eine Stelle, an der Vertrauen falsch etikettiert werden kann, und eine Stelle, an der eine Kontrolle sitzen kann.

Die entscheidende Grenze verläuft zwischen vertrauenswürdiger Mail-Infrastruktur oder vertrauenswürdigen Komponenten und den nicht vertrauenswürdigen Inhalten, die sie transportieren. Die Organisation darf Mail-Infrastruktur, Connector und Parser berechtigterweise als Systemsoftware vertrauen, doch diese Eigenschaft geht nicht auf die Nachricht über. Eine vertrauenswürdige Leitung heiligt ihre Fracht nicht. Transportechtheit, Zustellzuverlässigkeit und API-Authentifizierung beantworten Fragen über den Kanal, aber keine davon sagt aus, ob Text in der Nachricht einen AI-Mail-Workflow steuern darf. Parsing, Normalisierung und Zusammenfassung müssen daher Provenienz und Vertrauenskennzeichnungen des Inhalts durch die gesamte Kette erhalten.

Besondere Aufmerksamkeit verdient die Normalisierung, denn sie entscheidet, was das Modell tatsächlich sieht. Ob die Textalternative, der aufbereitete HTML-Teil, die vollständige Zitathistorie oder eine vom Connector erzeugte Zusammenfassung gewählt wird, führt aus derselben Nachricht zu deutlich unterschiedlichem Kontext. Was auch immer gewählt wird: Das Modell liest Aufgabenanweisungen und externen Nachrichtentext im selben Fenster und kann beides als handlungsleitend behandeln. Ab dort ist die Modellausgabe ein Vorschlag. Das abschließende Autorisierungs- und Ausführungstor über Empfänger, Datenklasse, Aktionsumfang und Ziel ist die letzte deterministische Kontrolle vor einer Nebenwirkung. Deterministische Kontrollen können aber auch frühere Stationen durch Datenminimierung, Parser- und Darstellungsgrenzen, Fähigkeitsbegrenzung, Empfänger- und Zielrichtlinien sowie Egress-Kontrollen einschränken.

Welche E-Mail-Bestandteile modellsichtbar werden

Auch eine Nachricht ist nicht ein einziger Text. Jede Integration macht dem Modell eine andere Teilmenge der folgenden Bestandteile sichtbar. Die Anforderung lautet, genau zu wissen, welche Teilmenge in den Kontext gelangt, und die Provenienz jedes Teils erhalten zu halten.

Die Provenienz muss die gesamte Kette überstehen. Eine brauchbare Aufzeichnung verbindet den modellsichtbaren Abschnitt mit einer stabilen Nachrichtenkennung, der Position im Thread, der gewählten Darstellung, der Information, ob der Abschnitt aus dem neuen Text oder aus der Zitathistorie stammt, und der Angabe, ob er aus einem Anhang und über welchen Extraktor kam. Sobald eine Transformation die Herkunft löscht, kann die nachgelagerte Richtlinie extern zugestellten Text nicht mehr von anwendungseigenen Anweisungen oder modellerzeugten Entwürfen unterscheiden, und eine Untersuchung kann nicht rekonstruieren, welcher Abschnitt welchen Vorschlag beeinflusst hat.

Authentifizierung ist keine Anweisungsautorität

Die Mechanismen lohnen eine präzise Formulierung, denn die unpräzise Fassung ist die Quelle des Fehlers. SPF (RFC 7208) prüft, ob der sendende Host für die RFC5321 MAIL FROM-Domain autorisiert ist, und kann HELO oder EHLO getrennt davon bewerten. DKIM (RFC 6376) signiert einen Hash, der aus ausgewählten kanonisierten Header-Feldern und einem Hash des kanonisierten Nachrichtenkörpers gebildet wird; Signaturdomain und Selektor kennzeichnen die Signatur, und ihre Prüfung belegt nur das davon Abgedeckte. DMARC (RFC 9989) bewertet, ob authentifizierte SPF- oder DKIM-Kennungen zur sichtbaren RFC5322.From- beziehungsweise Author Domain ausgerichtet sind. Die Werte p, sp und np drücken die Domain Owner Assessment Policy aus - eine Präferenz zur Nachrichtenbehandlung, die bei nicht bestandenem DMARC in die lokale Entscheidung des Mail-Empfängers einfließen kann. Die abschließende Behandlung bleibt lokale Empfängerrichtlinie. RFC 8601 definiert Authentication-Results zur Aufzeichnung von Authentifizierungsstatus. Nachgelagerte Systeme dürfen dem Feld jedoch nur vertrauen, wenn es von einem vertrauenswürdigen Authentifizierungsdienst innerhalb der administrativen Vertrauensgrenze des Empfängers oder von einem ausdrücklich vertrauten vorgelagerten Dienst erzeugt wurde. Eine extern gelieferte Instanz ist nicht allein deshalb autoritativ, weil der Header vorhanden ist.

Auch ein bestandener DMARC-Check ist weder eine ausdrückliche noch eine implizite Aussage über Wert, Sicherheit oder Vertrauenswürdigkeit der Nachricht oder ihres Domain-Inhabers. Er schafft keine AI-Anweisungsautorität. RFC 9989 wurde im Mai 2026 veröffentlicht, ist die aktuelle DMARC-Spezifikation und ersetzt RFC 7489 sowie RFC 9091.

Vier Konstellationen brechen die Abkürzung in der Praxis. Eine authentifizierte Domain kann kompromittiert sein, dann ist die Identität echt und die Absicht nicht. Eine Domain kann von Angreifern registriert und korrekt konfiguriert werden, was trivial ist. Versand kann legitim an Drittplattformen delegiert sein, sodass eine ausgerichtete Domain-Identität Inhalte abdeckt, die der Domain-Inhaber nie geprüft hat. Und am häufigsten schreibt ein völlig legitimer Absender Text, der Daten bleiben muss: Kundschaft zitiert eine Formulierung, ein Dienstleister leitet eine Mitteilung weiter, eine Kollegin fügt einen Dokumentauszug ein. Nichts davon ist ein Authentifizierungsfehler. Es sind Fälle, in denen Authentifizierung nie die Frage war.

Für interne Domains gilt dasselbe. Eine Nachricht, die zur eigenen Domain der Organisation ausgerichtet ist, kann zitierten externen Text, eine weitergeleitete Kundennachricht oder einen Anhang von außen enthalten. Die Ausrichtung sagt, welche Domain-Identität verwendet wurde, nicht, wer den Satz verfasst hat, den das Modell gerade liest.

Vertrauensgrenzen in Mail-Workflows

Mehrere Komponenten eines Mail-Workflows sind berechtigterweise vertrauenswürdige Infrastruktur. Diese Eigenschaft gehört den Komponenten, nicht dem Inhalt, der sie durchläuft, und genau an dieser Unterscheidung muss die Grenze gezogen werden.

Wie überall auf dem indirekten Pfad müssen für jeden mailbasierten Schritt vier Fragen getrennt beantwortet werden. Quellenvertrauen: Wer hat diesen Abschnitt tatsächlich verfasst, und woher wissen wir das? Anweisungsautorität: Darf dieser Text Verhalten steuern - bei eingehenden Mail-Inhalten lautet die Antwort nein. Datenvertraulichkeit: Welche modellsichtbaren Daten darf dieser Inhalt beeinflussen, referenzieren oder mitnehmen? Aktionsautorisierung: Was darf die Anwendung daraufhin tun, für dieses Principal, auf dieser Ressource, zu diesem Ziel? Diese Fragen in "der Absender ist authentifiziert" zusammenzufassen, ist genau das Versagen, das diese Fläche immer wieder hervorbringt.

Threads, Zitate und Provenienz

Threading macht den Unterschied zwischen E-Mail und einem einzelnen abgerufenen Dokument. Ein Thread ist ein wachsendes, teils externes, teils internes Artefakt, das der Workflow in jeder Runde erneut liest, und die Provenienz zerfällt darin, solange das Design sie nicht aktiv erhält.

Die Zitathistorie ist der Kernmechanismus. Text, den eine externe Partei vor Wochen geschrieben hat, wird in jeder Antwort mitgeführt, und jede Weitergabe entfernt ihn weiter von seinem Ursprung. Bei der zehnten Nachricht sitzt anweisungsartiger Inhalt von außen mitten in einem Gespräch, das sich intern anfühlt, direkt neben Texten von Kolleginnen und Kollegen, ohne dass die Darstellung noch markiert, wo die Grenze verläuft. Ein Modell, das den Thread liest, sieht ein durchgehendes Dokument. Wenn auch die Anwendung ein durchgehendes Dokument sieht, wurde alter externer Text stillschweigend in vertrauenswürdigen Gesprächszustand befördert.

Weiterleitungen verwischen die Identität auf verwandte Weise. Eine weitergeleitete Nachricht kommt mit einem neuen, möglicherweise internen, authentifizierten Absender an, während ihr Text den Inhalt einer anderen Partei enthält. Envelope-Identität, sichtbare Absenderidentität und die Urheberschaft des zitierten Inhalts sind drei getrennte Tatsachen, und eine Weiterleitung lässt sie optisch zusammenfallen. Verteilerlisten, gemeinsame Adressen, Ticket-Gateways und Connectors legen eine weitere Schicht darüber: Sie können Header umschreiben, Hüllen ergänzen, Banner voranstellen oder den Text umbauen, sodass die Darstellung, die das Modell liest, nicht die ist, die der ursprüngliche Absender verfasst hat.

Abgeleitete Artefakte sind das Problem zweiter Ordnung. Wenn ein Assistent einen Thread zusammenfasst und diese Zusammenfassung gespeichert, in einer späteren Sitzung angezeigt oder erneut in den Kontext gegeben wird, kommt sie meist ohne die Grenzen ihrer Quellen an. Anweisungsartiger Inhalt aus einem externen Zitat kann in einer Zusammenfassung überleben, als wäre er eine Schlussfolgerung des Assistenten. Die Zusammenfassung liest sich nun systemerzeugt und intern, und ihre Herkunft ist verschwunden.

Praktikable Provenienz für Mail-Workflows hält für jeden Abschnitt eine stabile Nachrichten- und Thread-Kennung fest, erfasst Position und Richtung im Thread (eingehend extern, eingehend intern, ausgehend), unterscheidet bei der Extraktion neuen Text von Zitathistorie, markiert Abschnitte aus Anhängen mit Quelle und Extraktor und erfasst die Herkunftslinie jeder abgeleiteten Zusammenfassung, sodass sich eine Zusammenfassung auf die genauen Nachrichten und Abschnitte zurückführen lässt. Es gilt dieselbe Invariante wie auf der Web-Zustellfläche: Transformation darf die Herkunft nicht löschen.

Besonders exponierte E-Mail-Workflows

Kein Workflow ist von sich aus verwundbar. Exposition entsteht aus der Kombination: externe Mail lesen und zugleich einen Fähigkeits- oder Datenpfad besitzen, den beeinflusste Ausgaben erreichen können. Die folgenden Muster verdienen Aufmerksamkeit, weil sie meist beides verbinden.

Die brauchbare Prüffrage lautet nicht "ist dieser Workflow riskant", sondern "was kann beeinflusste Ausgabe von hier aus erreichen": welche Empfänger, welche Datensätze, welche Zugangsdaten, welche Netzwerkziele - und welche dieser Schritte laufen heute über eine deterministische Autorisierungsentscheidung statt über das Urteil des Modells.

Offensive Review-Fragen

Eine autorisierte Mail-Prüfung sollte die Nachricht von der Absenderkontrolle bis zu einer beobachtbaren Wirkung verfolgen, ohne erfolgreiche Zustellung oder Authentifizierung als Anweisungsautorität zu behandeln. Jede Darstellung und Aktionsgrenze ist ein eigenes Erfolgstor.

Beispiel: ein AI-Mail-Assistent

Ein Support-Engineer bittet einen Assistenten, einen eingehenden Kunden-Thread zu prüfen und die Nachfassarbeit zu organisieren. Der Assistent kann das Postfach lesen, Antworten entwerfen und - in dieser Konfiguration - senden und weiterleiten.

Beide Hälften der Lektion zählen. Die Beeinflussung war real und messbar: ein externer Abschnitt hat den Plan des Assistenten verändert. Die Sicherheitsauswirkung war null, weil das Design die Modellausgabe als Vorschlag behandelte und Empfänger, Datenklasse, Aktionstyp und Provenienz deterministisch bewertete. Wäre derselbe Assistent so verdrahtet, dass vorgeschlagene Sendungen direkt ausgeführt werden, hätte dieselbe Nachricht eine Offenlegung von Kundendaten erzeugt - ohne jedes Versagen im Mail-Stack.

Folgeaktionen und Datenoffenlegung

"Der Assistent hat etwas mit der E-Mail gemacht" verdeckt die Unterschiede, die die Schwere bestimmen. Jede der folgenden Aktionen hat andere Nebenwirkungen, eine andere Reichweite und einen eigenen Autorisierungsbedarf.

Zwei Punkte verdienen eine eigene Erwähnung. Modellsichtbaren internen Kontext in eine ausgehende Antwort zu kopieren, ist eine Offenlegung, die wie normale Arbeit aussieht: In der Aktionsschicht geschah nichts Ungewöhnliches, nur die Nutzlast war falsch. Und dem Link zu folgen macht aus einem passiven Lesen eine ausgehende Anfrage, womit der Mail-Workflow das gesamte Egress-Problem der Web-Fläche erbt, einschließlich Weiterleitungen und Zielvalidierung.

Freigabe und Zielbindung

"Human in the Loop" ist für sich genommen keine Kontrolle. Eine Freigabe, die eine Zusammenfassung zeigt und eine Bestätigungsschaltfläche anbietet, erzieht Menschen zum Bestätigen und autorisiert nichts Bestimmtes. Eine Freigabe ist erst dann eine Sicherheitskontrolle, wenn sie eine Entscheidung an eine exakte, unveränderliche Beschreibung des Geschehens bindet.

Die Bindung ist wegen einer Lücke zwischen Prüfzeitpunkt und Ausführungszeitpunkt wichtig. Wird gegen eine Beschreibung freigegeben und liest die Ausführung anschließend einen späteren, veränderlichen Zustand, deckt die Freigabe die Aktion nicht mehr ab. Jede Änderung an Empfängern, Anhängen, Parametern, Ziel oder Aktionstyp nach der Freigabe macht diese ungültig und muss eine erneute Bewertung erzwingen, in den meisten Designs eine erneute Freigabe. Praktisch heißt das: Das freigegebene Objekt ist der Autorisierungseintrag, und die Ausführung handelt auf der freigegebenen Beschreibung, nicht auf einem Plan, den das Modell noch ändern kann.

Freigaben müssen außerdem sparsam eingesetzt werden, um bedeutsam zu bleiben. Für jeden Entwurf eine Bestätigung zu verlangen, zerstört die Aufmerksamkeit; sie für die Schritte zu verlangen, die Empfänger ändern, eine Datenklasse überschreiten, die Organisation verlassen oder in ein gemeinsames System schreiben, erhält sie. Alles Übrige sollte die Richtlinie ohne Menschen im Pfad erledigen.

Erkennung und Telemetrie

Erkennung auf dem Mail-Pfad verbindet deterministische Aufzeichnungen des Systemverhaltens mit probabilistischen Signalen über Inhalte. Die Aufzeichnungen belegen, was geschehen ist; die Signale zeigen, wo hinzusehen ist. Keines ersetzt das andere.

Die Grenzen gehören offen benannt. Inhaltsklassifikatoren erzeugen Fehlalarme bei legitimer Post, die KI-Verhalten diskutiert, Richtlinien zitiert oder Sicherheitshinweise weiterleitet; ihre Ausgabe darf daher Aufmerksamkeit priorisieren, aber keinen Verkehr blockieren. Authentifizierungsevidenz belegt Identitätstatsachen, keine inhaltliche Absicht. Telemetrie kann belegen, welcher Abschnitt beim Vorschlag im Kontext war, aber keine Kausalität im Modell beweisen. Und die Korrelation von Vorschlag und Aktion existiert nur, wenn die Architektur beides trennt - tut sie das nicht, ist das Fehlen dieser Telemetrie selbst der Befund.

Prävention und sichere Architektur

Das Ziel ist kein Modell, das sich von einer Nachricht nicht beeinflussen lässt. Das Ziel ist eine Architektur, in der keine Nachricht, wie überzeugend auch immer, von sich aus einen Versand, eine Offenlegung oder einen Schreibvorgang auslösen kann.

1. 01
   Provenienzerhaltend parsen

   Die Darstellung bewusst wählen, Zitathistorie und Text aus Anhängen markieren und stabile Nachrichten- und Abschnittskennungen vergeben, bevor etwas das Modell erreicht.

2. 02
   Nicht vertrauenswürdige Inhalte kennzeichnen

   Eingehende Mail dem Modell als externen, nicht vertrauenswürdigen Inhalt getrennt von Aufgabenanweisungen vorlegen und die Kennzeichnung durch Zusammenfassung und Planung erhalten.

3. 03
   Modellsichtbare Daten minimieren

   Keine Zugangsdaten, keine unbeteiligten Postfachinhalte und keine breiten Kundendatensätze neben eingehende Mail legen, solange die Aufgabe das nicht wirklich erfordert.

4. 04
   Ambiente Befugnisse entfernen

   Keine dauerhaften Rechte auf Postfach, CRM oder Kalender für den Agenten. Fähigkeiten sollten aufgabenbezogen, kurzlebig und für Lesen, Entwerfen und Senden getrennt vergeben sein.

5. 05
   Vorschlag von Ausführung trennen

   Das Modell schlägt vor; deterministische Logik autorisiert Principal, Aktion, Ressource, Empfänger und Ziel.

6. 06
   Freigabe an die exakte Aktion binden

   Eine bestimmte unveränderliche Beschreibung freigeben und neu bewerten, sobald sich Empfänger, Anhänge, Parameter oder Aktionstyp ändern.

7. 07
   Ziele und Egress validieren

   Empfängermengen, Linkziele und ausgehende Endpunkte stammen aus der Richtlinie, nie aus Text in einer Nachricht.

8. 08
   Provenienz durch Zusammenfassungen tragen

   Abgeleitete Zusammenfassungen und Thread-Gedächtnis führen die Herkunftslinie mit, damit externe Inhalte nicht zu internem Zustand umgewidmet werden.

Die Schichten ergänzen einander, und keine genügt allein. Kennzeichnung und Klassifikation senken die Exposition, bleiben aber beratend und probabilistisch. Autorisierung außerhalb des Modells ist die Schicht, die aus einem beeinflussten Plan ein Nichtereignis macht; alle anderen Schichten sorgen dafür, dass deren Aufgabe kleiner und besser beobachtet ist. Der Abwehr-Hub ordnet diese Kontrollen nach Familien.

Incident Response

Mail-Vorfälle haben ein besonderes Beweisproblem: Postfächer sind veränderlich, die Automatisierung läuft weiter, und abgeleitete Zusammenfassungen verbreiten sich, während die Untersuchung erst beginnt. Zuerst sichern, dann eingrenzen.

Diese abschließende Feststellung wiegt schwerer, als sie klingt. "Beeinflusst, aber eingedämmt" und "beeinflusst und ausgeführt" verlangen unterschiedliche Schweregrade, unterschiedliche Meldungen und unterschiedliche Korrekturen. Festzuhalten, welche konkrete Kontrolle gehalten hat, hält die Behebung auf die Lücke gerichtet, statt zu dem pauschalen Schluss zu führen, der Assistent sei generell nicht vertrauenswürdig.

Kontrollierte Tests

Getestet wird mit synthetischen Nachrichten in isolierten Postfächern der Testumgebung, nie mit echter Kundenpost und nie durch Testsendungen an Dritte. Es geht darum, die Architektur zu beanspruchen, nicht darum, wirksame Formulierungen zu finden.

Die gleichen Vertrauensentscheidungen zeigt das Lab zu Prompt Injection über E-Mails konzeptionell an fiktiven Nachrichten: Connector- und Absendernachweise sind dort von Anweisungsbefugnis getrennt.

Variiert werden die Dimensionen, von denen das Design tatsächlich abhängt: Darstellung (reiner Text gegenüber aufbereitetem HTML), Platzierung im neuen Text gegenüber der Zitathistorie, Thread-Tiefe, Text aus Anhängen, authentifizierte gegenüber nicht authentifizierten Absenderdomains, interne gegenüber externen Absendern, weitergeleitete gegenüber direkt empfangenen Nachrichten sowie Vorschläge, die Ziele außerhalb der Aufgabe benennen. Abdeckung über diese Dimensionen erzeugt brauchbare Befunde; eine einzelne gebaute Nachricht prüft einen einzigen Pfad.

Die Ergebnisse gehören in getrennte Kennzahlen. Ein zusammengefasster Score mittelt genau die Unterschiede weg, die die Schwere bestimmen.

Die Kombinationen wollen sorgfältig gelesen werden. Eine hohe Influence Rate bei niedriger Unauthorized Action Rate zeigt, dass Autorisierung und Eindämmung auf Aktionsebene halten - die Kontrolle, die Auswirkungen begrenzt, funktioniert. Das beschreibt kein gesundes oder fertiges System: Es bleibt erhebliche Exposition der Modellintegrität und des Workflows, und jede verbleibende Kontrolle trägt deren volles Gewicht. Die umgekehrte Kombination, wenig gemessene Beeinflussung bei nennenswerter Unauthorized Action Rate, ist eine ernste Exposition, denn die wenigen Beeinflussungen erreichen dann ungebremst Wirkungen.

Häufige Implementierungsfehler

Standards und Forschungskontext

OWASP LLM01:2026 benennt nicht vertrauenswürdige externe Inhalte als Zustellpfad für indirekte Prompt Injection, und die NIST-Terminologie fasst indirekte Injection als Ausführung über die Kontrolle einer Ressource statt über Nutzereingaben - und genau das ist ein eingehendes Postfach. Greshake et al. haben das Muster 2023 in realen LLM-integrierten Anwendungen gezeigt. Die Microsoft-Leitlinien zur Abwehr indirekter Prompt Injection und zu geringsten Rechten für KI-Agenten adressieren die Fähigkeitsseite, die darüber entscheidet, ob aus Beeinflussung eine Auswirkung wird.

Forschung zur Durchsetzung außerhalb des Modells lässt sich unmittelbar auf Mail-Workflows anwenden. CaMeL trennt Kontroll- und Datenfluss und wendet fähigkeitsbasierte Richtlinien an, damit nicht vertrauenswürdige Inhalte privilegierte Aktionen nicht umlenken können - Senden und Weiterleiten sind genau solche Aktionen. AttriGuard fragt, ob ein vorgeschlagener Werkzeugaufruf kausal auf die Nutzerabsicht oder auf eine nicht vertrauenswürdige Beobachtung zurückgeht, was direkt der Frage entspricht, ob ein vorgeschlagener Empfänger aus der Aufgabe oder aus einem zitierten Abschnitt stammt.

Die E-Mail-Authentifizierungsstandards stehen hier, weil diese Seite faktische Aussagen darüber trifft, was sie festlegen, und nicht, weil sie Prompt-Injection-Kontrollen wären. SPF, DKIM, DMARC und Authentication-Results gehören zu einer eigenständigen Identitäts- und Authentifizierungsschicht. Sie verringern Spoofing und unterstützen Filterung und Berichterstattung; sie waren nie dafür gedacht zu entscheiden, ob Text einen KI-Workflow steuern darf, und sie so zu verwenden, ist der zentrale Fehler auf dieser Fläche. Kein E-Mail-Standard behandelt Prompt Injection gezielt.

Häufige Fragen