Why Your Business Emails Go to Spam, and How to Fix It

You send a quotation to a client. They never reply. A week later you phone them and they say, politely, that they never got it — and then find it in spam. That conversation costs more than most people realise, and it is almost always fixable in an afternoon.

Email providers do not judge your message by its wording. They judge whether the server that sent it is allowed to send for your domain. Three DNS records decide that: SPF, DKIM and DMARC. If they are missing or wrong, a perfectly ordinary invoice lands in spam while an obvious scam reaches the inbox.

Before you change anything: find out what is actually failing

Guessing wastes days. Get the evidence first, and it takes two minutes.

Send an email from your business address to any Gmail address you control. Open it in Gmail on a desktop browser, click the three dots at the top right of the message, and choose Show original. You will see a small table at the top:

• SPF: PASS — the sending server is authorised for your domain.
• DKIM: PASS — the message carries a valid signature and was not altered.
• DMARC: PASS — your policy is published and the message satisfies it.

Any of those showing FAIL, SOFTFAIL or NEUTRAL tells you exactly where to start. Note which one, because the fix differs completely.

For a second opinion, send a message to the address shown at mail-tester.com and open your score. It checks the same three records plus blacklists and message structure, and explains each deduction in plain language. Aim for 9 or 10 out of 10.

SPF: say which servers may send for you

SPF is one DNS TXT record listing every server allowed to send email using your domain. Miss one and its mail gets marked as forged.

A typical record for a business on cPanel hosting that also uses Google Workspace looks like this:

v=spf1 +mx +a include:_spf.google.com ~all

Three mistakes account for most SPF failures:

• Two SPF records on one domain. This is an instant fail — not a merge. If you added Google Workspace and later added a mail service, you may now have two. There must be exactly one TXT record starting v=spf1, containing every sender.
• Forgetting a sender. Your website's contact form, your CRM, your invoicing tool and your newsletter platform all send as you. Every one needs to be in the record, usually via an include: the provider documents.
• Exceeding ten DNS lookups. Each include: costs a lookup, and nested includes count too. Past ten, SPF returns a permanent error and everything fails. If you have collected several services over the years, count them.

Use ~all (softfail) while you are testing and -all (hardfail) once you are confident the list is complete. Jumping straight to -all with a missing sender will bounce your own invoices.

DKIM: sign your mail so it cannot be tampered with

DKIM adds a cryptographic signature to every message. The receiving server fetches your public key from DNS and confirms the message came from you and arrived unaltered.

On cPanel this is nearly automatic. Open Email Deliverability, find your domain, and cPanel will show whether DKIM and SPF are valid. If DKIM is missing it offers to install it, and if your DNS is managed elsewhere — at your registrar, or on Cloudflare — it gives you the exact record to copy across. That last case is where most people stall: cPanel generates the key, nobody copies it to the real DNS provider, and DKIM silently keeps failing.

If you send through Google Workspace, DKIM is generated separately in the Google Admin console under Apps, Google Workspace, Gmail, Authenticate email. Generating the key is not enough; you must publish the record and then press Start authentication.

DMARC: tell providers what to do with failures

DMARC ties the other two together and tells receivers what to do when a message fails, while reporting who is sending as you.

Start here, with monitoring only:

v=DMARC1; p=none; rua=mailto:you@yourdomain.com; fo=1

Published as a TXT record on _dmarc.yourdomain.com, this changes nothing about delivery. It just starts the daily reports arriving. Read them for two or three weeks and you will discover every service sending as your domain, including ones you had forgotten.

Once the reports show only your own legitimate senders passing, tighten to p=quarantine, and later p=reject. Moving to reject too early blocks your own mail, so do not skip the monitoring phase — that is the whole point of it.

Since 2024, Gmail and Yahoo require a DMARC record from anyone sending bulk mail to their users, along with one-click unsubscribe and a spam-complaint rate kept low. If you send campaigns at all, this is no longer optional.

The causes that are not DNS at all

Sometimes all three records pass and mail still lands in spam. The usual culprits:

• Your website form sends as the visitor. A contact form that sets the From address to whatever the visitor typed is forging that person's domain, and it fails their SPF. Always send as your own address and put the visitor in Reply-To.
• Your site uses PHP mail() instead of SMTP. Unauthenticated mail straight from a web server is treated with suspicion. Send through an authenticated SMTP account on your own domain.
• Shared hosting IP reputation. On shared cPanel hosting you share an IP with strangers. If one of them spams, you inherit some of the damage. Check your IP at mxtoolbox.com against the common blacklists.
• Bulk mail sent through your website server. Newsletters and campaigns should go through a proper SMTP relay with reputation management, not through the same server that hosts your site. Mixing transactional and bulk mail damages both.
• A list you did not build. Purchased lists generate complaints, and complaints are the fastest way to ruin a sending reputation. Nothing in DNS repairs that.

A fifteen-minute check you can run today

1. Send a test to Gmail, open Show original, and note the three results.
2. Send one to mail-tester.com and read the deductions.
3. Confirm you have exactly one SPF record, and that it lists every service that sends as you.
4. Open cPanel, Email Deliverability, and fix anything not showing as valid — copying the DKIM record to your real DNS provider if it lives elsewhere.
5. Publish a DMARC record at p=none and start reading the reports.
6. Check your sending IP against the blacklists at mxtoolbox.com.

Most business email problems we are called in for turn out to be one missing DKIM record or a second stray SPF entry. If you would rather have someone do it, our IT infrastructure and support team handles email deliverability as routine work, and you can reach us through the support page.

Frequently asked questions

Why do my business emails go to spam when personal Gmail works fine?

Gmail addresses are authenticated by Google, so SPF, DKIM and DMARC pass automatically. Your own domain only passes if you have published those records yourself. A new or misconfigured domain with no DKIM signature and no DMARC policy looks, to a receiving server, exactly like someone forging that domain.

How do I check whether SPF, DKIM and DMARC are working?

Send a message to a Gmail address, open it on a desktop browser, click the three dots and choose Show original. The panel at the top shows PASS or FAIL for all three. For more detail, send to the address on mail-tester.com and read the report, which also checks blacklists and message structure.

Can I have two SPF records?

No. Two records containing v=spf1 on the same domain cause an immediate permanent failure rather than merging. Combine every sender into a single record, and keep the total DNS lookups at ten or fewer, counting nested includes.

What DMARC policy should I start with?

Start with p=none and a reporting address. That changes nothing about delivery but tells you which servers are sending as your domain. After two or three weeks of clean reports, move to p=quarantine, then p=reject. Going straight to reject usually blocks your own invoices and forms.

Do I need all three records, or is SPF enough?

All three. SPF alone does not survive forwarding, and it cannot detect a message altered in transit. DKIM handles both of those. DMARC ties them together and tells receiving servers what to do on failure. Since 2024, Gmail and Yahoo require DMARC from bulk senders, so SPF alone is no longer sufficient for anyone sending campaigns.