Why Your Support Emails Go to Spam (SPF, DKIM, DMARC Explained)

Few things hurt a support team more than replies that never arrive. The customer thinks you ignored them, writes again, gets frustrated, and your team has no idea the answer is sitting in their spam folder. The same goes for password resets, receipts and ticket notifications.

The good news: in most cases the cause is fixable in an afternoon. This guide explains why support emails go to spam, what SPF, DKIM and DMARC do in plain English, the rules Gmail, Yahoo and Outlook enforce today, and how to check that your emails pass.

The quick checklist

If you only have five minutes, check these first:

1. Your domain has one SPF record that includes every service that sends email for you.
2. DKIM is enabled for your help desk and any other sending service.
3. You have a DMARC record, at least p=none.
4. You send from your own domain, not from a free address like @gmail.com.
5. You stop sending to addresses that bounce.
6. Your marketing emails don't share a reputation with your support emails.

The rest of this guide explains each point.

How mailbox providers decide what's spam

Gmail, Outlook, Yahoo and others look at four things for every email:

• Authentication: can they confirm the email really comes from your domain? This is SPF, DKIM and DMARC.
• Reputation: does your domain (and the server sending for you) have a history of sending email people want?
• Engagement: do recipients open, reply and move your emails out of spam, or mark them as spam?
• Content: does the email look like typical spam, for example lots of links, link shorteners or a message that's just one big image?

Authentication is the foundation. Without it, good content and a clean list don't help much.

SPF: who is allowed to send for your domain

SPF (Sender Policy Framework) is a DNS record that lists the servers allowed to send email for your domain. When an email arrives, the receiving server checks whether it came from one of them.

An SPF record is a TXT record on your domain that looks like this:

01v=spf1 include:_spf.google.com include:amazonses.com ~all

This example allows Google Workspace and Amazon SES to send for the domain. ~all means other servers should be treated with suspicion.

Common SPF mistakes:

• Two SPF records. A domain can only have one. If you add a new tool, add its include: to the existing record instead of creating a second one.
• Too many lookups. SPF allows at most 10 DNS lookups. Every include: counts, and some include others. Remove services you no longer use.
• Forgetting a tool. Your help desk, CRM, billing system and newsletter tool may all send email as your domain. Each one needs to be covered by SPF or DKIM.

DKIM: a signature that proves the email is yours

DKIM (DomainKeys Identified Mail) adds a digital signature to every email. The sending service signs it with a private key, and publishes the matching public key in your DNS. The receiver checks the signature: if it matches, the email really comes from your domain and wasn't changed on the way.

You don't write DKIM records yourself. Your email or help desk provider gives you one or more records (usually TXT or CNAME, under a name like selector._domainkey.yourdomain.com) and you add them to your DNS. Prefer 2048-bit keys when you have the choice.

DKIM matters more than SPF in one important case: forwarding. When an email is forwarded, SPF usually breaks because the forwarding server isn't in your record, but the DKIM signature survives.

DMARC: what to do when checks fail

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM to the address customers see in the From field, and tells receivers what to do when an email fails.

A DMARC record is a TXT record at _dmarc.yourdomain.com:

01v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

• p=none only monitors. Nothing is blocked, but you receive reports.
• p=quarantine sends failing emails to spam.
• p=reject blocks failing emails completely.
• rua= is where daily aggregate reports are sent.

To pass DMARC, an email needs SPF or DKIM to pass and be aligned: the domain they authenticate must match the domain in the From address. This is why sending "on behalf of" your domain without proper setup fails, even when SPF technically passes for the provider's own domain.

Roll it out in stages: start with p=none, read the reports for a few weeks to find every service sending as your domain, fix the ones that fail, then move to p=quarantine and later p=reject.

The rules Gmail, Yahoo and Outlook enforce

Since 2024, the biggest mailbox providers turned these best practices into requirements:

Gmail also asks all senders, whatever their volume, to authenticate with SPF or DKIM. Even if you send far fewer than 5,000 emails a day, following the bulk sender rules is the safest way to land in the inbox.

Other reasons support emails land in spam

Authentication fixes most problems, but not all. Check these too:

• Sending from a free address. If your help desk sends as yourcompany@gmail.com, it can't authenticate for Gmail's domain. Always use an address on your own domain.
• Bounces. Repeatedly sending to addresses that don't exist hurts your reputation. Suppress addresses after they bounce.
• Spam complaints. Every "Report spam" click counts against you. Make unsubscribing from non-essential emails easy.
• Mixing marketing and support. A newsletter with a high complaint rate can drag down the reputation of your password resets. Send marketing from a subdomain, like news.yourdomain.com, and keep support and transactional email on your main domain or their own subdomain.
• A brand-new domain sending a lot at once. Increase volume gradually so providers can build trust in your domain.
• Spammy content. Avoid link shorteners, all-caps subjects, image-only emails and attachments nobody asked for.
• Mismatched Reply-To and From. Unusual combinations can look suspicious. Keep them on the same domain when you can.

How to check your emails pass

1. Gmail "Show original". Send an email from your help desk to a Gmail account, open it, click the three-dot menu and choose Show original. At the top you'll see SPF, DKIM and DMARC with PASS or FAIL.

2. Check your DNS records. Free tools like MXToolbox show your SPF, DKIM and DMARC records and flag common errors like duplicate SPF records or too many lookups.

3. Google Postmaster Tools. If you send a meaningful volume to Gmail users, Postmaster Tools shows your domain's reputation, spam rate and authentication results over time.

4. Read your DMARC reports. The aggregate reports sent to your rua address list every server sending email as your domain, and whether it passed. They're XML files, so many teams use a free DMARC report viewer to read them.

What to do if your domain is already in trouble

1. Fix authentication first. Make sure SPF, DKIM and DMARC pass for every sending service.
2. Clean your lists. Remove addresses that bounce and people who never engage.
3. Pause bulk sends like newsletters until support and transactional email recover.
4. Send to people who expect it. Replies to customers who wrote to you are the best email you can send for your reputation.
5. Be patient. Reputation recovers over days or weeks of good sending, not hours.

How TickOS keeps support email out of spam

TickOS sends every ticket reply, auto-acknowledgement and transactional email from your own verified domain, and guides you through the setup:

• Guided DNS setup with the exact SPF, DKIM and DMARC records to add, and a Verify button to check them.
• DKIM with 2048-bit keys.
• A custom MAIL FROM subdomain (like mail.yourdomain.com), so the return path matches your domain and passes DMARC alignment.
• Send the DNS instructions to your IT team by email if someone else manages your domain.
• Bounced addresses are suppressed automatically, so you don't keep damaging your reputation.
• Daily and hourly sending limits that protect new domains from sending too much too soon.

If you're also choosing an email API for your app's own emails, see our comparison of Resend alternatives for transactional email. And if your support still runs from a shared mailbox, start with how to turn emails into support tickets.