Why is my email going to spam? The three records that decide it

You send a quote. The client says they never got it. You ask them to check their spam folder, and there it is, between a lottery win and a discount on watches.

This is one of the most common email problems a business has, and it is rarely about your wording. Most of the time, the receiving mail server asked a simple question about your email, did not get a convincing answer, and put it in spam to be safe.

This page explains what that question is, the three records that answer it, and what else can send good email to the wrong folder.

What the receiving server is actually asking

Email was built in an era when anyone could type any “From” address and nobody checked. Even today, nothing in the basic system stops a stranger sending a message that says it is from you.

So receiving services such as Gmail and Outlook ask a question about every message: can this sender prove they are allowed to send as this domain? (Your domain is the part after the @, like yourcompany.com.) If the answer is yes, the message has a good start. If the answer is missing or wrong, it is treated with suspicion, and spam is the usual result.

Google says this plainly in its sender guidelines: messages that are not authenticated might be marked as spam or rejected. Microsoft explains the same idea from its side: authentication means its systems do not automatically junk your email just because it is unauthenticated.

The three records that decide it

The proof is published as three entries in your domain’s DNS. DNS is the public address book for your domain, and anyone can read it, including Gmail.

1. SPF (Sender Policy Framework) is a list of the servers allowed to send email for your domain. Think of it as a guest list kept at the door. The receiving server checks whether the sender is on it.
2. DKIM (DomainKeys Identified Mail) adds a digital signature to each message. It shows the message really came through a system you set up, and was not changed on the way. Think of it as a tamper-proof seal.
3. DMARC (Domain-based Message Authentication, Reporting and Conformance) is your instruction to receivers: what to do with a message that fails the first two, and where to send reports about it. Think of it as the notice that says “if the guest is not on the list, here is what to do, and tell me about it.”

Google asks every sender to Gmail for SPF or DKIM. If you send more than 5,000 messages a day to Gmail accounts, it asks for SPF, DKIM and DMARC together. Most small businesses are far below that number, but the same three records are what receivers across the board look for, and Google’s own advice is to set up all three for every domain you send from.

For a deeper explanation of each one, see SPF, DKIM and DMARC explained.

The most common way a small business gets this wrong

The records are usually set up once, when the email was first connected, and then forgotten. Years later, the business has added a newsletter tool, an invoicing system, a booking form and a CRM. Each of these sends email “from” your domain.

Google’s guidelines say it directly: if your third-party senders are not included in your SPF record, messages from those senders are more likely to be marked as spam. So the newsletter lands in spam while your normal email is fine, and nobody connects the two.

Other patterns we see when we look at small business domains:

• A sender nobody remembered. An old website form or former agency still sends mail as you.
• Two SPF records instead of one. The standard allows one, and having two can cause both to be ignored. This usually happens when two providers were set up months apart.
• No DMARC at all. Receivers have no instruction to follow, and you get no reports about who is using your domain.
• A signature that does not belong to you. A tool signs the email with its own domain, not yours, so the check passes for them but does not line up with the address your client sees.

That last one is called alignment. Google’s guidelines say the domain in the “From” address needs to match the domain that passed the SPF or DKIM check. It is a quiet detail that causes real problems for businesses using several tools.

Authentication is necessary, not magic

An honest point, because this is where many sales pitches go wrong. The standard behind DMARC says in so many words that it does not produce or encourage elevated delivery for authenticated email. Passing the checks gets you through the front door. It does not make a poor message welcome.

Once your records are right, these things can still send email to spam:

• People marking you as spam. Google asks senders to keep their spam rate in its Postmaster Tools below 0.3%. That is about three complaints in every thousand messages.
• Marketing without an easy way out. Google asks that marketing and subscribed messages support one-click unsubscribe, with a visible link in the message.
• A weak connection or broken sending address. Google also expects an encrypted (TLS) connection and valid forward and reverse DNS records for the sending server. Your email provider normally handles these.

How to check where you stand

You can do three things in about ten minutes, without touching any settings:

1. Run your domain through a free checker (ours is linked below). It reads your public records and shows whether SPF and DMARC exist, and whether DMARC is only watching or actually enforcing.
2. Send a test message to a Gmail address you control. Open it, choose “Show original” from the three-dot menu, and look for PASS next to SPF, DKIM and DMARC. A FAIL next to any of them tells you where to start.
3. List every service that sends email as you. Include the newsletter tool, invoicing, the website forms, the CRM and anything an agency set up. Every one of them needs to be accounted for in your records.

A note on checkers: no outside tool can reliably prove a DKIM signature exists, because DKIM records live under names only the sender knows. That is why our checker reports DKIM for information and does not mark you down for it. The test message in step 2 is the more reliable way to see DKIM.

What to ask your email provider or developer

If something fails, you do not need to know the technical fix to ask the right questions:

• Which services send email from our domain, and is each one covered by our SPF record?
• Is DKIM switched on for each of those services, using our domain and not theirs?
• Do we have a DMARC record, and is anyone reading the reports?
• Are there two SPF records, or too many lookups in the one we have?
• Who owns these records now, and what is the plan for the next time we add a tool?

If the answers are vague, that is a sign the records have no owner.

Want us to check yours?

Start with the free domain security checker. It reads your public records in about twenty seconds, runs in your browser and needs no signup.

If something is wrong, or you would rather someone take responsibility for it, our domain and email security service audits every sender, brings the records into order in a safe sequence so legitimate mail keeps flowing, and tests the result with you.

• Email hello@wpfoss.com
• WhatsApp +254 118 271 160
• Tell us what you need

If you want the order of work in full, how to stop email spoofing sets it out step by step.

Sources and further reading

• Email sender guidelines, Gmail Help, Google. Source for the SPF or DKIM requirement for all senders, SPF, DKIM and DMARC for 5,000 or more messages a day, the 0.3% spam rate, one-click unsubscribe, TLS, PTR records, alignment and third-party senders in SPF.
• Email authentication in cloud organizations, Microsoft Learn. Source for what SPF, DKIM and DMARC do and for authentication preventing automatic junking.
• RFC 7489: DMARC, IETF. Source for DMARC not elevating delivery of authenticated email.
• RFC 7208: SPF, IETF. Source for email being forgeable and for SPF as the list of authorised hosts.