Email & Google WorkspaceAdvanced

What Are SendGrid, Mailgun, Amazon SES, and Resend? Complete Guide to Transactional Email, SMTP Relay, Email APIs, Deliverability, and Choosing the Right Email Service

When a website, mobile application, desktop application, ERP, CRM, e-commerce store, SaaS platform, or business application needs to automatically send an em...

Bison Technical Team Enterprise IT specialists

Updated 28 Aug 2026 18 min read 3 total views

When a website, mobile application, desktop application, ERP, CRM, e-commerce store, SaaS platform, or business application needs to automatically send an email, it normally should not behave like a person opening Gmail or Outlook and clicking Send.

Instead, applications commonly use a specialized transactional email service.

Four well-known services in this category are:

Twilio SendGrid
Mailgun
Amazon Simple Email Service (Amazon SES)
Resend

These platforms provide infrastructure through which applications can send email using an API, SMTP relay, or both.

For example, an application may need to automatically send:

Password-reset emails
OTP or verification messages
Account activation emails
Welcome emails
Order confirmations
Payment receipts
Invoices
Support notifications
Security alerts
Login alerts
Subscription confirmations
License activation emails
Software notifications
Backup alerts
Server monitoring alerts
Appointment confirmations
Delivery notifications

Instead of maintaining your own internet-facing mail server, your application submits the email to a transactional email provider, and that provider handles much of the underlying email-delivery infrastructure.

What Is Transactional Email?

A transactional email is generally an email automatically triggered by an action, transaction, or event involving a user or system.

For example:

User action:

Customer clicks:

Forgot Password

Your application generates a password-reset link.

It then instructs an email service to send:

Reset your password

Another example:

Customer places an order → Application generates order → Transactional email provider sends order confirmation.

Transactional email therefore differs from ordinary person-to-person email.

Normal business email

Examples:

Employee sends quotation
Customer sends inquiry
Accountant sends documents
Manager replies to customer

These are normally handled through services such as Google Workspace or Microsoft 365.

Transactional/application email

Examples:

Password reset
OTP
Account verification
Order confirmation
Automatic invoice
Security notification
Server alert

These are generated automatically by software.

How Transactional Email Services Work

A simplified architecture looks like this:

Website/Application

↓

Email API or SMTP

↓

SendGrid / Mailgun / Amazon SES / Resend

↓

Internet mail infrastructure

↓

Gmail / Outlook / Yahoo / Corporate mail server

↓

Recipient's Inbox

Your software does not have to directly establish and maintain the complete email-delivery infrastructure.

SMTP vs Email API

Before comparing the four services, it is important to understand the two common methods applications use to communicate with them.

Method 1: SMTP

SMTP stands for:

Simple Mail Transfer Protocol

Your application receives credentials similar to:

SMTP Server
SMTP Port
Username
Password
Encryption Method

The application connects to the provider's SMTP server and submits the message.

Conceptually:

Application
      ↓
SMTP connection
      ↓
Transactional email provider
      ↓
Recipient mail server

SMTP is particularly useful when an existing application already supports configurable SMTP.

Examples include:

WordPress
ERP applications
CRM software
Helpdesk software
Monitoring applications
PHP applications
Accounting software
NAS devices
Website contact forms
Server applications

Method 2: Email API

Modern applications can instead communicate with the provider through an HTTP/REST API.

Conceptually:

Application
      ↓
HTTPS API Request
      ↓
Email Provider API
      ↓
Email Delivery Infrastructure
      ↓
Recipient

The application may send information such as:

{
  "from": "support@example.com",
  "to": "customer@example.net",
  "subject": "Your account has been activated",
  "html": "<h1>Welcome</h1>"
}

The provider accepts the request and processes the email.

APIs can provide tighter integration with features such as templates, scheduling, message metadata, webhooks and event processing.

1. What Is Twilio SendGrid?

Twilio SendGrid is a cloud-based email delivery platform designed for application-generated and marketing email.

Its Web API provides a REST interface that applications can use to send email at scale. SendGrid also provides an SMTP relay, allowing applications that already understand SMTP to send through SendGrid without requiring a complete API integration.

SendGrid therefore supports two important integration methods:

