Überblick über Email Delivery

Email Delivery verwendet die in diesem Abschnitt beschriebenen Komponenten.

GENEHMIGTE ABSENDER

Ein genehmigter Absender ist eine Ressource, die der Absenderadresse entspricht. Ein genehmigter Absender ist mit einem Compartment verknüpft und ist nur in der Region vorhanden, in der der genehmigte Absender konfiguriert wurde. Wenn Sie denselben genehmigten Absender in einer anderen Region benötigen, muss er in der anderen Region erstellt werden. Beispiel: Wenn Sie einen genehmigten Absender in der Region "US West (Phoenix)" erstellen, können Sie keine E-Mails über die Region "US East (Ashburn)" senden.

UNTERDRÜCKUNGSLISTE

Die Unterdrückungsliste ist in der Email Delivery-Benutzeroberfläche der Konsole und in der API enthalten. Email Delivery fügt E-Mail-Adressen mit Bouncecodes, die dauerhafte Fehler aufweisen, oder Benutzerbeschwerden automatisch zur Unterdrückungsliste hinzu, um die Absenderreputation zu schützen. Email Delivery sendet dann keine Nachrichten mehr an diese Empfänger.

Beispiele für die Unterdrückung:

• Beschwerden
• Hard Bounces
• Wiederholte Soft Bounces
• Manuelle Einträge
• Liste der Abmeldeanforderungen

SPF-AUTHENTIFIZIERUNG

Sender Policy Framework (SPF) wird von E-Mail-Empfängern verwendet, um E-Mail-Spoofing zu ermitteln. Mit SPF kann ein E-Mail-Empfänger prüfen, ob das Internet Protocol (IP) explizit zum Senden für diese Domain autorisiert ist. SPF wird implementiert, indem ein spezieller TXT-Record in den DNS-Records einer Domain veröffentlicht wird. Der TXT-Record deklariert, welche Hosts E-Mails im Auftrag dieser Domain senden dürfen. Posteingangsserver prüfen die SPF-Datensätze der sendenden Domains, um sicherzustellen, dass die Quell-IP-Adresse der E-Mail zum Senden von dieser Domain autorisiert ist. Ohne SPF kann eine Spam- oder Phishing-E-Mail durch "Spoofing" so aussehen, als komme die E-Mail von einer legitimen Domain. Bei Domains mit SPF ist die Wahrscheinlichkeit höher, dass E-Mails blockiert werden, die versuchen, Ihre Domain zu spoofen. Einen Überblick über die Funktionsweise von SPF finden Sie unter Sender Policy Framework. Details zur SPF-Datensatzsyntax finden Sie unter SPF-Datensatzsyntax.

SMTP-Zugangsdaten können für jede Region verwendet werden, da Identitäten globale Assets sind. Genehmigte Absender (Ihre Absenderadresse) müssen jedoch in jeder Region konfiguriert werden, die Sie für Email Delivery verwenden möchten. Um genehmigte Absender in jeder Region zu konfigurieren, wählen Sie im Menü "Region" in der Konsole eine Region aus, und erstellen Sie einen genehmigten Absender. Konfigurieren Sie Ihre Anwendung, um E-Mails an den Endpunkt der Region zu senden, in der Sie den genehmigten Absender mit den globalen SMTP-Zugangsdaten erstellt haben. Die sendende Anwendung muss sich nicht in der Region befinden, von der die E-Mails gesendet werden. Aus Performancegründen wird jedoch empfohlen, dass sie lokal oder so nah wie möglich ist.

Weitere Informationen finden Sie unter Regionen und Availability-Domains.

Email Delivery unterstützt alle nativen OCI-Authentifizierungsverfahren. Informationen hierzu finden Sie unter OCI-SDK-Authentifizierungsmethoden.

