SapotaCorp

SFMC Email Frequency and Spam Filters: Send Enough, Not Too Much

Client pushes for four sends a week instead of one. Unsubscribe triples, complaints rise, open rate drops, revenue doesn't budge. Here's how we think about frequency and the spam-filter patterns we avoid.

Key takeaways

  • Frequency increases (1 send/week to 4/week) typically triple unsubscribe rates, raise complaints 2x to 5x, drop open rates 30 to 50 percent, and produce flat or declining revenue. The math: marginal sends do not convert at the same rate as the first.
  • Einstein Engagement Frequency suggests per-subscriber send caps based on engagement patterns. Use it as guidance, not law — Einstein optimizes for opens, which correlates with but does not equal revenue. Override when the business case warrants it, document the reason.
  • Spam-filter content signals to avoid: ALL CAPS subject lines, excessive punctuation (!!!), spam-trigger words (FREE, ACT NOW), image-to-text ratio over 60 percent, short subject lines under 20 characters. Content Detective in SFMC scores against these signals.
  • Volume-based ISP flags trigger when sender volume spikes 5x to 10x without warning. Gmail, Yahoo, Outlook all suspect rapid volume growth — they assume list quality dropped. Ramp volume gradually (20 to 50 percent week-over-week max) to avoid the flag.
SFMC Email Frequency and Spam Filters: Send Enough, Not Too Much

A retail client we advised decided to quadruple email frequency - from one send per week to four - believing more sends would mean more revenue. Within a month:

  • Unsubscribe rate tripled.
  • Complaint rate crossed the 0.1% threshold.
  • Open rate dropped 30%.
  • Revenue stayed flat.

The ISPs noticed too. Inbox placement on subsequent sends degraded. The account spent 6 weeks recovering deliverability after 3 weeks of over-sending.

Email frequency has rules, and they're not flexible.

The core rule

Send what the subscriber expected when they opted in. If the signup form said "weekly newsletter," weekly is the promise. Daily isn't aggressive growth; it's a broken contract that triggers unsubscribes and complaints.

Subscribers opt in with a mental model of what they'll receive and how often. Violating that model produces two outcomes:

  1. Unsubscribe (best case).
  2. Spam complaint (worst case - damages sender reputation).

Three questions before every additional send

1. Is this content genuinely relevant to the subscriber?
2. Does the subscriber expect to receive this category of email?
3. Is this the right time (not a bad moment, not too close to the last send)?

If any answer is "no," don't send. "The campaign deadline is tomorrow" isn't a good enough reason to break the frequency promise.

Einstein Engagement Frequency

If the client's account has Einstein, use Engagement Frequency instead of guessing. It analyzes each subscriber's historical engagement to predict:

  • The ideal email volume per week for this subscriber
  • Whether the subscriber is currently being over-contacted (at risk of unsubscribe)
  • Whether the subscriber could absorb one more email this week without harm

Output: per-subscriber recommended frequency. Use it to filter the audience on high-volume sends - skip anyone flagged "over-contacted" to protect retention.

Einstein Engagement Frequency is bundled with Marketing Cloud Advanced editions - check if the client has access before promising its use.

Spam filter content signals to avoid

Spam filters look at content patterns regardless of sender reputation. Avoid:

  • All-caps subject lines: "50% OFF TODAY ONLY!!!"
  • Excessive exclamation marks anywhere in the email
  • Spam trigger words: "Free," "Guaranteed," "No risk," "Click here," "Act now"
  • Image-heavy with little text: images without enough accompanying text read as spam camouflage
  • Missing text version: HTML-only emails are downgraded by many filters

Ironically, the content that's "most aggressive marketing" is also the content that triggers the most spam filters. Copy that reads naturally tends to deliver better.

Volume-based ISP flags

ISPs also watch sending behavior:

  • Sudden large volumes from a new IP (before IP warming completed) - flagged as suspicious sender.
  • High bounce rate on a send - flagged immediately by receiving ISPs.
  • High complaint rate - flagged; reputation damage persists.
  • Low engagement across many sends - gradual downgrade to Promotions / Spam.

Ramping a new dedicated IP requires a warming plan - a few thousand sends on day 1, gradually doubling, across weeks. Going from 0 to 500k overnight on a new IP is instantly suspicious.

Content Detective in SFMC

Before sending, run the email through Content Detective. It scans for spam-filter patterns and flags potential issues:

  • Trigger words
  • Excessive punctuation
  • Image-to-text imbalance
  • Bad HTML patterns
  • Broken links

Content Detective isn't perfect - some filtered content will still deliver, some clean content gets filtered - but running it is a 5-minute safety check that catches the worst offenders.

What "good frequency" looks like

Mid-market B2C retail, healthy setup:

  • 1 newsletter per week
  • 2-4 promotional sends per month (seasonal / sale events)
  • Triggered emails (welcome, cart abandon, post-purchase) on event
  • Total: 4-8 emails per month

Subscribers who want more can be offered higher-frequency segments (daily deals, VIP tier) via Publication Lists. Subscribers who want less can downshift the same way. Granular preferences reduce unsubscribes.

Takeaway

Frequency isn't a lever to pull for more revenue; it's a contract with subscribers. Violate it and short-term revenue gains are wiped out by long-term deliverability damage. Use Einstein Engagement Frequency if available, Content Detective every send, and publication-level preferences for granular opt-in. Respect the promise you made at signup.


Balancing revenue goals with deliverability constraints? Our Salesforce team advises on send cadence, Einstein features, and content optimization on production SFMC engagements. Get in touch ->

See our full platform services for the stack we cover.