Application → SendGrid Web API → Recipient

or:

Application → SendGrid SMTP Relay → Recipient

SendGrid SMTP

A typical SendGrid SMTP configuration uses:

SMTP Host: smtp.sendgrid.net
Recommended TLS Port: 587
Username: apikey
Password: Your SendGrid API key

SendGrid also supports ports 25 and 2525 for unencrypted/TLS connections and 465 for SSL connections. Its documentation generally recommends TLS on port 587 when you are unsure which SMTP port to use.

SendGrid Web API

SendGrid's v3 Web API allows applications to communicate with SendGrid using HTTP.

It supports capabilities including:

Transactional email
Dynamic templates
Attachments
Personalization
Scheduled sending
Webhooks
Delivery statistics
Contact management
Marketing campaigns

SendGrid itself notes that its Web API offers a richer feature set for many application use cases, while SMTP remains particularly useful for connecting existing SMTP-compatible applications.

Where SendGrid Is Commonly Used

SendGrid can be suitable for:

SaaS applications
E-commerce stores
Membership websites
CRM systems
Password-reset systems
Notification systems
Large web applications
Marketing and transactional email environments

Twilio SendGrid official documentation

2. What Is Mailgun?

Mailgun is an email infrastructure platform designed heavily around developers and application integration.

It provides APIs and tools for sending, receiving and tracking email at scale. Its platform supports transactional email, bulk sending, SMTP integration and additional email-processing functionality.

A typical architecture is:

Website/Application
        ↓
Mailgun API
        ↓
Mailgun infrastructure
        ↓
Recipient

or:

Existing Application
        ↓
SMTP
        ↓
Mailgun
        ↓
Recipient

Mailgun API

Mailgun provides a RESTful API that developers can use to send messages.

Applications can provide elements such as:

From address
Recipient
Subject
Plain-text content
HTML content
Templates
Attachments

Mailgun then constructs and processes the message.

Mailgun SMTP

Mailgun also provides SMTP credentials for sending domains.

Its documentation recommends port 587 for SMTP submission in normal configurations.

Mailgun Features

Depending on the product and plan being used, Mailgun's platform includes capabilities around:

Email API
SMTP
Transactional email
Bulk email
Email tracking
Templates
Email logs
Email validation
Analytics
Inbound email routing/parsing
Deliverability tools

One particularly useful feature for developers is inbound email processing.

An application can receive email through Mailgun and programmatically process incoming messages using inbound routes.

This can be useful for applications such as:

support@example.com
        ↓
Mailgun
        ↓
Application
        ↓
Automatically create support ticket

Mailgun official website

3. What Is Amazon SES?

Amazon SES stands for:

Amazon Simple Email Service

It is part of Amazon Web Services (AWS).

AWS describes SES as a scalable and cost-effective email service that developers and digital marketers can use for transactional, notification and marketing email.

Amazon SES is especially attractive when an organization already uses AWS infrastructure.

Examples:

EC2
Lambda
Application Server
Website
SaaS Platform
        ↓
Amazon SES
        ↓
Customer

Ways to Send Email Through Amazon SES

Amazon SES supports several sending methods, including:

AWS Management Console for testing/management
SMTP interface
SES API
AWS SDK
AWS CLI

For production applications, SMTP or API-based integration is normally used.

Amazon SES SMTP

An application that already supports SMTP can connect to the SES SMTP interface.

Conceptually:

Application
      ↓
SES SMTP Endpoint
      ↓
Amazon SES
      ↓
Recipient

SMTP credentials must be generated/configured for SES.

Amazon SES API

Applications built directly on AWS can communicate with SES programmatically through its API or AWS SDKs.

For example:

Application
      ↓
AWS SDK
      ↓
Amazon SES API
      ↓
Recipient

Amazon SES API v2 is available across multiple AWS Regions, with regional endpoints.

Amazon SES Sandbox

An important concept for new SES users is the SES sandbox.

SES sandbox status and sending limits are region-specific. Production deployments normally need the appropriate SES production access and sending configuration for the AWS Region being used.

Amazon SES Deliverability Tools

Amazon SES also provides deliverability capabilities including Virtual Deliverability Manager (VDM), which provides insights and recommendations concerning email deliverability.