Email Delivery unterstützt alle nativen OCI-Authentifizierungsverfahren bei der Verwendung von HTTPS-E-Mail-Weiterleitungen. Weitere Informationen finden Sie unter OCI-SDK-Authentifizierungsmethoden. Außerdem wird der AUTH PLAIN-Befehl bei der SMTP-Authentifizierung unterstützt. Wenn die sendende Anwendung im Hinblick auf den AUTH-Befehl nicht flexibel ist, kann ein SMTP-Proxy/-Relay verwendet werden. Weitere Informationen zum AUTH-Befehl finden Sie unter AUTH-Befehl und seine Verfahren.

Informationen zu den regionalen Endpunkten, Ports oder Sicherheitsdetails zum Herstellen von HTTPS- oder SMTP-Verbindungen finden Sie in der Konsole unter HTTPS-Sendeinformationen und SMTP-Sendeinformationen. Weitere Informationen finden Sie unter HTTPS-Verbindung konfigurieren und SMTP-Verbindung konfigurieren.

Mit Metriken, Alarmen und Benachrichtigungen können Sie Zustand, Kapazität und Performance Ihrer Oracle Cloud Infrastructure-Ressourcen überwachen. Weitere Informationen finden Sie unter Monitoring und Notifications.

Informationen zu verfügbaren Servicemetriken für Email Delivery und deren Anzeige finden Sie unter Metriken für Email Delivery.

Eine Liste der anwendbaren Limits und Anweisungen zum Anfordern einer Erhöhung finden Sie unter Servicelimits. Um compartment-spezifische Grenzwerte für eine Ressource oder Ressourcenfamilie festzulegen, können Administratoren Compartment-Quotas verwenden.

Kunden, die sich für eine kostenlose Oracle Cloud-Testversion registrieren, haben folgende Einschränkungen:

• Ein Volumen von 200 E-Mails pro Tag, wobei eine E-Mail entweder als einzelner Empfänger in den Feldern "An:", "Cc:" oder "Bcc:" oder als Daten-Chunk von 2 MB definiert ist.

  E-Mail-Beispiele:

  • Eine einzelne Anforderung mit 10 Empfängern ("An:", "Cc:" oder "Bcc:") entspricht 10 E-Mails.

  • Eine E-Mail mit 10 MB, die an einen einzelnen Empfänger gesendet wird, entspricht 10 MB geteilt durch 2 MB pro E-Mail. Dies entspricht 5 E-Mails.

  • Eine einzelne E-Mail-Anforderung mit einer Nachrichtengröße von 10 MB, die an 10 Empfänger gesendet wird, entspricht 10 MB geteilt durch 2 MB pro E-Mail multipliziert mit 10 Empfängern. Dies entspricht 50 E-Mails.

• 2.000 Genehmigte Absender.
• Jeder Benutzer hat maximal zwei SMTP-Zugangsdaten.
• Senderaten sind auf 10 E-Mails pro Minute begrenzt.
• Inline-Anhänge und externe Anhänge.
• Maximale Nachrichtengröße von 2 MB einschließlich base64-Codierung und Headern

Enterprise-Accounts sind beschränkt auf:

• Ein Volumen von 50.000 E-Mails pro Tag, wobei eine E-Mail entweder als einzelner Empfänger in den Feldern "An:", "Cc:" oder "Bcc:" oder als Daten-Chunk von 2 MB definiert ist.

  E-Mail-Beispiele:

  • Eine einzelne Anforderung mit 10 Empfängern ("An:", "Cc:" oder "Bcc:") entspricht 10 E-Mails.
  • Eine E-Mail mit 10 MB, die an einen einzelnen Empfänger gesendet wird, entspricht 10 MB geteilt durch 2 MB pro E-Mail. Dies entspricht 5 E-Mails.
  • Eine einzelne E-Mail-Anforderung mit einer Nachrichtengröße von 10 MB, die an 10 Empfänger gesendet wird, entspricht 10 MB geteilt durch 2 MB pro E-Mail multipliziert mit 10 Empfängern. Dies entspricht 50 E-Mails.
  Dieses Limit gilt für separate Empfänger aller gesendeten E-Mails. Beispiel: Eine E-Mail, die an 100 Empfänger gesendet wird, wird genau wie 100 E-Mails gezählt, die an einen Empfänger gesendet werden.
