Not Receiving Emails? A Step-by-Step Troubleshooting Guide

Missing email is one of the most frustrating problems in software, because the failure can happen at any point in a chain of systems — your sending server, DNS, the recipient's mail server, spam filters, and the recipient's mail client — and most of those steps are invisible to the user.

This guide walks through diagnosing missing emails systematically, whether you are a developer debugging an application sending issue or an end user who cannot receive mail.

Step 1: Confirm the email was actually sent

Before investigating the receiving side, verify the sending side.

Check application logs or delivery events

If email is sent through an API like Rovela, look at the delivery events for the message:

• Was the API call made? If no request appears in logs, the code that calls the API did not run.
• Did the API accept the message? An HTTP 422 means the request was malformed. An HTTP 500 means the sending service had an error.
• What is the delivery status? A successful API call means the message was accepted for delivery, not that it was delivered. Look for a delivery or bounce event.

Check for silent failures in your code

// This silently swallows errors
sendEmail(params);

// This surfaces them
const result = await sendEmail(params);
if (!result.ok) {
  console.error('Send failed:', result.error);
}

Many missing email bugs are silent exceptions: the code reaches the send call, an error occurs, and the application continues without anyone knowing the email was never sent.

Step 2: Check if the email bounced

If the message was accepted by the sending service but never arrived, check for a bounce notification.

Hard bounce: permanent failure

A hard bounce means the receiving server permanently rejected the message. Common causes:

• The email address does not exist (most common)
• The domain does not accept email
• The sender is on the receiving domain's permanent blocklist

Soft bounce: temporary failure

A soft bounce means temporary failure — the server accepted the connection but could not deliver the message now:

• Mailbox full
• Server temporarily unavailable
• Rate limiting

Most sending services retry soft bounces automatically over 24-72 hours. If the message still has not arrived after that window, check whether all retries have been exhausted.

Step 3: Check the spam folder

Spam folders are the most common destination for legitimate email that "didn't arrive."

If the email is there, the question is why it was classified as spam:

Spam filter scoring

Spam filters assign a score based on dozens of signals:

• Authentication failures: DKIM or SPF not passing increases the score
• Content signals: unusual URL patterns, certain phrases, excessive images, broken HTML
• Sending reputation: IP or domain reputation with that inbox provider
• Engagement history: if previous emails were never opened, new ones score lower

Getting out of spam

• Fix authentication first (see Step 5)
• Have the recipient mark the message as "Not Spam" — this is a direct signal to the provider
• If you are sending marketing email, review your list hygiene and unsubscribe management
• Use Google Postmaster Tools or Microsoft SNDS to see how the major providers view your sending reputation

Step 4: Check if the address was correct

A significant portion of "I didn't receive the email" reports come down to a typo in the address:

• user@gmai.com (missing l) — valid syntax, but this domain may catch the email
• user@example,com (comma instead of period) — API will return a validation error
• firstname.lastname @example.com (space before @) — same

If the address passes format validation but the email is not arriving, verify the exact address with the recipient by an out-of-band method (phone call, SMS, or in-person).

Step 5: Check your sending domain's authentication

Authentication failures cause many legitimate emails to land in spam or be rejected entirely.

Check SPF

Your SPF record should include every server that sends email on behalf of your domain. If you send through Rovela, your SPF record should include Rovela's SPF mechanism:

v=spf1 include:_spf.rovela.dev ~all

Use dig TXT yourdomain.com to verify the record is published, or check with an SPF validation tool.

Check DKIM

DKIM adds a cryptographic signature that the receiving server verifies. If the signature is missing or invalid, many providers will treat the message as suspicious.

In Rovela, every domain gets a unique DKIM key when you verify the domain. The key is published as a DNS TXT record. After making any DNS changes, verify the key is propagated:

dig TXT rovela._domainkey.yourdomain.com

Check DMARC

DMARC tells receiving servers what to do when SPF and DKIM fail. A p=reject DMARC policy means any message that fails authentication will be rejected outright.

If you recently added DMARC with p=reject and emails stopped arriving, check whether a sending server (an app, a third-party service) is not included in your SPF record or is not signing with DKIM.

Step 6: Check if your IP or domain is on a blocklist

Blocklisting is when an anti-spam organization or individual ISP adds your sending IP or domain to a list of known bad senders.

How to check

• MXToolbox (mxtoolbox.com/blacklists.aspx) checks against dozens of public blocklists
• Spamhaus (spamhaus.org) is the most influential blocklist — a listing here will severely affect deliverability to all major providers
• Barracuda, SORBS, and SpamCop are also widely used

How to get delisted

Most blocklists have a delisting process:

1. Identify and fix the underlying issue (compromised account, spam being sent from your IP, open relay)
2. Submit a delisting request with an explanation of what was fixed

Do not request delisting before fixing the issue — repeated listings are harder to remove.

Step 7: Check recipient server logs (if you have access)

If you are investigating a delivery failure between two servers you control, the receiving server's mail log is the authoritative source:

grep "from=<sender@domain.com>" /var/log/mail.log | tail -20

The log shows exactly what happened: whether the connection was accepted, whether the message was delivered to the mailbox, and if rejected, the exact rejection reason.

Step 8: Test with a fresh address

If you have exhausted other options, send a test email to a new address at a major provider (Gmail, Outlook, iCloud). If it arrives there but not at the target address:

• The problem is specific to that recipient domain
• Contact their mail administrator or IT department

If it does not arrive anywhere:

• Your sending IP may be rate-limited or blocked
• Your authentication setup has a systematic problem
• Your sending service is experiencing an outage

Preventing the problem

For application developers

• Log every send attempt with the recipient address, message ID, and API response
• Record delivery and bounce webhooks and store them attached to the original message
• Build an alerting threshold: if your bounce rate exceeds 2%, alert before it becomes a reputation problem
• Test your full send path in staging with a real inbox, not just a unit test

For end users and domain administrators

• Check spam folders first before assuming email was never sent
• Maintain your domain's DNS records and verify authentication periodically
• Review Postmaster Tools or similar dashboards to understand your reputation at major providers
• Keep your sending list clean — unsubscribers should be removed immediately, bounced addresses suppressed

Rovela automatically suppresses hard-bounced addresses and records delivery status for every message, so you always have a record of what was sent and what happened to it.