Where Amazon SES Makes Sense

SES is often considered for:

AWS-hosted applications
SaaS products
Large notification systems
High-volume transactional email
E-commerce platforms
Serverless applications
Enterprise applications

Amazon SES official website

4. What Is Resend?

Resend is a developer-focused email platform designed to simplify application email.

It supports both a REST API and SMTP and provides SDKs/integrations for numerous development stacks.

Its positioning emphasizes straightforward developer integration.

A typical implementation looks like:

Application
      ↓
Resend API
      ↓
Resend
      ↓
Recipient

Resend API

Resend provides an HTTP API and SDKs for multiple development environments.

Its API supports functionality such as:

Transactional emails
Attachments
Scheduled emails
Batch email
Idempotency keys
Email events
API logs
Webhooks

Idempotency keys are particularly useful when an application retries an operation, because they can help prevent the same email request from being processed more than once.

Resend SMTP

Resend also provides an SMTP service.

A typical SMTP configuration is:

SMTP Host: smtp.resend.com
Username: resend
Password: API key

For SMTPS, Resend documents ports 465 and 2465. STARTTLS can use 25, 587 and 2587.

This means an application does not necessarily need a Resend-specific SDK.

If it understands SMTP, it can potentially use Resend as its SMTP delivery provider.

Resend Developer Support

Resend provides integrations/SDK options across technologies including:

Node.js
Python
PHP
Ruby
Go
Java
.NET
Rust
Elixir
REST
SMTP

It also documents integrations with frameworks and platforms such as Laravel, WordPress, Django and others.

Resend official website

SendGrid vs Mailgun vs Amazon SES vs Resend

The following conceptual comparison helps explain where each platform fits.

Feature	SendGrid	Mailgun	Amazon SES	Resend
Transactional email	Yes	Yes	Yes	Yes
Email API	Yes	Yes	Yes	Yes
SMTP	Yes	Yes	Yes	Yes
Developer focused	Yes	Yes	Yes	Strongly
Marketing capabilities	Yes	Available	Supported use case	Available
AWS ecosystem integration	No special requirement	No special requirement	Excellent	No special requirement
Inbound email capabilities	Yes	Strong	Available	Available
Templates	Yes	Yes	Yes/implementation dependent	Yes
Webhooks/events	Yes	Yes	AWS event ecosystem	Yes
Best-known strength	Mature email platform	Developer/email infrastructure	AWS scale & infrastructure	Developer experience

This table should not be interpreted as a permanent pricing or feature matrix. Providers frequently modify plans, quotas, feature packaging and pricing.

Which Service Should You Choose?

There is no universal winner.

The best choice depends on your application architecture.

Consider SendGrid When

You want a mature email platform combining transactional email infrastructure with extensive email-management functionality.

It is particularly useful when you need both developer integration and broader email capabilities.

Consider Mailgun When

Your application has sophisticated email-processing requirements.

Mailgun can be attractive for developers needing:

Sending
Receiving
Parsing
Routing
Validation
Detailed email processing

Consider Amazon SES When

Your infrastructure already runs heavily on AWS or you expect substantial email volume and are comfortable managing AWS configuration.

A typical AWS architecture might be:

Application
   ↓
AWS Lambda / EC2
   ↓
Amazon SES
   ↓
Customer

Consider Resend When

You want a modern, developer-oriented integration experience and a relatively straightforward API.

It can be particularly attractive for newly developed web applications and SaaS products.

Do These Services Replace Gmail or Microsoft 365?

Usually, no.

This distinction is extremely important.

Google Workspace and Microsoft 365 are primarily business productivity and mailbox platforms.

They provide services such as:

Mailbox
Inbox
Sent Items
Calendar
Contacts
IMAP/POP
Webmail
Desktop/mobile email

Transactional email platforms primarily provide application email delivery infrastructure.

For example:

employee@company.com

may have a Google Workspace mailbox.

But:

no-reply@company.com

might be used by a website/application through SendGrid, Mailgun, SES or Resend.

Therefore an organization can use both systems simultaneously.

Why Not Simply Use Gmail SMTP?

A small application can sometimes send email using an existing mailbox SMTP service.