• 10.000 genehmigte Absender.
• Senderaten sind auf 18.000 E-Mails pro Minute begrenzt.
• Inline-Anhänge und externe Anhänge.
• Maximale Nachrichtengröße von 2 MB einschließlich base64-Codierung und Headern

Email Delivery unterstützt standardmäßig Nachrichten mit einer Größe von bis zu 2 MB, einschließlich von Headern, Text und Anhängen. Je 2 MB Daten werden auf Ihr tägliches Sendevolumen und Ihre Senderatenlimits angerechnet. Beispiel: 10 MB werden als fünf E-Mails gezählt.

Bei einer Erhöhung des E-Mail-Grenzwerts sind SPF und DKIM für Ihre Absenderdomain und den genehmigten Absender erforderlich. Siehe SPF konfigurieren und DKIM konfigurieren.

Je nach Anforderung können Sie eine Limiterhöhung von bis zu 60 MB für die Nachrichtengröße beantragen.

Informationen zum Öffnen einer Serviceanfrage zur Erhöhung des Limits finden Sie unter Erhöhung des Servicelimits beantragen. Ihre Erhöhungsanforderung wird anhand folgender Informationen bewertet:

• Wie lauten Ihre aktuellen Absenderdomains?
• Erfüllen Ihre Sendepraktiken die Anforderungen von CAN-SPAM und CASL?
• Beschreiben Sie kurz den Typ der zu sendenden E-Mails. Sind die E-Mails beispielsweise Marketing, Bulk, Newsletter, Transaktion, Benachrichtigungen usw.?
• Senden Sie E-Mails zu Kleinkrediten oder Kreditkartenangeboten?
• Senden Sie E-Mails im Namen anderer Unternehmen?
• Wie melden sich die Empfänger für den Empfang dieser E-Mails an? Geben Sie alle Domains an, bei denen sie sich möglicherweise anmelden.
• Werden E-Mail-Adressen noch über andere Methoden erfasst?
• Wie viele E-Mails möchten Sie pro Monat senden?
• Mit welchem E-Mail-Anbieter senden Sie Ihre E-Mails?
• Wie viele Nachrichten müssen maximal mit Burst-Kapazität gesendet werden (innerhalb eines bestimmten Zeitrahmens)?
• Wie groß sind Ihre Nachrichten maximal?
• Wie viele E-Mails mit einer Größe von über 2 MB werden pro Tag gesendet?
• Sind Ihre Empfänger Oracle-E-Mail-Adressen (z.B. test.user@oracle.com)?
• Über welche Email Delivery-Region möchten Sie E-Mails senden?

Wenn Sie mit Policys nicht vertraut sind, finden Sie weitere Informationen unter Erste Schritte mit Policys und Allgemeine Policys. Weitere Details zu Policys für Email Delivery finden Sie unter Details für den Email Delivery-Service.

Berechtigungen sind für die Verwaltung und Verwendung genehmigter Absender und der Unterdrückungsliste erforderlich. Beispiel:

• So aktivieren Sie alle Vorgänge an genehmigten Absendern für eine bestimmte Benutzergruppe:

  Allow group <Your Group Name> to manage approved-senders in tenancy

• So aktivieren Sie alle Vorgänge an Unterdrückungen für eine bestimmte Benutzergruppe:

  Allow group <Your Group Name> to manage suppressions in tenancy

Wenn Sie einen Email Delivery-Serviceaccount erstellen, werden Ihre E-Mails standardmäßig von IP-Adressen gesendet, die mit anderen Oracle-Kunden gemeinsam verwendet werden.

Email Delivery unterstützt eigens für Sie dedizierte IP-Adressen, damit Sie vollständige Kontrolle über Ihre Reputation behalten. Sowohl eine Strategie mit gemeinsam genutztem IP-Pool als auch eine Strategie mit dedizierten IP-Adressen kann je nach Ihren Anforderungen und E-Mail-Streameigenschaften eine sehr gute Zustellung ermöglichen. Weitere Informationen zur gemeinsamen IP finden Sie unter Gemeinsame IP oder dedizierte IP.

