Oracle Cloud Email Delivery Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application Development

Category

Application Development

1. Introduction

Oracle Cloud Email Delivery (often referred to in documentation as Oracle Cloud Infrastructure (OCI) Email Delivery) is a managed service for sending outbound email from your applications and systems—things like password resets, account verification, invoices, alerts, and operational notifications.

In simple terms: you connect your app to Oracle Cloud Email Delivery using standard SMTP, authenticate with SMTP credentials, and send emails reliably without running and maintaining your own mail servers.

Technically, Email Delivery provides a regional, cloud-managed email submission and delivery capability with governance features such as approved senders, optional email domains and DKIM signing, suppression list management (bounces/complaints), and integration with Oracle Cloud’s IAM, compartments, audit logging, and monitoring.

It solves a common problem in Application Development and platform operations: delivering transactional email at scale while reducing the operational burden and security risks of self-hosted SMTP servers and improving deliverability through authenticated sending practices.

Service name note: The exact service name used throughout this tutorial is Email Delivery. In official Oracle Cloud documentation, you may also see it presented as OCI Email Delivery. At the time of writing, Email Delivery is an active OCI service; verify current naming and scope in the official docs if Oracle updates branding.

2. What is Email Delivery?

Official purpose (practical definition):
Oracle Cloud Email Delivery is an Oracle Cloud Infrastructure service that enables you to send outbound email from applications and services using SMTP, with controls for sender identity, email authentication (for example DKIM), and bounce/complaint suppression.

Core capabilities

• Send outbound email via SMTP using region-specific SMTP endpoints.
• Define and verify Approved Senders (email addresses allowed to send).
• Configure Email Domains (domain-level sending identity) and set up DKIM signing for improved deliverability.
• Track and manage a Suppression List (addresses that should not receive email due to bounces/complaints or manual suppression).
• Use Oracle Cloud governance features:
• IAM policies and compartment-based access control
• Audit for control-plane actions
• Monitoring metrics for visibility (verify metric names and availability in your region in official docs)

Major components (conceptual model)

• SMTP submission endpoint (data plane): where your app submits messages.
• Approved Sender: a verified “From” address you are allowed to use.
• Email Domain + DKIM: domain-based authentication configuration for better reputation and deliverability.
• SMTP credentials: username/password created for an OCI user to authenticate to the SMTP endpoint.
• Suppression list: addresses that should not receive messages due to deliverability and complaint handling.

Service type and scope

• Service type: Managed outbound email (transactional) delivery service using SMTP submission.
• Scope: Primarily regional within OCI. Email Delivery resources (like approved senders/domains) and SMTP endpoints are region-associated.
• Verify regional availability in the official “Regions” and Email Delivery documentation.
• Tenancy/compartment integration: Resources are managed within an OCI tenancy, organized by compartments, and governed by IAM policies.

How it fits into the Oracle Cloud ecosystem

Email Delivery fits naturally into Application Development and platform operations on Oracle Cloud: – Compute workloads (Compute instances, Instance Pools) – Containerized apps (OKE) – Serverless (Functions) where networking permits outbound SMTP – CI/CD pipelines and operational tooling (sending job status notifications) – Observability-driven operations (alerts routed through application logic)

It complements (but does not replace) other messaging and integration services—Email Delivery is for email, not for general pub/sub or SMS.

3. Why use Email Delivery?

Business reasons

• Faster time-to-market: you don’t need to build and maintain a mail server infrastructure.
• Lower operational overhead: fewer components to patch, secure, and monitor.
• Better customer experience: more reliable delivery for transactional email (verification, receipts, alerts).

Technical reasons

• Standard SMTP integration: works with most languages, frameworks, and libraries.
• Governed sender identity: “approved sender” and domain-based setups reduce accidental spoofing and misconfiguration.
• Deliverability best practices: DKIM signing support and suppression handling help reduce spam-folder placement.

Operational reasons

• Compartment-based organization: separate dev/test/prod sending identities and policies.
• Metrics and visibility: operational insights without building your own telemetry (verify exact metrics in your region).
• Quotas/service limits: guardrails for safe usage and scaling.

Security/compliance reasons

• IAM-controlled administration: define who can create approved senders/domains and manage suppressions.
• Audit logging: changes to sending identities and suppression rules can be audited.
• TLS-based SMTP submission: use encrypted connections (STARTTLS / TLS) to reduce interception risk.

Scalability/performance reasons

• Designed for scalable outbound delivery without you maintaining MTAs, queues, or bounce processors.
• Supports use cases from small transactional volumes to high-volume application sending (subject to service limits).

When teams should choose Email Delivery

Choose Email Delivery when you need: – Transactional email from apps or platform workflows – A managed service that integrates into OCI IAM/compartments – A controlled and auditable way to manage senders/domains – A solution that avoids self-hosted SMTP complexity

When teams should not choose Email Delivery

Avoid Email Delivery when you need: – Inbound email processing (mailboxes, receiving, routing inbound mail) — Email Delivery is outbound-focused. – A complete marketing automation platform (campaigns, segmentation, A/B testing, templates, unsubscribe management at scale).
– For marketing-heavy workflows, consider specialized tools (Oracle products or third-party ESPs). – Full control over MTA behavior, custom queueing policies, or on-prem-only routing (self-managed might fit better).

4. Where is Email Delivery used?

Industries

• SaaS and software products (account verification, billing notices)
• E-commerce (order confirmations, shipping notifications)
• Financial services (transaction alerts, statements—subject to compliance)
• Healthcare (appointment reminders—subject to regulatory controls)
• Education (enrollment notifications, LMS alerts)
• Media and subscriptions (login links, alerts)

Team types

• Application developers and platform teams
• DevOps/SRE teams sending operational notifications
• Security teams integrating identity flows (MFA/verification emails)
• IT operations teams modernizing legacy app notifications

Workloads

• User lifecycle: sign-up, verification, password reset
• System events: job completion, failures, anomaly alerts
• Billing: invoices, receipts, payment failure notices
• Support: ticket updates, escalation notifications

Architectures

• Microservices: each service uses SMTP through a shared internal library
• Event-driven: events trigger functions that send emails
• Batch processing: scheduled jobs send summary reports
• Hybrid: on-prem apps send via OCI Email Delivery over the internet/VPN (networking permitting)