However, as the application grows, specialized transactional infrastructure provides advantages such as:

Better separation of application email
Higher-scale sending infrastructure
Detailed logs
Bounce management
Complaint processing
Webhooks
API integration
Suppression management
Deliverability monitoring
Dedicated IP options
Application-specific credentials

A business mailbox and a transactional delivery service solve related but different problems.

Why SPF, DKIM and DMARC Matter

Using a professional email API does not eliminate the importance of domain authentication.

Three major technologies are involved.

SPF

Sender Policy Framework

SPF allows a domain owner to specify systems authorized to send email for the domain.

DKIM

DomainKeys Identified Mail

DKIM cryptographically signs email so receiving servers can verify that the message is associated with the authorized sending domain and was not improperly altered in transit.

DMARC

Domain-based Message Authentication, Reporting and Conformance

DMARC builds on SPF and DKIM and gives domain owners policies and reporting mechanisms for handling authentication.

A typical production deployment therefore involves:

Domain
   ↓
DNS
   ├── SPF
   ├── DKIM
   └── DMARC

Application
   ↓
Email Provider
   ↓
Recipient Mail Server
   ↓
Authentication Checks
   ↓
Inbox / Spam / Reject

Correct DNS configuration is a major component of reliable application email.

What Is Sender Reputation?

Email providers continuously evaluate the reputation of senders.

Factors may include:

Bounce rate
Spam complaints
Authentication
Sending history
Message content
Recipient engagement
Sending patterns
IP reputation
Domain reputation

Using SendGrid, Mailgun, SES or Resend does not automatically guarantee inbox delivery.

The sender must still follow good email practices.

Shared IP vs Dedicated IP

Transactional email platforms may send through shared or dedicated IP infrastructure depending on provider and plan.

Shared IP

Multiple customers send through infrastructure using a shared IP pool.

Advantages can include:

Easier initial setup
Lower cost
Suitable for smaller senders

Dedicated IP

An IP address is allocated specifically to a sender or sending environment.

Advantages can include greater control over IP reputation.

However, a dedicated IP is not automatically better.

A sender must establish and maintain its reputation properly, particularly when sending significant volumes.

What Is a Bounce?

A bounce occurs when an email cannot be successfully delivered.

Examples include:

Mailbox does not exist
Domain does not exist
Mailbox full
Recipient server rejected email
Policy rejection
Authentication problem

Professional transactional email services track these events and can make them available through dashboards, APIs or webhooks.

What Is a Webhook?

A webhook allows the email provider to notify your application when something happens.

For example:

Application sends email
        ↓
Provider accepts message
        ↓
Recipient server accepts/rejects message
        ↓
Provider generates event
        ↓
Webhook
        ↓
Your application

Possible events include:

Delivered
Bounced
Opened
Clicked
Complained
Unsubscribed
Deferred

Your software can then update its database automatically.

For example:

Invoice Email Status

Sent       → 10:30
Delivered  → 10:30
Opened     → 10:42

Example: Password Reset System

Consider a website where a user clicks:

Forgot Password

The complete workflow might be:

1. User enters email address

2. Website checks account

3. Application creates secure reset token

4. Application generates reset URL

5. Application sends request to email provider

6. Provider accepts email

7. Provider sends email

8. Recipient mail server receives it

9. User receives password-reset email

10. User clicks reset URL

The provider in Step 5 could be:

SendGrid
Mailgun
Amazon SES
Resend

Example: Software License Activation

Suppose software activation succeeds.

Your licensing server could automatically trigger:

License Activated Successfully

Customer: Example Customer
Product: Example Software
License: XXXXX-XXXXX
Activation Date: 28-Aug-2026

Architecture:

Desktop Software
      ↓
License Server
      ↓
Email API
      ↓
Transactional Email Provider
      ↓
Customer

This avoids embedding normal mailbox passwords inside desktop software.

API Keys Must Be Protected

Never place unrestricted transactional-email credentials inside publicly accessible frontend code.

For example, this is dangerous:

JavaScript running inside browser
       ↓
Permanent secret API key

A visitor may be able to extract that key.

A safer architecture is:

Browser
   ↓
Your Backend
   ↓
