Why Your Store Emails Land in Spam — and the 3 DNS Records That Fix It
You answer a customer's question. They say they never got it. A refund request sits unanswered because your reply is buried in their Promotions or Spam tab. For a small store, a few missed emails a week quietly become lost sales, angry reviews, and a sender reputation that keeps getting worse.
The good news: most deliverability problems come from three missing or broken DNS records — and they're fixable in an afternoon.
The 30-second version
- SPF, DKIM and DMARC are DNS records that prove an email really came from you. Missing any of them = higher spam risk.
- Authentication is only half of it. Sender reputation (engagement, complaints, list hygiene) decides the other half.
- Fix the three records, warm up your domain, keep content personal — and reply volume actually helps reputation.
- AI replies sent from your own mailbox inherit your reputation. They don't hurt deliverability if configured right.
What "email deliverability" actually means
Deliverability is the percentage of emails you send that actually reach the inbox (not spam, not bounced, not silently dropped). For transactional and support mail — order confirmations, shipping updates, return replies — deliverability is the product. If it lands in spam, the customer experiences silence.
Receiver-side filters (Gmail, Outlook, Apple Mail, Yahoo) make the final call using two broad signals:
- Authentication — did this message come from who it claims? (SPF, DKIM, DMARC)
- Reputation — does this sender behave like a trustworthy, wanted sender? (engagement, complaint rate, volume patterns)
The 3 authentication records, in plain English
All three live in your domain's DNS. None require coding — you add them where you bought your domain or host your email.
What it does: publishes a list of the servers allowed to send email for your domain. When a receiver gets mail from you, it checks: "Is this server on the approved list?" If not, the message is suspect.
What it looks like: a single TXT record like v=spf1 include:spf.qiye.aliyun.com ~all (or your email provider's include).
Common mistake: having more than one SPF record — only the first is read, so consolidate into one.
What it does: adds a cryptographic signature to every message. The receiver verifies it with a public key published in DNS. This proves the email wasn't altered in transit and that it originated from you.
Why it matters: SPF alone breaks when email is forwarded. DKIM survives forwarding, so it's the more durable proof of identity.
Common mistake: generating a key at your email host but never publishing it — or rotating it and leaving the old one, which silently fails verification.
What it does: ties SPF and DKIM together and tells receivers what to do when a check fails — quarantine, reject, or allow — and sends you daily reports of who is sending as you (great for catching spoofing).
Why it matters: without DMARC, a failed SPF/DKIM check is treated inconsistently. DMARC makes your policy explicit and gives you visibility.
Start gently: publish p=none first (monitor only), review reports, then move to p=quarantine and finally p=reject.
Authentication is half the battle: sender reputation
Even with perfect SPF/DKIM/DMARC, a brand-new domain sending bursts of identical messages will get throttled. Reputation is built on behaviour:
- Engagement — do recipients open and reply, or ignore and delete? Replies are the strongest positive signal.
- Complaint rate — marked-as-spam clicks. Keep this tiny; a few per thousand is normal, more is dangerous.
- List hygiene — sending to dead or purchased addresses hurts you. Only email people who opted in or are active customers.
- Consistency — sudden volume spikes from a cold domain look like a blast. Warm up gradually.
This is why genuine, personal customer replies are good for deliverability — they're opened and answered, not flagged.
A 5-step checklist to stop landing in spam
- Add SPF, DKIM and DMARC at your DNS host. Run a health check to confirm all three pass.
- Send from your main domain (or a subdomain like
support.yourstore.com) that is properly authenticated — not an unrelated domain. - Warm up a new domain: start with low volume and ramp over 2–4 weeks rather than blasting from day one.
- Keep content personal and relevant. Plain-language, customer-specific replies beat templated mass mail. Avoid ALL CAPS, link stuffing, and "free!!!" hype language.
- Monitor with DMARC reports and a periodic health check. Fix issues before they compound.
How AI replies fit in (without hurting you)
A common worry: "If an AI answers my email, will that get me flagged?" The answer depends on how it sends.
RespondThat drafts and sends through the mailbox you connect — your domain, your SPF and DKIM, your reputation. It is not bulk-mailing from a shared IP. Because replies are personal, specific to each customer, and often answered by the customer (a strong positive signal), they behave like normal first-party support mail.
The only real risk is content quality — and that's exactly what brand-voice drafting and human review are for. You can always read a draft before it goes out.
Frequently asked
SPF publishes which mail servers are allowed to send for your domain. DKIM adds a cryptographic signature so the message can't be tampered with and proves it came from you. DMARC ties the two together and tells receivers what to do if either check fails — and sends you reports. You generally want all three.
Signs include customers saying they never got your reply, opens suddenly dropping, or your messages showing a "via" label or a red lock icon. The fastest check is a free email health check that tests your SPF, DKIM and DMARC records and your domain reputation in one report.
Not if the AI sends through your own authenticated mailbox. RespondThat drafts and sends from the mailbox you connect (your domain, your SPF/DKIM), so replies inherit your existing reputation instead of being bulk-mailed from a shared IP. The risk is only in the content — keep replies personal and relevant, which AI drafting helps with.
DNS changes usually propagate within minutes to a few hours, but some receivers cache records for up to 24–48 hours. After adding or fixing a record, wait a day and re-run a health check before judging the result.
You can, but it's risky. Mail from a domain that doesn't match your store looks spoofed and is more likely to be filtered. Best practice is to send from your main domain (or a subdomain like support.yourstore.com) that has SPF, DKIM and DMARC properly configured.