Real-world deployment contexts

• Production: DKIM-enabled domain sending, strict IAM, monitoring, suppression governance
• Dev/Test: separate approved senders, lower limits, test recipient addresses, controlled policies to avoid accidental outbound spam

5. Top Use Cases and Scenarios

Below are realistic scenarios where Oracle Cloud Email Delivery is commonly used. Each includes the problem, why Email Delivery fits, and a short example.

1. Password reset emails – Problem: Users need secure password reset links delivered quickly. – Why Email Delivery fits: SMTP integration is simple; DKIM improves deliverability; suppression reduces repeat failures. – Scenario: A web app sends a reset token email after a user requests password recovery.

2. New account verification – Problem: You must confirm that the user owns the email address. – Why it fits: Controlled approved sender identity; consistent delivery. – Scenario: After sign-up, the app emails a verification link.

3. Billing and invoice notifications – Problem: Customers must reliably receive invoices and payment receipts. – Why it fits: Operationally managed sending identity and domain authentication. – Scenario: A monthly billing job emails invoices (PDF links) to customers.

4. Order confirmation and shipping updates – Problem: Transactional updates must reach inboxes quickly. – Why it fits: Designed for transactional email flows from application backends. – Scenario: E-commerce backend sends “order placed” and “shipped” emails.

5. Operational alerts routed through application logic – Problem: Teams want to send tailored alerts (with context) rather than generic monitoring emails. – Why it fits: Application-controlled SMTP sending with your own templates/content. – Scenario: A pipeline detects failures and emails the owning team with logs/links.

6. CI/CD pipeline notifications – Problem: Build/deploy results should reach developers without relying on third-party email servers. – Why it fits: Easy SMTP integration from build agents; compartment separation per environment. – Scenario: Jenkins/GitHub Actions runner calls a script that sends an email summary.

7. Security notifications – Problem: Users need warnings about unusual login activity. – Why it fits: Controlled “From” identity reduces spoof risk; can sign with DKIM. – Scenario: App emails “New login from device X” alerts.

8. Scheduled report distribution – Problem: Stakeholders want daily/weekly reports by email. – Why it fits: Batch systems can send outbound messages on schedule via SMTP. – Scenario: A nightly job emails KPI summaries to executives.

9. Multi-tenant SaaS with compartment isolation – Problem: Different tenants require isolation and governance. – Why it fits: OCI compartments and IAM policies can separate identities and control access. – Scenario: Each tenant’s environment has distinct sending domain configuration.

10. Legacy application modernization – Problem: A legacy app expects an SMTP relay but you don’t want to host an MTA. – Why it fits: Email Delivery acts as the relay; minimal changes required. – Scenario: An on-prem app is re-pointed from local Postfix to OCI SMTP.

11. Edge-case: “Do-not-contact” enforcement – Problem: You must prevent sending to certain addresses for legal or customer preference reasons. – Why it fits: Suppression list management provides a centralized stop-list (validate workflow in official docs). – Scenario: Support adds addresses to suppression based on customer request.

12. Blue/green release testing for email flows – Problem: New release must be tested without affecting real customers. – Why it fits: Separate approved senders or separate compartments for staging. – Scenario: Staging environment sends only to internal test addresses.

6. Core Features

This section focuses on widely documented, current capabilities of Oracle Cloud Email Delivery. If your tenancy/region differs, verify in official docs.

6.1 SMTP-based sending

• What it does: Lets applications submit emails through SMTP using authenticated credentials.
• Why it matters: SMTP is universally supported; easiest integration path for most apps and tools.
• Practical benefit: Works with Python, Java, Node.js, .NET, PHP, Postfix relay mode, and more.
• Caveats: SMTP traffic is to a public endpoint; ensure outbound network access and TLS.

6.2 Approved Senders (verified “From” addresses)

• What it does: Restricts outbound sending to verified sender addresses.
• Why it matters: Prevents spoofing and reduces misconfigured apps sending as random addresses.
• Practical benefit: Easy to start: verify a single address and send test emails quickly.
• Caveats: For higher deliverability and brand alignment, domain-based configuration is recommended.

6.3 Email Domains and DKIM signing

• What it does: Allows domain-level configuration and DKIM keys/records so recipients can verify message authenticity.
• Why it matters: DKIM is a major deliverability factor; many organizations require authenticated sending.
• Practical benefit: Fewer spam-folder issues; improved trust and consistent branding.
• Caveats: Requires DNS access to publish DKIM records; DNS changes take time to propagate.

6.4 Suppression list management (bounces/complaints)

• What it does: Maintains a list of recipients that should not be emailed (for example, repeated bounces or complaints, and manually suppressed addresses).
• Why it matters: Repeatedly emailing invalid addresses harms sender reputation.
• Practical benefit: Helps protect deliverability and reduces wasted send attempts.
• Caveats: Understand your business process: manual suppression for “do not email” may be required in addition to bounce-based suppression.

6.5 IAM and compartment scoping

• What it does: Controls who can create/manage approved senders, domains, and suppression entries.
• Why it matters: Sending email is a sensitive capability; governance prevents abuse.
• Practical benefit: Enforce separation of duties (developers can send, security admins manage domains).
• Caveats: Design policies carefully to avoid over-permissive access.

6.6 Auditability (control-plane)

• What it does: OCI audit logs can record administrative actions (creating senders/domains, changing settings).
• Why it matters: Supports compliance and incident investigation.
• Practical benefit: Trace “who changed what” in production.
• Caveats: Audit covers management actions; it is not a full email content archive.

6.7 Monitoring and metrics

• What it does: Provides service-level metrics that help operators understand sending volume and delivery outcomes.
• Why it matters: You need to detect spikes, failures, or reputation-impacting issues quickly.
• Practical benefit: Alert on abnormal bounce rates or send failures (verify which metrics are exposed and how).
• Caveats: Metrics granularity and availability may differ by region; verify in docs.

6.8 SDK/CLI support for management operations

• What it does: Enables automation of management tasks (creating approved senders, querying suppression list).
• Why it matters: Infrastructure-as-Code and repeatability for multi-environment setups.
• Practical benefit: Integrate with CI/CD and provisioning workflows.
• Caveats: Email submission itself is typically via SMTP; API/CLI are primarily for management.

