Why Your Business Emails Go to Spam, and the Three Records That Fix It

Your quotation went out this morning. The client never replied. You assume they are busy, or comparing prices, or gone cold.

There is a reasonable chance they never saw it.

Email deliverability is the least investigated problem in Indian small business. Everyone knows some mail goes to spam. Almost nobody checks whether it is their own fault, and in most cases it is, for reasons that take an afternoon to fix.

The three records that decide where your email lands

When Gmail receives a message claiming to be from your domain, it does not take that claim on trust. It checks three DNS records before deciding between the inbox, the spam folder, and outright rejection.

SPF is a list of the mail servers allowed to send email on your behalf. If a message arrives from a server that is not on the list, that is a signal it might be forged.

DKIM is a cryptographic signature added to every message you send. The receiver checks the signature against a public key published in your DNS. If it matches, the message genuinely came from you and was not altered in transit.

DMARC ties the two together and, crucially, tells the receiver what to do when a message fails. Deliver it anyway, send it to spam, or refuse it entirely.

Miss any of the three and you are asking a suspicious system to trust you for no reason.

How to check yours in two minutes

You do not need a tool or an agency for the first look.

Open your domain's DNS records, wherever they live, and look for a TXT record on the root domain starting with v=spf1. Then look for a TXT record at the name underscore dmarc, starting with v=DMARC1. DKIM sits at a selector name, so on Google Workspace it is usually at google dot underscore domainkey.

If you would rather not go digging, our free email deliverability checker reads all three from public DNS in a few seconds and tells you plainly what is missing. It works on any domain, including a supplier's or a competitor's.

The four mistakes we see constantly in India

1. Google Workspace DKIM was never switched on

This is the big one, and it catches serious companies.

Google Workspace does not enable DKIM by default. Somebody with admin access has to generate the key in the admin console and publish it in DNS. It is two screens and ten minutes, and an enormous number of Indian businesses on Workspace have simply never done it, because nothing prompts you and nothing breaks visibly when you skip it.

Their mail goes out unsigned, for years, and nobody notices until deliverability gets bad enough that somebody finally asks.

2. The old host is still in the SPF record

A business starts on cPanel email through a shared hosting provider. Later it moves to Google Workspace. The MX records get updated because otherwise mail stops arriving, so that part gets done properly.

The SPF record does not get updated, because nothing breaks if you forget.

So you end up with a domain whose mail is handled by Google, and whose SPF record authorises the old shared host. Google sends your mail, the receiver checks SPF, and the sending server is not on the list.

We see this pattern constantly, and the business has usually been living with it for a year or more.

3. There are two SPF records

Someone adds a new one for a marketing tool rather than merging it into the existing record. The specification allows exactly one SPF record per domain. With two, most receivers treat the whole thing as an error and SPF fails completely.

This is worse than having no SPF at all, and it happens every time a new tool asks you to "add this record".

The fix is to merge the includes into a single record, not to keep adding.

4. DMARC is set to p equals none, forever

Publishing DMARC feels like the job is done. It is not.

A policy of none means monitor only. Mail that fails authentication is still delivered. Nothing is blocked. Somebody can still send an email that appears to come from your domain, and the receiving server has been explicitly told to let it through.

None is the correct place to start, because it lets you collect reports and find every legitimate sender before you start blocking. It is the wrong place to stay. The point of the exercise is to get to quarantine, and then to reject.

The part that is not about spam

Weak authentication is not only a deliverability problem. It is a fraud problem, and this is the version that costs real money.

If your domain has no enforcing DMARC policy, anyone can send an email that appears to come from your accounts department. Attackers use this against Indian businesses in a specific and effective way: they email your customer, from what looks exactly like your address, with a revised invoice and new bank details.

Your customer pays the wrong account. They believe they paid you. You believe they have not paid. The conversation that follows is unpleasant, and the money is usually gone.

The technical defence against that is DMARC at quarantine or reject, and you either have it or you do not.

Fixing it, in the right order

One. Inventory everything that sends mail as you. Google Workspace or Microsoft, your website contact form, your invoicing software, your email marketing tool, your CRM, your payment gateway notifications. Missing one is how you break your own email when you turn enforcement on.

Two. Write a single SPF record that covers all of them. One record, one all mechanism at the end. Start with tilde all, the softfail.

Three. Turn DKIM on and publish the key. In Google Workspace this is under Apps, Google Workspace, Gmail, Authenticate email. Generate the record, add it to DNS, then come back and click start authentication. People frequently do the first half and forget the second, which leaves the key published and unused.

Four. Publish DMARC at p equals none with a reporting address. Let it run for two to four weeks and read what comes back. The reports will show you senders you had forgotten about.

Five. Move to quarantine, then to reject. Only once the reports are clean. This is the step that actually protects you, and it is the step almost everyone skips.

How long this takes

For a business with one domain and a handful of sending services, the technical work is under an hour. The waiting is the slow part, because you should watch DMARC reports for a few weeks before enforcing.

The honest exception is a company with many sending tools accumulated over years. There, the inventory is the work, and it is worth doing carefully rather than quickly, because turning on enforcement with an incomplete list means your own invoices start bouncing.

If you would rather not do it yourself

We fix this as a fixed-price job, ₹3,500 for one domain, usually same day. SPF corrected, DKIM generated and published, DMARC moved to enforcement, all verified working before we call it done.

Or check yours first with the free deliverability checker and decide from there. Most people who run it find at least one of the three is missing, and quite a few find all three.

Either way, check it. A quotation that never arrives looks exactly like a client who is not interested, and you will never know the difference.