Why your quotes land in spam

12 August 2026 · 4 min read

A quote that lands in spam is a lost booking you never find out about. The cause is almost always three DNS records that nobody set up.

1. What is actually going wrong

When you send a quote, the receiving mail server has to answer one question before it decides where to put your message: is this sender really who it claims to be?

Anyone can put your address in the "From" field. Email was designed in an era when that was not a concern, so the protocol itself provides no proof of identity. Everything that followed — SPF, DKIM, DMARC — exists to bolt that proof on afterwards.

If your domain publishes none of it, the receiving server has nothing to check. It is not that you failed the test. There was no test. A message from an unauthenticated domain, containing a price and a link, from a sender the recipient has never corresponded with, is a close match for the profile of a phishing attempt. Spam folder.

This gets worse, not better, over time. Both Google and Microsoft have tightened bulk sender requirements in recent years, and unauthenticated mail that used to scrape into the inbox increasingly does not.

2. SPF, DKIM and DMARC in plain terms

All three are DNS records. You add them once per domain and then they keep working.

• SPF is a list of the servers allowed to send mail as your domain. The receiver checks whether the message came from one of them. Think of it as a guest list.
• DKIM is a cryptographic signature added to each message. The receiver fetches your public key from DNS and verifies the message really came from you and was not altered in transit. Think of it as a wax seal.
• DMARC tells receivers what to do when the first two fail — ignore it, quarantine it, or reject it — and where to send reports. Think of it as the standing instruction.

The order matters. SPF and DKIM establish identity; DMARC is the policy that gives them teeth. A domain with DMARC but no working DKIM is not protected — it is just instructing receivers about a check that never passes.

3. Why "it works when I email myself" proves nothing

This is the single most common reason a broker believes their email is fine when it is not.

When you send to your own domain, or to a colleague on the same domain, the message often never leaves your provider's network. No external server evaluates it. Internal mail also carries reputation signals that a stranger's inbox does not — you are in each other's contacts, you have corresponded for years, nothing looks unusual.

Your customer is a stranger receiving an unsolicited message with a price in it. That is a completely different test, and passing the first one tells you nothing about the second.

Test properly: send to an address on a domain you do not control, ideally one at Gmail and one at Outlook, from an account that has never corresponded with it.

4. The reply-to trap

A lot of transport software sends customer mail from its own domain and sets reply-to to yours. It works, in the sense that replies reach you. It costs you two things.

The first is trust. Your customer is about to hand over a vehicle worth thousands of dollars, and the quote arrived from a company name they have never heard of. Some will assume it is a scam. You will never hear from those people, so this cost is invisible — which is exactly what makes it dangerous.

The second is reputation. Deliverability accrues to the sending domain. If your mail goes out under a shared platform domain, you are inheriting the behaviour of every other customer on that platform, and building nothing of your own.

Sending from your own authenticated domain fixes both. It is more setup — you have to add the DNS records — and it is a one-time cost that keeps paying.

5. How to check where you stand

Before changing anything, find out what your domain currently publishes:

• Send a message to a Gmail address you own from a fresh account. Open it, choose Show original, and look for SPF, DKIM and DMARC. Each says PASS, FAIL, or is missing entirely.
• Missing is the common result, and it is the easiest to fix.
• A FAIL usually means a record exists but does not cover the service you are actually sending from — often after switching provider and leaving the old record in place.

One caution: a domain may only have one SPF record. Two records is a misconfiguration that causes a permanent failure, and it is a frequent outcome of adding a new provider without merging the entry that is already there.

Fixing all three takes roughly five to fifteen minutes, once, per domain. We wrote a step-by-step guide with the exact records for each major host — Google Workspace, Microsoft 365, GoDaddy, Hostinger, Zoho, cPanel and Stackmail. It is free to use and you do not need to be a TruxCRM customer for any of it.