7. Architecture and How It Works

High-level architecture

Email Delivery has two primary planes:

1. Control plane (management): – Define and verify approved senders – Configure email domains and DKIM – Manage suppression list – Govern via IAM/compartments and track actions via Audit

2. Data plane (email submission and delivery): – Applications connect to a region-specific SMTP endpoint using SMTP credentials – Messages are processed and delivered to recipient mail systems – Bounces/complaints may influence the suppression list and metrics (verify details in official docs)

Request/data/control flow

1. Admin configures Approved Sender (and optionally domain + DKIM).
2. Admin creates SMTP credentials for an OCI user intended for sending.
3. Application uses SMTP (preferably TLS) to submit an email: – Authenticates using SMTP username/password – Uses an approved “From” address
4. Email Delivery attempts delivery to recipients’ mail servers.
5. Delivery outcomes influence: – Suppression list entries (for certain failures) – Monitoring metrics

Integrations with related Oracle Cloud services

Common OCI integrations include: – IAM: policies controlling Email Delivery management – Compartments: environment scoping (dev/test/prod) – Audit: change tracking – Monitoring/Alarms: operational visibility – OCI Functions / OKE / Compute: application hosts that send mail via SMTP – OCI Vault: store SMTP credentials securely (recommended)

Note: Some teams also integrate with OCI Events/Notifications patterns indirectly (for example, an event triggers a function; the function sends email via Email Delivery). Avoid assuming direct “bounce event streaming” integrations unless confirmed in official docs.

Dependency services

• DNS provider (OCI DNS or external): needed for DKIM records if you use email domains.
• Vault (optional but recommended): secrets storage for SMTP credentials.
• Networking egress: application must reach the public SMTP endpoint.

Security/authentication model

• SMTP authentication: uses SMTP credentials tied to an OCI user.
• Authorization governance: controlled by IAM policies for who can manage Email Delivery resources.
• Sender validation: “From” addresses must match configured approved senders and/or domain policies.

Networking model

• SMTP endpoints are public and regional. Your workloads must have outbound internet access (direct or via NAT gateway) to reach the endpoint.
• Use TLS/STARTTLS ports supported by Email Delivery (verify current ports and endpoints in official docs; commonly 587 for STARTTLS is used).

Monitoring/logging/governance considerations

• Use Monitoring metrics and alarms to detect:
• Spikes in sending volume
• Elevated bounce/complaint rates
• Authentication failures (where measurable)
• Use Audit to track:
• Creation/deletion of approved senders and domains
• Suppression list changes
• Policy changes affecting Email Delivery administration

Simple architecture diagram (starter)

flowchart LR
  A[Application / Script] -->|SMTP over TLS| S[Email Delivery SMTP Endpoint<br/>(Regional)]
  S --> R[Recipient Mail Servers]
  Admin[Admin] -->|Console/CLI| C[Email Delivery Control Plane<br/>Approved Senders / Domains / Suppressions]
  C -.governs.-> S

Production-style architecture diagram (recommended patterns)

flowchart TB
  subgraph OCI[Oracle Cloud Tenancy]
    subgraph CompartmentProd[Compartment: prod]
      App1[OKE/Compute Apps] -->|SMTP TLS 587| SMTP[Email Delivery SMTP Endpoint<br/>(Region)]
      Vault[OCI Vault<br/>SMTP Credentials Secret] --> App1
      Mon[OCI Monitoring + Alarms] <-->|Metrics| SMTP
      Audit[OCI Audit] <-->|Control-plane events| Control[Email Delivery Resources<br/>Approved Senders, Email Domains, DKIM, Suppressions]
      IAM[IAM Policies & Groups] --> Control
    end
  end

  SMTP --> MX[External Recipient Mail Systems]
  DNS[DNS Provider (OCI DNS/External)] -->|DKIM records| Control

8. Prerequisites

Before you start the hands-on lab, ensure you have:

Tenancy / account requirements

• An active Oracle Cloud (OCI) tenancy with permission to use Email Delivery in at least one region.
• Access to the OCI Console.

Permissions / IAM roles

You need permissions to: – Manage Email Delivery resources (approved senders, email domains, suppressions) – Create SMTP credentials for a user (typically under IAM user settings)

A common policy pattern (example—adjust to your model and verify in official IAM docs): – Create a group (for example EmailDeliveryAdmins) – Add users who manage Email Delivery to that group – Create a policy in the target compartment such as: – Allow group EmailDeliveryAdmins to manage email-family in compartment <compartment-name>

The exact resource family name and policy verbs should be validated against the official Email Delivery IAM documentation.

Billing requirements

• A billing-enabled tenancy (Email Delivery is usage-priced; free tier may exist—verify in official pricing).

Tools (for the lab)

• A machine to run a test send:
• Your laptop, or
• An OCI Compute instance, or
• Cloud Shell (if outbound SMTP is allowed from your environment)
• One of the following:
• Python 3 (recommended for this tutorial), or
• swaks (SMTP test tool), or
• Any SMTP-capable client library/tool

Region availability

• Email Delivery is regional. Pick a region where it’s available in your tenancy.
• You must use the SMTP endpoint matching your chosen region.

Quotas / limits

• Email Delivery has service limits (for example rate/volume). Start small.
• If you plan production volume, review and request limit increases early (via OCI service limits process).

Prerequisite services (optional but recommended)

• OCI Vault for storing SMTP credentials (recommended for production).
• DNS access (OCI DNS or external) if you want DKIM domain setup.

9. Pricing / Cost

Oracle Cloud Email Delivery pricing is usage-based. Exact prices can vary by region and may change; always confirm using official Oracle sources.

Pricing dimensions (what you typically pay for)

Common pricing dimensions for managed email delivery services include: – Number of emails sent (often billed per 1,000 emails or similar unit) – Potential add-ons or premium deliverability options (if offered; verify in OCI pricing) – Related services you use alongside Email Delivery (Vault, Monitoring, data egress, Compute/Functions)

For Oracle Cloud Email Delivery specifically: – Refer to the official Oracle Cloud pricing page and Email Delivery line item(s) to confirm: – Unit of measure (emails, per 1K emails, etc.) – Whether there is a free monthly allowance (free tier) and its size – Any regional variance