Protected API Key
   ↓
Email Provider

API keys should normally be stored in:

Environment variables
Secret managers
Protected server configuration

They should never be published in:

GitHub repositories
JavaScript frontend code
Public configuration files
Knowledgebase articles
Screenshots
Mobile application source where extraction is possible

Should You Use SMTP or API?

A simple rule is:

Existing software only supports SMTP

Use:

SMTP

Example:

WordPress Plugin
      ↓
SMTP
      ↓
SendGrid/Mailgun/SES/Resend

You are developing your own application

Consider:

API

Example:

PHP / Python / Node.js Application
      ↓
HTTPS API
      ↓
Email Provider

API integration often provides better control over application-specific features, errors, events and metadata.

Can You Change Providers Later?

Yes, and designing your software correctly makes migration much easier.

Instead of placing provider-specific code everywhere:

registration.php → SendGrid
invoice.php → SendGrid
password.php → SendGrid
alerts.php → SendGrid

create an internal email layer:

Application
      ↓
EmailService
      ↓
Current Provider

Then:

EmailService → SendGrid

can later become:

EmailService → Amazon SES

without rewriting the entire application.

This is particularly important when building commercial software.

Recommended Architecture

For a professional application:

USER / SOFTWARE
       ↓
APPLICATION
       ↓
EMAIL SERVICE MODULE
       ↓
QUEUE
       ↓
EMAIL API
       ↓
TRANSACTIONAL EMAIL PROVIDER
       ↓
INTERNET
       ↓
RECIPIENT

And separately:

EMAIL PROVIDER
       ↓
WEBHOOK
       ↓
APPLICATION
       ↓
EMAIL EVENT DATABASE

The application can therefore maintain its own status:

Queued
Sent
Delivered
Bounced
Failed
Opened
Clicked

This is much more robust than simply executing a basic mail command and assuming delivery succeeded.

Final Conclusion

SendGrid, Mailgun, Amazon SES and Resend belong to the broad category of cloud email delivery and transactional email infrastructure.

Their fundamental purpose is similar:

Allow websites, software and applications to send email reliably without requiring the developer to operate the entire underlying mail-delivery infrastructure.

A simplified way to understand the four platforms is:

SendGrid — mature transactional and marketing email ecosystem with strong API and SMTP support.

Mailgun — developer-oriented email infrastructure with particularly useful sending, receiving, validation and email-processing capabilities.

Amazon SES — scalable AWS email infrastructure that fits naturally into applications already using Amazon Web Services.

Resend — modern developer-focused email platform emphasizing straightforward APIs, SDKs, SMTP and application integration.

For developers, the decision should therefore not be based solely on the question:

"Which provider is cheapest?"

A better evaluation considers:

Integration complexity
        +
Expected email volume
        +
Deliverability requirements
        +
Logging requirements
        +
Inbound email requirements
        +
Webhook requirements
        +
Existing cloud infrastructure
        +
Support requirements
        +
Security
        +
Long-term scalability

Whichever service is selected, production deployments should properly configure domain authentication, protect API credentials, process bounces and complaints, monitor sender reputation, and maintain appropriate SPF, DKIM and DMARC configuration.

Frequently Asked Questions (FAQ)

1. What are SendGrid, Mailgun, Amazon SES and Resend?

They are cloud email-delivery platforms that allow websites and applications to programmatically send email using APIs and/or SMTP.

2. Are they email hosting providers like Google Workspace?

Not primarily. They are mainly designed for application-generated and transactional email rather than normal employee inboxes.

3. What is transactional email?

Transactional email is an automated message generated because of a user action, transaction or system event, such as a password reset, invoice, receipt or security alert.

4. Can I send password-reset emails through these services?

Yes. Password-reset messages are one of the classic transactional-email use cases.

5. Can I send OTP emails?

Yes. Applications can use transactional email infrastructure for email-based OTP and verification messages.

6. Do all four support SMTP?

Yes. SendGrid, Mailgun, Amazon SES and Resend provide SMTP-based sending options.

7. Do all four provide APIs?

Yes. Each provides programmatic API-based email functionality.

8. Which is better: SMTP or API?

For existing applications with SMTP support, SMTP may be easiest. For custom software development, APIs generally provide more programmatic control.

