Why Your Review Request Emails Go to Spam (And How to Fix It)

Is it the words or the sender?

Most merchants respond to a spam problem by rewriting the email. They soften the subject line, remove the word free, shorten the body, and send again into the same folder. The rewrite rarely helps because filters make most of the decision before they read anything: who sent this, is that provable, and does mail from them usually get opened.

So start with one piece of evidence rather than a theory. Send a review request to an address you control at a large mailbox provider, let it arrive, and open the raw message headers. Most clients expose these somewhere, though the label differs and moves; in Gmail it has long been called Show original. Near the top you will find lines reporting SPF, DKIM and DMARC. Those three lines are worth more than any amount of guessing about wording.

• Send one real request to an address you control and let it land.
• Open the raw headers and read the SPF, DKIM and DMARC results.
• Note the exact domain in the From line, which is often not the one you assumed.
• Only after that has been read should anyone touch the copy.

SPF, DKIM and DMARC: what actually has to line up

The three are separate mechanisms, published as open standards, and they answer different questions. SPF says which servers are allowed to send mail for a domain. DKIM attaches a signature that proves a message came from a domain and was not altered on the way. DMARC ties both back to the address a human sees and tells receivers what to do when the check fails.

Alignment is the part that catches stores out, because you can pass two checks and still fail the one that counts. Say your review app sends from [email protected] but signs the message with its own sending domain. DKIM passes, for the app. SPF passes, for the app. DMARC still fails, because neither authenticated domain matches the yourstore.com the recipient can see, and the message now looks exactly like a well-formed impersonation. The fix is a properly delegated sending domain or subdomain, which every reputable sending platform documents. Follow their instructions and your DNS host's, because the steps differ by both.

• SPF: which servers may send for the domain.
• DKIM: a signature proving the message came from that domain intact.
• DMARC: the policy, and the requirement that an authenticated domain match the visible From.
• Passing SPF and DKIM for someone else's domain does not help yours.

The From line problem that is specific to review apps

Review requests are unusual mail. They are sent by a third-party app, on your behalf, wearing your name, to customers who bought something rather than to a list that subscribed. Every one of those properties makes authentication more fragile than it is for a normal newsletter.

Check what your app and your store actually put in the From line, because defaults vary between apps and change between versions, and the answer is frequently not what the setup screen implied. Three patterns show up repeatedly: sending from the app's own shared domain, which pools your reputation with every other store on it; sending from your address without a delegated sending domain behind it, which is the alignment failure above; and sending from an address that cannot receive replies, which is a deliverability problem in its own right because a customer replying to a bounce teaches nothing good.

• Read the real From domain from a delivered message, not from the app's settings page.
• A shared sending domain pools your reputation with strangers.
• A reply address that bounces costs you both replies and reputation.

Why requests get filtered even when authentication passes

Because authentication only proves who sent the message. Reputation decides whether that sender is welcome, and reputation is mostly built from what recipients do. Review requests are structurally bad at this: they go to every buyer, including the ones who never open anything, and the whole point of the email is asking for work rather than offering anything, so the open rate on a full buyer list is naturally lower than on an engaged marketing segment.

Volume shape makes it worse. A store that sends nothing for six months and then pushes eight thousand requests in one night is producing exactly the pattern a filter is built to catch, and doing it from a domain with no established sending history. Steady beats spiky. Send to recent buyers, suppress people who have ignored several requests, remove hard bounces immediately, and let the volume grow rather than arrive.

• Send to recent buyers rather than to the entire order history.
• Suppress addresses that have ignored two or more requests.
• Remove hard bounces at once; repeatedly mailing dead addresses is a strong negative signal.
• Grow volume gradually instead of restarting at full scale after a quiet period.

The content things that do still matter

Content is the last cause, not the first, but a few items are worth checking once the sender is sound. One link rather than five. No link shortener, which strips away the reassurance of a recognisable domain and shares a reputation with whatever else uses it. Not an image-only email, which has almost no text to read and looks like an attempt to avoid being read. A working unsubscribe or opt-out, even though this is transactional-adjacent mail and you may feel it does not need one.

The large mailbox providers have been tightening what they expect from bulk senders, and authentication and a straightforward way to stop receiving mail are now firmly on that list. The specifics differ by provider and are revised periodically, so look up the current requirements for the providers your customers actually use rather than working from a checklist someone wrote a few years ago. The direction of travel is stable even when the details are not: prove who you are, make leaving easy, and keep complaints low.

A diagnostic order that works

Do these in sequence and stop when the folder changes. Read the headers of one delivered message. Fix authentication and alignment for the domain in the From line. Send a test to addresses at several different providers, because one inbox is one data point and providers disagree. Then look at who you are sending to and how much, and only then at the email itself.

What makes this order worth following is that each step invalidates the ones after it. There is no point tuning copy while DMARC is failing, and no point tuning segments while the mail is arriving from a shared domain you do not control. Most stores that work the list in this order find the answer in the first two steps.

• Read the headers of a delivered message.
• Fix authentication and alignment for the visible From domain.
• Seed-test across several providers, not just your own inbox.
• Then audience and volume, then content.

What this adds up to

A review request that lands in spam is usually a sender problem wearing a copywriting costume. The email is bulk, it goes to people who never subscribed, and it is very often sent from a domain that cannot prove it represents you. Fix the proof first, then the audience, then the words, and the same email you have been rewriting starts arriving.

Delivery is only the first half of the job. The reviews you collect this way still have to be readable in your page HTML and phrased as answers to the questions buyers ask, or they sit unread by the search results and AI answers where people now decide what to buy. Getting them quoted there is the gap BeyondReviews is built to close.

Frequently asked questions