Official references: – Oracle Cloud Pricing page (navigate to Email Delivery): https://www.oracle.com/cloud/price-list/ – Oracle Cloud Cost Estimator / Calculator: https://www.oracle.com/cloud/costestimator.html (or the current Oracle cost estimator page)

Free tier (if applicable)

Oracle Cloud often provides free usage for certain services. If Email Delivery includes a free allowance, it will be listed on the official pricing/free tier pages. Verify in official docs because free tier amounts and eligibility can change.

Cost drivers (what makes costs grow)

• Higher transaction volume (more emails sent)
• High-volume environments (prod + staging + dev sending)
• Poor deliverability leading to repeated sends and retries in your application logic
• Operational tooling sending noisy alerts

Hidden or indirect costs

• Compute/Functions cost for the workloads that generate the emails.
• Vault cost (if used) for secret storage operations.
• Monitoring/Logging cost if you export metrics/logs heavily.
• Data egress cost is usually about data leaving OCI; SMTP submission goes to OCI endpoints, but your app still needs internet egress connectivity. Cost implications depend on your network design and where the app runs.

Network/data transfer implications

• If your app runs outside OCI (on-prem or another cloud), you will incur that environment’s outbound internet traffic costs to reach OCI SMTP endpoints.
• If your app runs inside OCI private subnets, you may need NAT Gateway for outbound internet access; NAT Gateway itself has costs.

How to optimize cost (practical tactics)

• Keep non-production environments on a strict allow-list of recipient domains (for example only internal addresses).
• Rate-limit and deduplicate application notifications.
• Use suppression list governance to avoid repeated sends to invalid addresses.
• Avoid attaching large files; prefer secure download links to Object Storage (with proper authorization).

Example low-cost starter estimate (no fabricated numbers)

A realistic starter approach: – Use Email Delivery for a small set of transactional emails (password resets, verification). – Keep total monthly volume within any available free allowance (if offered). – If you exceed free allowance, estimate cost by: 1. Calculate monthly emails sent (for example, signups + resets + notifications). 2. Multiply by the per-email or per-1,000-email rate shown on the official pricing page.

Example production cost considerations

For production planning: – Build a cost model by environment: dev/test/prod. – Estimate peak day/month volumes. – Include additional spend for: – NAT Gateway (if required) – Vault (secrets) – Observability tooling – Consider deliverability engineering as a “cost” (time/effort): DKIM setup, suppression workflows, monitoring, and incident response.

10. Step-by-Step Hands-On Tutorial

Objective

Configure Oracle Cloud Email Delivery with an Approved Sender, create SMTP credentials, and send a real test email via SMTP over TLS from a local machine (or any host you control).

Lab Overview

You will: 1. Choose a region and compartment for Email Delivery resources. 2. Create and verify an Approved Sender (email address). 3. Create SMTP credentials for an OCI user. 4. Send a test email using Python (smtplib) via the regional SMTP endpoint. 5. Validate delivery and review basic operational checks. 6. Clean up resources.

Assumptions: You can receive the sender verification email and a test recipient email. If your organization restricts external SMTP, use a network that allows outbound TCP 587.

---

Step 1: Prepare your OCI compartment and access

1. Log in to the Oracle Cloud Console.
2. Select the region you will use (top-right region selector).
3. (Recommended) Create a compartment for this lab: – Go to Identity & Security → Compartments – Create a compartment, for example: email-delivery-lab

Expected outcome: You have a known compartment and region for Email Delivery resources.

Verification: – You can see your compartment in the compartment list. – You can switch to your chosen region.

---

Step 2: Create (or identify) a user and group for Email Delivery administration

If you already have a user with admin rights, you can use it for the lab. For least-privilege practice:

1. Go to Identity & Security → Groups
2. Create a group, for example: EmailDeliveryAdmins
3. Add your user to this group.

Then add an IAM policy in the compartment:

1. Go to Identity & Security → Policies
2. Create a policy in compartment email-delivery-lab
3. Add a statement similar to (verify exact resource family in official docs): – Allow group EmailDeliveryAdmins to manage email-family in compartment email-delivery-lab

Expected outcome: Your user can manage Email Delivery resources in the lab compartment.

Verification: – You can open Email Delivery pages without authorization errors. – You can create an approved sender in the next step.

---

Step 3: Create and verify an Approved Sender

1. Navigate to Developer Services (or the menu area where Email Delivery appears in your console) and open Email Delivery.
2. Select your lab compartment.
3. Go to Approved Senders.
4. Click Create Approved Sender.
5. Enter an email address you control, for example: yourname@yourdomain.com.
6. Create it.

Oracle Cloud will send a verification email to that address. Open the email and complete the verification step.

Expected outcome: The sender is verified and appears as “approved/verified” in the console.

Verification: – In Approved Senders, the status shows as verified/active (exact wording may vary). – You can use this address as the “From” address.

Common issue: Verification email not received. – Check spam/junk folders. – Ensure your email gateway doesn’t block automated verification messages. – Re-send verification if the console provides that option.

---

Step 4: Create SMTP credentials for your OCI user

SMTP credentials are used for SMTP authentication. In OCI:

1. Go to Identity & Security → Users
2. Select the user that will send emails (for the lab, your current user is fine).
3. Find SMTP Credentials.
4. Click Generate SMTP Credentials.
5. Provide a description, for example: email-delivery-lab-smtp.
6. Copy and store: – SMTP username – SMTP password

Store them securely. For the lab you can store locally in environment variables; for production use OCI Vault.

Expected outcome: You have SMTP credentials to authenticate to the Email Delivery SMTP endpoint.

Verification: – SMTP credentials appear in the user’s SMTP credentials list. – You have copied the password (it is typically shown only once).

---

Step 5: Identify the correct SMTP endpoint for your region

Email Delivery uses a regional SMTP endpoint. In many OCI regions, the SMTP host is formatted similarly to:

• smtp.email.<region-identifier>.oci.oraclecloud.com

Example (format only—verify for your region in official docs/console): – smtp.email.us-ashburn-1.oci.oraclecloud.com

Also confirm the port and TLS mode. Common patterns are: – Port 587 with STARTTLS (commonly recommended) – Port 465 with implicit TLS (if supported) – Port 25 may be blocked by networks/ISPs and is often not ideal for client submission

