Email Spam Placement: Nine Causes and How to Fix Them

· Original article ↗

Summary

Based on 100+ audits, the article explains why messages reach spam and recommends monitoring domain/IP reputation, suppressing disengaged recipients, validating SPF/DKIM/DMARC, enforcing DMARC, and restricting SaaS notification features that can be abused for phishing.

Key points

  • A high delivery rate shows that a receiving server accepted a message; it does not show that the message reached the inbox.
  • The article identifies authentication failures, domain or IP reputation, unengaged recipients, spoofing, and excessive sending as causes of spam placement.
  • Audit SPF, DKIM, and DMARC records across sending domains; monitor reports and consider moving DMARC from p=none to enforcement after verifying legitimate mail streams.
  • Monitor domain and IP reputation, and address low engagement, complaints, and bounce rates before expanding sending volume.
  • Suppress recipients who have not engaged within a defined period, and monitor deliverability metrics by individual sender on shared platforms.
  • The article describes how attackers can abuse SaaS notification features to send phishing messages through the platform's trusted email infrastructure; it recommends restricting alert customization.
  • Set aggregate sending limits and align email frequency with what recipients were told to expect.

Article Details

Defense Focus
Detect and reduce email spoofing, reputation damage, and abuse of shared SaaS email infrastructure that can deliver phishing messages.
Detection Methods
  • Review domain reputation and related signals in Google Postmaster Tools at least weekly.
  • Analyze DMARC reports to identify unauthorized senders and authentication failures.
  • Track engagement, complaints, bounces, and spam-trap hits by individual sender and sending IP, not only in aggregate.
  • Compare IP reputation across Google Postmaster Tools, Sender Score, and Talos Intelligence.
  • Audit SPF, DKIM, and DMARC records for every sending domain and verify them after infrastructure changes.
  • Use feedback-loop data and sender-level blocking trends to identify sources of reputation damage.
Data Sources
  • Google Postmaster Tools domain and IP reputation signals
  • DMARC reports, including rua and ruf reports
  • SPF, DKIM, and DMARC DNS records
  • Sender-level engagement, complaint, bounce, and spam-trap metrics
  • IP reputation results from Sender Score and Talos Intelligence
  • Email provider feedback-loop and blocking data
Defensive Actions
  • When domain reputation drops, reduce sending volume and target recently engaged recipients for three to four weeks; expand cautiously after reputation stabilizes.
  • Suppress recipients after a defined period without opens or clicks; the article suggests six months as a starting point, or 60–90 days when reputation is deteriorating. Limit attempts to reach never-engaged addresses to two or three.
  • Validate SPF, DKIM, and DMARC for every sending domain, update records after infrastructure changes, and rotate DKIM keys.
  • Enable DMARC reporting and move from p=none toward p=quarantine or p=reject after confirming that legitimate mail streams authenticate correctly.
  • Consider MTA-STS, TLS-RPT, and DNSSEC to address email transport and DNS security risks.
  • Monitor performance by sender; address poor performers with coaching, volume caps, lead-upload restrictions, IP segmentation, or removal from the platform.
  • Restrict customization of notification alerts and prevent users from adding arbitrary recipients or inserting phishing links into platform-generated messages.
  • Set aggregate sending-frequency limits across campaigns and workflows, and pause resend campaigns to non-openers.
  • Investigate the underlying engagement or complaint issues before requesting mitigation for a blocked IP; distribute sending volume consistently across dedicated IPs.

MITRE ATT&CK

Vendors

Products

Related Articles