Wenn Sie einen dedizierten Pool mit IP-Adressen von Oracle verwenden, wird nur Ihre Mail daraus gesendet.

Dedizierte IP-Adressen eignen sich ideal für Absender, für die Folgendes gilt:

• Sie senden regelmäßig große Mengen an E-Mails, um ihre eigene IP-Reputation aufrechtzuerhalten. Das konsistente Senden eines großen E-Mailvolumens wird von den automatisierten Filtern der Internet Service Provider (ISPs) verwendet, um Ihrer IP-Adresse eine Reputation zuzuweisen. Dies ist einer der Schlüsselfaktoren bei der Entscheidung, ob Ihre Nachrichten in den Posteingang oder den Spamordner zugestellt oder vorübergehend abgelehnt werden.
• Sie wollen vollständige Kontrolle über ihre Absenderreputation und verstehen Best Practices für die E-Mail-Zustellung. Wenn Sie für eine IP der einzige Absender sind, wird Ihre Reputation von anderen Absendern isoliert. Dies kann gut oder schlecht sein, je nachdem, wie genau Sie es mit den Sendepraktiken nehmen.
• Sie haben große Mengen an E-Mail aus verschiedenen Streams und möchten für jeden davon eine eigene Reputation schaffen. Mit dedizierten IPs können Sie separate IP-Reputationen basierend auf verschiedenen Typen von Mailstreams wie Transaktionsnachrichten oder Bulkversand von Marketing-E-Mails erstellen. Bei einem entsprechend hohen Volumen kann das Isolieren dieser Mailstreams das Risiko von Zustellungsproblemen für kritischere Nachrichtentypen reduzieren.

Dedizierte IP-Adressen eignen sich wahrscheinlich nicht für Absender, für die Folgendes gilt:

• Sie senden Mail inkonsistent mit geringen Volumen, sodass keine ISP-Reputation zugewiesen werden kann. Für den Aufbau einer IP-Reputation bevorzugen ISPs ein vorhersehbares E-Mail-Intervall mit ausreichendem E-Mail-Volumen, um eine Reputation zuzuweisen. Wenn diese Anforderung nicht erfüllt wird, kann dies zu Zustellungsproblemen führen. Wenn Sie in einem gemeinsamen IP-Pool mit vielen kleineren Absendern senden, erhält der ISP eine große Menge konsistenter E-Mails.
• Sie verstehen nicht die Best Practices für E-Mails, was zu einer Zustellung mit schlechter Reputation führen kann. Das Senden in einem gemeinsam mit anderen Kunden genutzten IP-Pool, der von Oracle verwaltet wird, kann für E-Mail-Einsteiger weniger riskant sein.

Ihre E-Mail-Merkmale (Volumen, Burst-Raten, Reputation usw.) hängen von Ihrer dedizierten IP-Strategie ab. Unsere Teams sind im Hinblick auf dedizierte IP-Adressen geschult und können Ihre diesbezüglichen Anforderungen jederzeit unterstützen. Wenn Sie Unterstützung bei Ihrer Konfiguration benötigen, können Sie zu My Oracle Support gehen und eine Serviceanfrage erstellen.

Sie können Tags auf Ihre Ressourcen anwenden, um diese entsprechend Ihren Geschäftsanforderungen zu organisieren. Sie können Tags beim Erstellen einer Ressource anwenden oder die Ressource später mit Tags aktualisieren. Allgemeine Informationen zum Anwenden von Tags finden Sie unter Ressourcentags.

Email Delivery unterstützt das Anwenden von Tags auf genehmigte Absender.

Email Delivery auditiert die folgenden Ereignisse:

• Absender erstellen (CreateSender)
• Absender löschen (DeleteSender)
• Details zu einem Absender abrufen (ListSenders)

Um Logs für Ereignisse im Email Delivery-Service anzuzeigen, muss Ihr Benutzer in einer Gruppe enthalten sein, die alle Auditereignislogs im Mandanten anzeigen kann. Weitere Informationen finden Sie unter Auditlogereignisse anzeigen.