Expected outcome: You know the SMTP host and port to use.

Verification: – The SMTP endpoint is shown in Email Delivery documentation or console for your region.

---

Step 6: Send a test email using Python (SMTP + STARTTLS)

On your local machine (or a compute instance), create environment variables:

export OCI_SMTP_HOST="smtp.email.<your-region>.oci.oraclecloud.com"
export OCI_SMTP_PORT="587"
export OCI_SMTP_USER="your-smtp-username"
export OCI_SMTP_PASS="your-smtp-password"
export MAIL_FROM="your-verified-approved-sender@yourdomain.com"
export MAIL_TO="recipient@example.com"

Now create a Python script send_test_email.py:

import os
import smtplib
from email.message import EmailMessage

smtp_host = os.environ["OCI_SMTP_HOST"]
smtp_port = int(os.environ.get("OCI_SMTP_PORT", "587"))
smtp_user = os.environ["OCI_SMTP_USER"]
smtp_pass = os.environ["OCI_SMTP_PASS"]
mail_from = os.environ["MAIL_FROM"]
mail_to = os.environ["MAIL_TO"]

msg = EmailMessage()
msg["Subject"] = "OCI Email Delivery test"
msg["From"] = mail_from
msg["To"] = mail_to
msg.set_content(
    "Hello!\n\nThis is a test email sent using Oracle Cloud Email Delivery via SMTP.\n"
)

with smtplib.SMTP(smtp_host, smtp_port, timeout=30) as server:
    server.ehlo()
    server.starttls()
    server.ehlo()
    server.login(smtp_user, smtp_pass)
    server.send_message(msg)

print("Sent.")

Run it:

python3 send_test_email.py

Expected outcome: – The script prints Sent. – The recipient receives the email.

Verification steps: – Confirm the message arrives in the recipient inbox (or spam folder). – If it lands in spam, proceed to domain/DKIM best practices later.

---

Step 7 (Optional but recommended for production): Configure Email Domain and DKIM

If you control DNS for yourdomain.com, set up DKIM:

1. In Email Delivery → Email Domains, create an email domain for yourdomain.com.
2. Generate DKIM key(s) as guided by the console.
3. Publish DKIM DNS records at your DNS provider.
4. Wait for DNS propagation and confirm verification in the console.

Expected outcome: DKIM is configured and active for your domain.

Verification: – Console shows DKIM as verified/active. – You can send a new test email and inspect headers in the recipient mailbox to confirm DKIM results (look for dkim=pass in Authentication-Results).

SPF and DMARC: Email deliverability typically also benefits from SPF and DMARC. Whether OCI requires or recommends specific records should be verified in the official Email Delivery docs.

---

Validation

Use this checklist:

• Sender verified: Approved Sender status is verified.
• SMTP auth works: Python script sends successfully without authentication errors.
• Recipient receives email: Inbox or spam (either confirms delivery path).
• Headers (optional): Confirm DKIM pass once configured.

If you have DKIM set, open the email source and look for: – Authentication-Results: ... dkim=pass ... (format varies by receiver)

---

Troubleshooting

Common errors and fixes:

1. SMTPAuthenticationError / login failed – Ensure you used the SMTP credentials (not your console password). – Regenerate SMTP credentials and update environment variables. – Confirm your user is allowed to send and that the “From” address is an approved sender.

2. Connection timeout – Your network may block outbound SMTP ports. – Try from a different network or from an OCI Compute instance with internet egress. – Confirm security rules/route tables/NAT gateway if sending from a private subnet.

3. From address rejected – The From address must match a verified Approved Sender (and/or your configured domain rules). – Re-check that you used exactly the verified email address (no display-name-only mismatch).

4. Email arrives in spam – Configure DKIM on an Email Domain and ensure it verifies. – Add SPF/DMARC where appropriate (verify recommended records in official docs). – Avoid spam-like content (URL shorteners, heavy promotional wording).

5. Recipient never receives email – Check suppression list for the recipient address. – Confirm the recipient domain isn’t blocking the message. – Validate that your content isn’t being rejected downstream.

---

Cleanup

To avoid accidental future sends and to keep your tenancy tidy:

1. Delete SMTP credentials – Identity & Security → Users → your user → SMTP Credentials → delete the lab credential

2. Remove Approved Sender – Email Delivery → Approved Senders → delete sender

3. Remove Email Domain / DKIM (if created) – Email Delivery → Email Domains → delete domain resources – Optionally remove DKIM DNS records you created (only if they were lab-only)

4. Remove IAM policy/group (if lab-only) – Delete the policy granting Email Delivery management in the lab compartment – Remove group or user membership if created only for this lab

5. Delete compartment (optional) – Only if it contains no other resources.

11. Best Practices

Architecture best practices

• Treat email as an external dependency: implement retries with backoff, but avoid infinite retry loops.
• Centralize your email-sending module: build a shared library/service so you can:
• enforce From addresses
• standardize headers
• apply rate limits
• manage templates consistently
• Separate environments: use separate compartments and distinct senders/domains for dev/test/prod.

IAM/security best practices

• Least privilege: only allow a small admin group to manage domains, DKIM, and suppression rules.
• Separate duties: developers can use SMTP credentials to send; security/platform team manages identity (domains/senders).
• Rotate SMTP credentials: periodic rotation and immediate rotation after suspected compromise.

Cost best practices

• Alert fatigue control: avoid sending noisy operational emails that inflate volume.
• Deduplicate events: don’t email on every retry; aggregate and summarize.
• Use links not attachments: host content in Object Storage with appropriate access controls instead of emailing large files.

Performance best practices

• Batch where appropriate: for report-style emails, batch and send once rather than many individual messages.
• Use connection reuse: for high-volume sending within a service instance, reuse SMTP connections when feasible (while respecting library safety and service limits).

Reliability best practices

• Implement dead-letter handling: if sending fails, queue for later processing or manual review.
• Respect suppression: if an address is suppressed, stop sending and trigger a separate workflow to correct the address.
• Backpressure: protect your application from cascading failures if SMTP becomes temporarily unavailable.

Operations best practices

• Monitoring and alerting: create alarms for anomalies in send/bounce patterns (verify metric availability).
• Audit reviews: periodically review who changed approved senders/domains.
• Document runbooks: include steps for credential rotation, domain verification, and troubleshooting spam placement.