9. Can WordPress use these services?

Yes, provided an appropriate plugin or integration supports the provider's SMTP/API configuration.

10. Can PHP applications use them?

Yes. PHP applications can integrate using SMTP libraries, HTTP APIs or provider SDKs where available.

11. Can Python applications use them?

Yes.

12. Can Node.js applications use them?

Yes.

13. Can desktop software use a transactional email API?

Yes, but permanent secret API keys generally should not be embedded directly in distributable desktop software. A backend API is normally safer.

14. Is Amazon SES only for websites hosted on AWS?

No. External applications can also connect to SES through its supported interfaces, although AWS-hosted applications often benefit from particularly natural integration.

15. Does using these services guarantee delivery to Gmail inboxes?

No. Deliverability depends on numerous factors including sender reputation, authentication, complaints, bounce rates and recipient-provider policies.

16. Do I still need SPF?

Normally, domain authentication configuration should include the SPF requirements appropriate to your sending setup.

17. Do I need DKIM?

DKIM is strongly recommended for legitimate production email and is an important component of modern email authentication.

18. Should I configure DMARC?

Yes, organizations operating their own domains should generally implement DMARC as part of a properly planned email-authentication strategy.

19. Can I use Google Workspace and SendGrid together?

Yes. Google Workspace can provide employee mailboxes while SendGrid handles application-generated email.

20. Can Microsoft 365 and Amazon SES be used together?

Yes. Microsoft 365 can remain the business mailbox system while SES handles application-generated messages.

21. What is an email API key?

It is a credential used by an application to authenticate itself to the provider's API.

22. Should an API key be stored in JavaScript?

A permanent secret API key should not normally be exposed in browser-side JavaScript.

23. Can I publish my API key on GitHub?

No. Secrets should not be committed to public repositories.

24. What happens if an API key is leaked?

An attacker may potentially use the account to send unauthorized email, damage sender reputation or consume paid resources. The compromised credential should be revoked/rotated immediately.

25. What is a webhook?

A webhook is an HTTP callback through which the provider can notify your application about email events such as delivery or bouncing.

26. What is bounce handling?

Bounce handling is the process of detecting and managing emails that could not be delivered.

27. What is a suppression list?

It is a list used to prevent further sending to addresses that should no longer receive particular messages, such as addresses associated with certain bounces, complaints or unsubscribes.

28. What is sender reputation?

It is the reputation associated with your sending identity, domain and/or IP infrastructure that receiving email systems may consider when deciding how to handle your mail.

29. What is a dedicated IP?

A dedicated IP is sending IP infrastructure assigned specifically to a sender rather than shared across many unrelated customers.

30. Is a dedicated IP always better?

No. It requires appropriate sending volume, reputation management and often an IP warm-up strategy.

31. What is IP warm-up?

IP warm-up means gradually increasing email volume from a new dedicated IP to establish a sending history rather than suddenly sending very large volumes.

32. Can transactional email go to spam?

Yes. Using a professional provider reduces infrastructure complexity but does not eliminate spam filtering.

33. Can these services send HTML email?

Yes.

34. Can they send attachments?

The platforms provide mechanisms for attachments through their supported sending interfaces, although limits and implementation details vary by provider and plan.

35. Can I track email delivery?

Yes. These services provide varying levels of logs, events, analytics, webhooks and delivery information.

36. Can I track opens and clicks?

Providers offer engagement tracking capabilities, although privacy protections in modern mail clients mean open tracking should not be interpreted as perfect proof that a human actually read an email.

37. Which service is best for AWS applications?

Amazon SES is naturally integrated into the AWS ecosystem and is therefore an important option to evaluate.

38. Which service is easiest for a new developer?

Resend emphasizes a developer-first integration experience, while SendGrid and Mailgun also provide extensive developer APIs and SDKs. The easiest choice depends on the application's programming language and requirements.

39. Which is best for high-volume sending?

All four can support scalable sending in appropriate configurations. Required volume, quotas, pricing, IP strategy and deliverability requirements should be evaluated before choosing.

40. Can I switch providers later?

Yes. Building an internal email abstraction/service layer makes migration considerably easier.