Why your support replies land in spam (and how to stop it)

When support replies get filtered, it is rarely the words in the message — it is almost always an authentication or reputation problem the receiver can see and your team cannot. The usual culprits are a missing DKIM signature, a “via your vendor” leak, an SPF record that doesn’t cover your real sender, a return-path on the wrong domain, and either no DMARC or a too-strict one enabled before monitoring. Here are the five most common causes, worst first, with the fix for each.

1. No DKIM signature

Unsigned mail cannot be verified, so receivers treat it as suspect — and unsigned support mail also fails DMARC by default, since DMARC needs SPF or DKIM to pass and align. Publishing DKIM is the single highest-leverage fix — see the DKIM definition for the mechanics. A valid signature also survives forwarding, which SPF does not, so it’s the more durable of the two checks.

2. A “via” leak from your vendor

If recipients see “via amazonses.com,” you are signing as your provider, not yourself: the d= domain in the DKIM signature belongs to the vendor. That both advertises your tooling and fails DMARC alignment, because the signing domain isn’t your From domain. BYODKIM puts the signing key on your own domain so d= is yours, the leak disappears, and DKIM alignment passes. The relationship between alignment and these checks is laid out in SPF, DKIM, and DMARC: the difference.

3. SPF that doesn’t list your sender

SPF must authorize whatever server actually sends your mail, and stay under the ten-lookup limit. Stacking providers with multiple include: mechanisms silently blows past that limit, at which point SPF returns permerror and stops helping. A second gotcha: a domain may have only one SPF TXT record — a duplicate is an error, not a merge.

4. A mismatched return-path

A return-path (the envelope sender SPF actually checks) on the vendor’s domain breaks SPF alignment and sends bounces somewhere you never read — so you don’t even learn which addresses are failing. Put the return-path on your own subdomain so SPF aligns with your From domain and the bounce stream comes back to you.

5. No DMARC, or a too-strict one set too soon

Without DMARC you have no visibility into who passes, who fails, and who is spoofing you. But with a reject policy set before monitoring, you can blackhole your own legitimate mail the moment one source isn’t aligned. Start at p=none, read the aggregate reports until every real sender passes, then ratchet up to quarantine and finally reject.

Beyond authentication: reputation

Authentication gets you in the door; reputation decides which folder you land in. Even perfectly signed mail can be filtered if the sending domain or IP has a poor history. The factors that move reputation are blunt and behavioral:

• Spam complaints. Recipients hitting “report spam” is the strongest negative signal there is.
• Bounce rate. Repeatedly mailing dead addresses signals a careless or scraped list — track bounces and complaints.
• Engagement. Mail that gets opened and replied to builds reputation; mail that’s ignored erodes it. Support replies are usually high-engagement, which works in your favor — if authentication lets them through.
• Shared pools. On a shared sending IP or domain, another sender’s bad behavior drags your delivery down with it. Sending from your own isolated domain keeps your reputation yours.

How to diagnose it yourself

You don’t need vendor tooling to find the cause. Send a test reply to an address you control and inspect the raw headers:

• Open the Authentication-Results header and look for spf=, dkim=, and dmarc=. Anything other than pass on all three is your lead.
• Check the d= tag in the DKIM-Signature header. If it isn’t your domain, that’s the “via” leak.
• Find the Return-Path header and confirm it’s on your domain, not the vendor’s.
• Read your DMARC aggregate reports — they name every source sending as you and whether each aligns.

The end-to-end checklist, including the DNS records, is in the deliverability guide.

The order to fix it

Work in dependency order so you never enforce before mail authenticates: publish SPF for your real sender, enable DKIM signing on your own domain, move the return-path onto your subdomain, confirm all three pass on a test message, then add DMARC at p=none and ratchet up. Cherryrise sets DKIM, the return-path, and alignment up from two DNS records, so all five failure modes above are closed at once — and because every workspace sends as its own domain through its own SES, your reputation is never pooled with anyone else’s.

Frequently asked questions

Why do only some of my support replies go to spam?

Inconsistent filtering usually points to authentication that passes intermittently rather than content. SPF can pass on a direct send but fail after a forward; a reply threaded into a long mailing-list conversation may have its body modified, breaking the DKIM body hash; and reputation is evaluated per receiver, so Gmail and Outlook can disagree on the same message. The fix is to make authentication deterministic — DKIM signing on your own domain, an aligned return-path, and a DMARC record — so the result no longer depends on the path the message took.

Does adding an unsubscribe link help support email reach the inbox?

For genuine one-to-one support replies it is not required and adds little, because those are transactional, solicited messages. It matters for bulk or notification mail, where large mailbox providers expect easy unsubscription. The far bigger levers for support replies are authentication and reputation: DKIM, SPF alignment, a clean return-path, and a sending domain that is not pooled with other senders.

How long does it take to recover sender reputation?

There is no fixed timer. Reputation is rebuilt by sending wanted mail that recipients open and reply to, and not sending mail that gets marked as spam or bounces. After you fix the underlying authentication problem, consistent good sending over days to a few weeks typically moves the needle, but heavily damaged domains take longer. Sending from your own isolated domain rather than a shared pool means your recovery depends only on your own behavior.

Will switching help-desk tools fix my spam problem?

Only if the new tool changes the underlying signals. A tool that signs DKIM as its own domain, shares a sending IP pool, or uses its own return-path will reproduce the same problems. What actually fixes it is sending signed as your own domain with an aligned return-path on infrastructure whose reputation is yours alone — which is what BYODKIM on your own SES gives you.