Governance/tagging/naming best practices

• Use consistent tags:
• env=dev|test|prod
• owner=<team>
• cost-center=<id>
• Standardize resource naming:
• prod-email-domain-yourdomain
• dev-approved-sender-noreply

12. Security Considerations

Identity and access model

• Control-plane access is governed by OCI IAM policies and compartments.
• SMTP submission is authenticated using SMTP credentials associated with an OCI user.
• Protect SMTP credentials like any production secret—anyone with them can send email as your approved sender(s).

Encryption

• Use TLS/STARTTLS for SMTP submission to protect credentials and message content in transit between your app and OCI.
• Verify supported cipher suites and TLS versions in official docs if you have strict compliance requirements.

Network exposure

• SMTP endpoint is typically public. Plan egress:
• Private subnet apps use NAT gateway or another egress pattern.
• Restrict outbound traffic from workloads to required destinations where feasible.

Secrets handling

• Store SMTP credentials in OCI Vault (recommended) or an equivalent secret manager.
• Avoid embedding credentials in source code, container images, or CI logs.
• Rotate secrets and remove old credentials quickly.

Audit/logging

• Use OCI Audit to track administrative actions.
• If you need content-level audit trails, implement it in your application (careful with privacy/legal requirements).

Compliance considerations

Email often contains PII or sensitive data: – Minimize sensitive content in emails (prefer secure links to authenticated pages). – Ensure your privacy policies cover email notifications. – For regulated industries, confirm regional data handling and service compliance posture in official Oracle documentation.

Common security mistakes

• Using a shared “admin” user for SMTP credentials across many apps.
• Over-permissive IAM policy allowing many users to create new approved senders/domains.
• Sending sensitive data directly in email bodies.
• Not rotating SMTP credentials after team changes.

Secure deployment recommendations

• Use a dedicated OCI user for application SMTP credentials.
• Restrict that user’s permissions and scope via compartments and IAM.
• Apply DKIM (and SPF/DMARC where applicable) to reduce spoofing and improve trust.
• Monitor for unusual send volume (potential credential compromise indicator).

13. Limitations and Gotchas

The exact limits can change; consult official docs for current details.

Known limitations / service boundaries

• Outbound email only: not an inbound mailbox service.
• Not a marketing automation platform: no built-in campaign management (verify features; don’t assume templates/list management beyond suppressions).
• Public SMTP endpoint: no assumption of private connectivity unless explicitly documented by Oracle.

Quotas and service limits

• Expect limits such as:
• maximum send rate
• maximum emails/day
• maximum recipients per message
• Plan limit increase requests well before production launch.

Regional constraints

• Resources and SMTP endpoints are regional; multi-region designs require:
• duplicating configuration (senders/domains) per region, or
• standardizing on one region for email sending (depending on latency and governance)
• Verify which regions support Email Delivery.

Pricing surprises

• High-volume operational alerts can quietly become expensive.
• NAT gateway egress patterns (if used) can add costs.
• Observability exports may add costs if you stream logs/metrics heavily.

Compatibility issues

• Some networks block SMTP ports (especially 25).
• Some enterprise mail gateways have strict policies; DKIM/SPF/DMARC alignment becomes essential.

Operational gotchas

• If recipients get suppressed due to bounces/complaints, email may silently stop reaching them until the underlying issue is fixed and suppression is managed appropriately.
• Verification emails for approved senders can be delayed by external providers.

Migration challenges

• Legacy apps may assume an open relay or unauthenticated SMTP—Email Delivery requires authenticated submission.
• Sender identity governance may require changes to “From” addresses across applications.

Vendor-specific nuances

• SMTP credentials are tied to OCI users—plan lifecycle management carefully.
• Approved sender verification is a distinct operational step; automate and document it for production readiness.

14. Comparison with Alternatives

Email Delivery is one option among several ways to send email. Here’s how it compares.

Nearest services in Oracle Cloud

• OCI Notifications (email subscriptions): good for simple alerting from OCI events/alarms; not a general transactional email engine for applications.
• Oracle Integration Cloud / other integration tools: can orchestrate workflows; email sending may be a connector feature but may not match SMTP-based app needs.

Nearest services in other clouds

• Amazon SES (AWS): similar transactional email service.
• Azure Communication Services Email (Azure): application email sending.
• Google (partner-based email sending): GCP often relies on partners for email sending; patterns differ.

Open-source / self-managed

• Postfix/Exim + reputation management: maximum control but high ops overhead and deliverability engineering burden.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud Email Delivery	OCI-hosted apps needing transactional outbound email	SMTP simplicity; OCI IAM/compartments; approved sender/domain governance; suppression handling	Regional setup; public SMTP egress; not a full marketing platform	You run workloads on Oracle Cloud and want managed transactional email with OCI governance
OCI Notifications (Email)	Infrastructure alerts, simple subscriptions	Tight OCI integration for alarms/events; minimal setup	Not designed as a general app email engine; limited customization	You need basic alert emails from OCI monitoring/events
Amazon SES	AWS-centric transactional/bulk email	Mature ecosystem; deep integrations	Different IAM model; cross-cloud adds egress/complexity	Your apps run on AWS or you already standardized on SES
Azure Communication Services Email	Azure app email	Azure-native integration	Cross-cloud complexity if on OCI	Your apps are primarily on Azure
Third-party ESP (SendGrid/Mailgun/etc.)	Advanced deliverability tooling, marketing + transactional	Rich analytics, templates, webhooks	Vendor lock-in; separate IAM/governance from OCI; potentially higher cost	You need advanced email features beyond SMTP relay and basic suppression
Self-managed Postfix/Exim	Maximum control; air-gapped/hybrid constraints	Full control; custom routing	Highest ops burden; deliverability/reputation is hard	You have strict constraints or need deep customization and accept ops cost

15. Real-World Example

Enterprise example: regulated SaaS platform sending customer notifications

• Problem: A multi-tenant enterprise SaaS on Oracle Cloud must send verification emails, invoices, and security alerts reliably while maintaining governance, auditability, and environment separation.
• Proposed architecture:
• Separate OCI compartments: prod, staging, dev
• Email Delivery configured per environment:
  • prod uses domain + DKIM
  • staging/dev use limited approved senders and strict recipient allow-lists
