A user signs up for your SaaS product. The welcome email never arrives. They try resetting their password. That email does not arrive either. They assume the product is broken and leave.
Your website is up. Your API responds in 200ms. Every uptime check is green. But email delivery has been silently failing for hours because your SMTP provider is throttling you, your MX records changed after a DNS migration, or your SPF record is misconfigured.
Email is infrastructure. When it breaks, users cannot sign up, cannot reset passwords, cannot receive invoices, and cannot get the notifications they depend on. Yet most monitoring setups ignore it completely.
This guide covers how to monitor email delivery so you catch failures before they affect users.
Why Email Monitoring Is Critical
Email touches nearly every part of a web application:
- Authentication — Password resets, email verification, magic links, two-factor codes
- Transactional — Order confirmations, invoices, shipping notifications, receipts
- Notifications — Alert emails, activity digests, collaboration updates
- Marketing — Welcome sequences, product announcements, re-engagement
- Internal — Error reports, cron job summaries, system alerts
When email fails, the impact is different from a website outage. There is no error page. The user simply does not receive something they expected. They may not report it for hours or days because they assume the email is delayed or in spam.
What to Monitor
1) SMTP Server Availability
If you run your own mail server or relay, monitor that it accepts connections:
- TCP port check on port 25 — Standard SMTP
- TCP port check on port 465 — SMTPS (implicit TLS)
- TCP port check on port 587 — Submission (STARTTLS)
A TCP port check verifies the SMTP server is running and accepting connections. If the port is unreachable, no email can be sent or received.
For self-hosted mail servers (Postfix, Exim, Exchange), this is the first line of defense. The mail server process can crash, the server can run out of disk space, or a firewall change can block the port.
2) MX Record Monitoring
MX (Mail Exchange) records tell the internet which servers handle email for your domain. If MX records are wrong, email sent to your domain goes to the wrong place — or bounces entirely.
Monitor:
- MX record resolution — Verify your domain's MX records resolve to expected mail servers
- MX record priority — Ensure the correct server has the highest priority
- Unexpected changes — Alert when MX records change outside of a planned migration
MX record issues are especially dangerous because:
- Senders get no error — their mail server queues the message and retries
- The problem can be regional if DNS propagation is uneven
- A DNS provider misconfiguration can redirect all incoming email to a wrong server
3) DNS Authentication Records
Modern email delivery depends on three DNS records that prove you are authorized to send email:
SPF (Sender Policy Framework):
- A TXT record listing which servers can send email for your domain
- If misconfigured, receiving servers reject or spam-flag your messages
- Monitor that the SPF record exists and contains your sending servers
DKIM (DomainKeys Identified Mail):
- A TXT record containing a public key for email signature verification
- If the DKIM record is missing or wrong, email authentication fails
- Monitor the DKIM selector record for your domain
DMARC (Domain-based Message Authentication):
- A TXT record defining what to do when SPF/DKIM fails
- Protects against spoofing and provides reporting
- Monitor that the DMARC record exists with your intended policy
DNS record monitoring catches these issues because SPF, DKIM, and DMARC are all DNS TXT records that can be accidentally deleted, overwritten, or broken during DNS migrations.
4) Third-Party Email Provider Health
Most applications use a third-party email service. Monitor their availability:
| Provider | Status/API Endpoint |
|---|---|
| SendGrid | https://status.sendgrid.com |
| Postmark | https://status.postmarkapp.com |
| Amazon SES | Region-specific health dashboard |
| Mailgun | https://status.mailgun.com |
| Resend | https://resend-status.com |
Monitor the provider's status endpoint or API endpoint with an HTTP check. When your provider has an outage, you want to know before your users report missing emails.
Additionally, if your provider exposes a sending API, monitor it:
GET https://api.sendgrid.com/v3/mail/send
An HTTP check on the API endpoint (expecting a 4xx for unauthorized, not a 5xx or timeout) validates the service is reachable.
5) Email Delivery Pipeline (End-to-End)
The most comprehensive check: send a test email and verify it arrives.
Heartbeat approach:
- A scheduled task sends a test email every N minutes
- The receiving side (a webhook, a mailbox check, or a forwarding rule) pings a heartbeat URL when the email arrives
- If the heartbeat does not arrive on schedule, the email pipeline is broken
This catches issues that individual checks miss:
- Provider is up but your account is suspended
- Sending rate limit exceeded
- Email queued in your application but not dispatched
- Email sent but blocked by receiving server
6) Email Queue Health
If your application queues emails (common in Laravel, Django, Rails), monitor the queue:
- Queue depth — A growing queue means emails are being produced faster than sent
- Queue worker health — Use heartbeat monitoring to verify workers are processing
- Oldest message age — If the oldest message is hours old, the queue is stuck
Common Email Failure Modes
| Failure | Impact | Detection |
|---|---|---|
| SMTP server process crashed | No email in or out | TCP port check on 25/465/587 |
| MX records changed/deleted | Incoming email lost or bouncing | DNS monitoring on MX records |
| SPF record missing/broken | Outgoing email marked as spam | DNS monitoring on TXT records |
| DKIM key rotated incorrectly | Email signature verification fails | DNS monitoring on DKIM selector |
| Email provider outage | Transactional emails delayed or lost | HTTP check on provider status/API |
| Sending rate limit exceeded | Emails queued and delayed | Queue depth monitoring + heartbeat |
| Account suspended by provider | All email stops | End-to-end delivery heartbeat |
| DNS migration breaks records | SPF, DKIM, MX all affected | DNS monitoring on all email records |
| Disk full on mail server | Mail server stops accepting messages | TCP port check + end-to-end heartbeat |
| TLS certificate expired on mail server | Connections rejected by strict senders | SSL monitoring on mail server hostname |
| Application queue worker stopped | Emails queued but not sent | Heartbeat monitoring on queue worker |
Monitoring by Email Setup
Third-Party Email API (SendGrid, Postmark, SES, Resend)
Most modern apps use an API-based email service:
- HTTP check on provider API — Verify the endpoint is reachable
- DNS monitoring — SPF, DKIM, and DMARC records
- Application queue heartbeat — If emails are queued before sending
- End-to-end delivery heartbeat — Periodic test email with arrival verification
Self-Hosted Mail Server (Postfix, Exim)
- TCP port checks on ports 25, 465, and 587
- SSL monitoring on the mail server hostname
- DNS monitoring — MX, SPF, DKIM, DMARC records
- Disk space monitoring — Mail servers fail when disk is full
- Queue depth — Monitor the mail queue for backlog
- End-to-end delivery heartbeat
Google Workspace / Microsoft 365
- MX record monitoring — Verify records point to Google or Microsoft
- DNS monitoring — SPF, DKIM records for your domain
- HTTP check on provider status — Google Workspace or Microsoft 365 status
- Application-level monitoring — If your app sends via SMTP relay or API
Setting Up Email Monitoring
Quick start (5 minutes)
- DNS monitoring on your domain's MX records — Catch record changes
- DNS monitoring on SPF TXT record — Verify sending authorization
- HTTP check on email provider API/status — Catch provider outages
- Application queue heartbeat — Verify emails are being dispatched
Comprehensive setup
Add to the above:
- TCP port checks on mail server ports (if self-hosted)
- SSL monitoring on mail server hostname
- DKIM and DMARC DNS monitoring
- End-to-end delivery heartbeat — Test email sent and arrival verified
- Multi-region DNS checks — Catch propagation issues affecting specific regions
How Webalert Helps
Webalert monitors the infrastructure that email delivery depends on:
- TCP port monitoring — Verify SMTP servers accept connections on ports 25, 465, 587
- DNS monitoring — Track MX, SPF, DKIM, and DMARC records for changes
- SSL monitoring — Catch certificate issues on mail server hostnames
- HTTP checks — Monitor email provider API and status endpoints
- Heartbeat monitoring — Verify email queue workers and scheduled tasks run on time
- Multi-channel alerts — Email, SMS, Slack, Discord, Teams, webhooks
- 60-second intervals — Detect SMTP failures within 2 minutes
See features and pricing for details.
Summary
- Email delivery fails silently — users do not see an error page, they just do not receive the message.
- Monitor SMTP ports, MX records, and DNS authentication records (SPF, DKIM, DMARC).
- Third-party provider outages affect your email. Monitor their status endpoints.
- Use heartbeat monitoring for application email queues and workers.
- End-to-end delivery testing is the most comprehensive check — send a test email and verify arrival.
- DNS migrations are the most common cause of email infrastructure breakage.
- Start with MX record monitoring, SPF monitoring, and a queue worker heartbeat.
Your application sends the email. Monitoring proves it was delivered.