Cart
Net 9 regions SYD 264 ms FRA 18 ms NRT 232 ms Uptime 30d 99.997 %

03 / Email

Troubleshooting email: why your messages land in spam

The six reasons mail lands in spam, how to test each one, and the fix order that actually works.

8 min read · Updated April 2026

You send a message. The recipient does not see it. You check Sent: it's there. You check their spam folder: it's there. This article walks through the six causes of mail landing in spam, in the order we check them when a customer opens a ticket.

1. Authentication (SPF/DKIM/DMARC) is wrong

Most common by far. Send a message to mail-tester.com; their service gives you a 0-10 score and a breakdown. Under 8/10, fix authentication before doing anything else. See the SPF/DKIM/DMARC article for exact records.

bash
# Quickly check from command line
dig +short TXT yourdomain.com | grep spf
dig +short TXT default._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com

# All three should return populated records

2. Server IP is on a blacklist

The IP that sent the message is flagged by a spam database. Check every major list at once with mxtoolbox.com/blacklists.aspx. If Spamhaus, Barracuda, or SORBS are red, you have two paths:

  1. 01. If you're on a shared IP and listed due to another customer, email [email protected] and we'll investigate. We monitor our outbound IPs continuously and delist quickly.
  2. 02. If you're on a dedicated IP, go to each blacklist's removal form and submit a delist request. Include the reason (e.g. compromised account, now fixed).

3. Reverse DNS (PTR) doesn't match

Receiving servers check that the sending IP's reverse DNS resolves to a hostname matching HELO. Mismatch → suspicious. On Omega Digital, PTR is set at the server level and usually correct. Verify:

bash
# Find your server's sending IP
dig +short A mail.yourdomain.com

# Check its reverse DNS
dig -x 198.51.100.42 +short

# Should return a name that makes sense, e.g. mail.yourdomain.com
# or server.omdigital.cc — not, say, a random generic hostname

4. Message content triggers filters

Spam filters score content. High-score triggers:

  • · All-caps subject lines
  • · Subject with lots of punctuation (!!!, $$$)
  • · Single-image emails with no text
  • · Shortened URLs (bit.ly, tinyurl)
  • · Too many links relative to text
  • · Words like 'free', 'guarantee', 'congratulations' in the subject

Run the message through mail-tester.com or Mailgun's Postmaster tools. They score content separately from authentication.

5. Domain has no history or a bad history

A brand-new domain with no sending history gets treated with suspicion by Gmail. Warm up slowly. Send 10-20 messages per day for the first week, 50-100 the second, then scale. Sudden volume spikes from a cold domain are a classic spammer signature.

If the domain was recently owned by a spammer, you inherit their reputation. Check the domain's history at archive.org and look for spam-complaint tools like Postmark's SpamAssassin report.

6. Recipient has marked earlier mail as spam

A Gmail user marking two of your messages as spam can poison delivery for that entire domain pair. There is no external fix; the recipient has to un-mark and add you to contacts. For mass mail, always honor unsubscribes immediately and prune unengaged subscribers.

A systematic test

  1. 01. Open mail-tester.com in a browser. It shows an address like [email protected].
  2. 02. Send a normal message from your domain to that address.
  3. 03. Wait 30 seconds, then click 'Then check your score'.
  4. 04. Read every item that isn't green. Fix the highest-impact issues first: authentication, then blacklists, then content.
  5. 05. Re-test with a fresh mail-tester address. Repeat until the score is 9/10 or higher.

Common gotchas

  • · Testing only with Gmail. Gmail is actually permissive compared to Microsoft 365 and Yahoo. Test to all three.
  • · Not rotating the test inbox. Once an inbox marks you spam, every new test goes to spam. Use a fresh address for each round.
  • · Ignoring DMARC reports. If DMARC shows a pattern of failures, that's your diagnostic. Follow where the failed IPs lead.
  • · Sending via a PHP script that uses the local mail() function with no authentication. This is the #1 cause of mail landing in spam on shared hosting. Always send via authenticated SMTP.

Still stuck?

Email [email protected] with the mail-tester URL and the recipient domain. We'll dig into it.

Support

Email [email protected] with your account email and the exact error. Direct support.