• SMTP credentials stored in OCI Vault and injected into workloads via secure deployment pipelines
• Monitoring alarms on bounce/complaint anomalies and send volume spikes
• Why Email Delivery was chosen:
• OCI-native governance (IAM/compartments/Audit)
• Simple SMTP integration across microservices
• Reduced operational burden vs self-managed MTAs
• Expected outcomes:
• Faster release cycles (no mail server maintenance)
• Improved deliverability with DKIM and suppression handling
• Clear audit trail for sending identity changes

Startup/small-team example: MVP app needs password reset and onboarding emails

• Problem: A small team is launching an MVP on OCI and needs basic transactional email without spending weeks on deliverability engineering.
• Proposed architecture:
• One compartment for production
• Start with a single verified approved sender (for example noreply@...)
• Use SMTP credentials stored as a secret (Vault or minimal secret store)
• Use a single Python/Node email module used by the app
• Why Email Delivery was chosen:
• Minimal setup and standard SMTP
• Keeps everything inside Oracle Cloud for simpler operations
• Expected outcomes:
• Working transactional emails quickly
• A clear path to improve deliverability later (domain + DKIM)

16. FAQ

1. Is Email Delivery for inbound email (receiving messages)?
   No. Email Delivery is designed for outbound email sending. For inbound processing, you need a different approach (mail server, third-party inbound service, etc.).

2. Do I have to use SMTP, or is there an API to send messages?
   The common, documented submission method is SMTP. Management is via console/CLI/SDK. Verify in official docs if Oracle introduces a send API.

3. What is an Approved Sender?
   An Approved Sender is a verified email address that your applications are allowed to send from.

4. Do I need my own domain to start?
   You can often start with an approved sender address you control. For production deliverability and branding, domain + DKIM is strongly recommended.

5. What is DKIM and why should I enable it?
   DKIM signs outgoing mail so recipient systems can verify it wasn’t modified and is authorized by your domain. This improves deliverability and trust.

6. Should I set up SPF and DMARC too?
   Usually yes for production-grade sending. Exact recommendations depend on how OCI Email Delivery interacts with your domain; verify Oracle’s official guidance.

7. Why are some recipients not receiving emails even though sends “succeed”?
   They may be suppressed due to bounces/complaints, or the receiving provider may be filtering the email. Check suppression lists and authentication (DKIM/SPF/DMARC).

8. How do suppression lists work?
   Email Delivery maintains addresses that should not be emailed (for example due to bounce/complaint). You can also manage suppressions manually.

9. Can I use Email Delivery for marketing campaigns?
   It is primarily positioned for transactional email. Marketing at scale often requires additional capabilities (unsubscribe management, campaign tooling). Use a marketing platform if that’s your need.

10. How do I store SMTP credentials securely?
    Use OCI Vault (recommended) and inject credentials at runtime using secure configuration.

11. What ports should I use for SMTP?
    Commonly port 587 with STARTTLS. Port availability can vary; verify supported ports in the official docs and ensure your network allows outbound access.

12. Can I send from private subnets in OCI?
    Yes, if you provide outbound internet egress (often via NAT gateway). The SMTP endpoint is public unless Oracle documents a private option.

13. How do I separate dev/test/prod to prevent accidental emails?
    Use separate compartments, separate senders/domains, and enforce recipient allow-lists in non-prod code.

14. How can I monitor Email Delivery health?
    Use OCI Monitoring metrics and alarms (verify which metrics are available), and implement application-level logging for SMTP responses.

15. What should I do if I suspect SMTP credentials were leaked?
    Immediately delete/rotate the SMTP credentials, audit recent changes and sending activity, and add preventive monitoring/alerting on send spikes.

16. Does Email Delivery guarantee inbox placement?
    No provider can guarantee inbox placement. Deliverability depends on authentication (DKIM/SPF/DMARC), content, sending patterns, and recipient filtering.

17. Can multiple apps share the same SMTP credentials?
    They can, but it’s not ideal. Prefer per-application credentials for traceability and blast-radius reduction.

17. Top Online Resources to Learn Email Delivery

Resource Type	Name	Why It Is Useful
Official documentation	OCI Email Delivery Documentation (Overview) — https://docs.oracle.com/en-us/iaas/Content/Email/Concepts/overview.htm	Primary source for service concepts, setup steps, endpoints, and limits
Official documentation	Email Delivery: Approved Senders / Email Domains / Suppressions (navigate within docs) — https://docs.oracle.com/en-us/iaas/Content/Email/home.htm	Deep dives into sender verification, DKIM, and suppression management
Official pricing	Oracle Cloud Price List — https://www.oracle.com/cloud/price-list/	Authoritative pricing units and regional cost references
Cost estimation	Oracle Cloud Cost Estimator — https://www.oracle.com/cloud/costestimator.html	Helps model monthly spend across services
Official IAM docs	OCI IAM Policies — https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/policies.htm	Correct policy syntax and least-privilege guidance
Official CLI docs	OCI CLI Documentation — https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm	How to install and use CLI for automation
Architecture guidance	OCI Architecture Center — https://docs.oracle.com/solutions/	Reference architectures and cloud design patterns (useful for production designs around Email Delivery)
Official videos	Oracle Cloud Infrastructure YouTube — https://www.youtube.com/c/OracleCloudInfrastructure	Product explainers and operational guidance (search within for Email Delivery topics)
SDK docs	OCI SDK Documentation — https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/sdks.htm	Automate resource management and integrate with provisioning workflows
Community learning	Oracle Cloud blogs (search: “OCI Email Delivery”) — https://blogs.oracle.com/cloud-infrastructure/	Practical posts and updates; validate against official docs for currency

18. Training and Certification Providers

1. DevOpsSchool.com – Suitable audience: DevOps engineers, SREs, cloud engineers, developers – Likely learning focus: DevOps, cloud operations, CI/CD, cloud services usage patterns (including messaging/email patterns) – Mode: Check website – Website: https://www.devopsschool.com/

2. ScmGalaxy.com – Suitable audience: DevOps practitioners, build/release engineers, platform teams – Likely learning focus: SCM, CI/CD, DevOps toolchains, automation fundamentals – Mode: Check website – Website: https://www.scmgalaxy.com/

3. CLoudOpsNow.in – Suitable audience: Cloud operations teams, SREs, cloud engineers – Likely learning focus: Cloud ops practices, monitoring, reliability, operational readiness – Mode: Check website – Website: https://www.cloudopsnow.in/

4. SreSchool.com – Suitable audience: SREs, operations engineers, platform engineers – Likely learning focus: Reliability engineering, incident response, observability, runbooks – Mode: Check website – Website: https://www.sreschool.com/

5. AiOpsSchool.com – Suitable audience: SRE/ops teams, DevOps engineers, IT operations – Likely learning focus: AIOps concepts, automation, event correlation, monitoring strategy – Mode: Check website – Website: https://www.aiopsschool.com/

19. Top Trainers

1. RajeshKumar.xyz – Likely specialization: DevOps/cloud training and coaching (verify current offerings on site) – Suitable audience: Beginners to intermediate engineers seeking guided learning – Website: https://www.rajeshkumar.xyz/

2. devopstrainer.in – Likely specialization: DevOps tools, CI/CD, cloud operations training resources – Suitable audience: DevOps engineers and students – Website: https://www.devopstrainer.in/

3. devopsfreelancer.com – Likely specialization: DevOps consulting/training resources and practitioner services (verify specifics on site) – Suitable audience: Teams seeking practical DevOps enablement – Website: https://www.devopsfreelancer.com/

4. devopssupport.in – Likely specialization: DevOps support and enablement resources (verify current scope on site) – Suitable audience: Engineers needing operational help and training-style support – Website: https://www.devopssupport.in/

20. Top Consulting Companies

1. cotocus.com – Likely service area: Cloud and DevOps consulting (verify offerings on website) – Where they may help: Architecture design, cloud migrations, operational readiness – Consulting use case examples: Designing compartment/IAM strategy for Email Delivery administration; setting up secure secret handling; building monitoring/alerting runbooks – Website: https://cotocus.com/

2. DevOpsSchool.com – Likely service area: DevOps and cloud consulting/training services (verify service catalog) – Where they may help: CI/CD modernization, DevOps platform engineering, cloud adoption – Consulting use case examples: Integrating Email Delivery into CI/CD notification workflows; implementing secure SMTP credential rotation; operational dashboards for email sending – Website: https://www.devopsschool.com/

3. DEVOPSCONSULTING.IN – Likely service area: DevOps consulting and implementation services (verify current offerings) – Where they may help: Toolchain automation, cloud governance, reliability practices – Consulting use case examples: Building environment separation (dev/test/prod) around Email Delivery; policy reviews; incident response playbooks for deliverability issues – Website: https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

To use Email Delivery well in Oracle Cloud (Application Development context), you should know: – Email basics: SMTP, MIME, headers, TLS/STARTTLS – Identity fundamentals: DKIM, SPF, DMARC concepts – OCI basics: – Compartments – IAM users/groups/policies – Regions and endpoints – Secure secret management (Vault or equivalent)

What to learn after this service

To operate Email Delivery in production: – Deliverability engineering (reputation, bounce/complaint handling) – Observability: metrics, alarms, incident response – Secure application configuration patterns (Vault integration, rotation) – Infrastructure as Code patterns for repeatable provisioning (Terraform/CLI—verify official modules)

Job roles that use it

• Cloud Engineers (OCI)
• DevOps Engineers
• SRE / Platform Engineers
• Backend Developers
• Security Engineers (governance, auditing, least-privilege)

Certification path (if available)

Oracle Cloud certifications evolve. Look for OCI architect/developer/operations certifications that cover: – IAM – networking – governance – application integration patterns
Check Oracle University / OCI certification tracks for the most current mapping.

Project ideas for practice

• Build a small service that sends:
• welcome emails
• password reset emails
• weekly summary reports
• Implement a “safe mailer” library:
• environment-based recipient allow-lists
• rate limiting
• structured logging of SMTP responses
• Create an operations dashboard:
• daily send counts
• bounce rate alerts (if metrics available)
• anomaly detection on send volume

22. Glossary

• Approved Sender: A verified email address authorized to send outbound messages through Email Delivery.
• DKIM (DomainKeys Identified Mail): A method of signing outgoing email so recipients can verify authenticity and integrity.
• SPF (Sender Policy Framework): DNS-based mechanism to declare which servers are allowed to send mail for a domain.
• DMARC: A policy layer built on SPF/DKIM that instructs recipients how to handle authentication failures and provides reporting.
• SMTP: Simple Mail Transfer Protocol; standard protocol for sending email.
• STARTTLS: An SMTP command to upgrade an existing plaintext connection to TLS encryption.
• Suppression List: A list of recipients that should not receive email due to bounces, complaints, or manual suppression.
• Compartment (OCI): A logical container used to organize and isolate OCI resources for governance and access control.
• IAM Policy (OCI): A statement defining permissions for groups over resources in compartments.
• SMTP Credentials (OCI): Username/password pair created for an OCI user to authenticate to Email Delivery’s SMTP endpoint.
• Deliverability: The likelihood that email reaches recipients’ inboxes rather than spam/junk or being rejected.
• Bounce: A delivery failure report indicating the message could not be delivered.
• Complaint: A signal that a recipient marked the message as spam (handling depends on provider and service behavior; verify OCI’s exact complaint processing).

23. Summary

Oracle Cloud Email Delivery is a managed outbound email service designed for Application Development teams that need to send transactional emails reliably using SMTP, with governance features like approved senders, optional domain + DKIM authentication, and suppression list handling.

It matters because building and operating your own mail servers is operationally heavy and deliverability is difficult. Email Delivery helps standardize and control sending identity, integrates with Oracle Cloud IAM/compartments, and supports operational visibility through audit and monitoring (verify exact telemetry capabilities in your region).

Cost is primarily driven by email volume and surrounding architecture choices (NAT egress, Vault usage, and observability). Security hinges on protecting SMTP credentials, using TLS, applying least-privilege IAM, and enabling DKIM for production.

Use Email Delivery when your Oracle Cloud applications need transactional email with strong governance. Next, deepen your production readiness by implementing DKIM/SPF/DMARC practices, adding monitoring/alerts, and managing SMTP credentials through OCI Vault with rotation.