Why Are My Business Emails Going to Spam?

There are two different problems here, and they wear the same symptom

If you are asking why are my business emails going to spam, the first useful thing to know is that your domain almost certainly sends mail from two completely separate places, and only one of them is usually broken.

If you want the quickest read on where you stand before you go further, run your domain through the DMARC and SPF checker. It reads the live records, shows the policy actually in force, and warns when more than one SPF or DMARC record is published, which on its own can make receivers ignore both.

Mail a person sends. You open Zoho Mail or Gmail, type a quotation, and press send. That message leaves your mail provider's servers, signed by your mail provider.

Mail the website sends. A visitor fills in your contact form and you get a notification. Somebody places an order and gets a confirmation. Somebody resets a password and gets a one-time code. None of that goes anywhere near your mail provider. It is generated by the website, on the hosting server, usually by the hosting server's own mail program.

These two have different senders, different servers, different failure modes and different fixes. A domain can have perfect authentication for the first and none at all for the second, which is exactly why "but we set up SPF last year" and "our order confirmations go to junk" are both true at the same time.

Almost everything written on this subject is written for a third case that is probably not yours: bulk marketing and cold outreach, where the answer is list hygiene, warm-up and complaint rates. That advice is correct for a company sending fifty thousand campaign emails a week. It is useless when your problem is that one quotation out of three lands in a customer's junk folder.

This page is the other thing. An ordered diagnosis you can run yourself in about twenty minutes with free checkers, the real record syntax for the common setups, where those records actually live in a typical Indian small-business account, and a closing list of the things that are not an authentication problem so you stop paying to fix the wrong one.

Work out which of the two is failing before you change anything

Read the symptom carefully, because it tells you which half to look at.

Send yourself one test from each side. A normal reply from your mailbox to a personal Gmail address, and a real submission through your own contact form to the same personal Gmail address. If only one of the two lands in spam, you have halved the problem in four minutes.

The twenty-minute diagnosis, in order

Run these in sequence. The order matters, because each step rules out a cause the next one would otherwise confuse you about.

1. Read the zone, and read the nameservers first

Start with the DNS checker on your domain. It queries every record type at once, which is what you want here, but read the results in a specific order.

NS first. The nameserver records answer the question everything else depends on: who controls this zone. If the NS records say Cloudflare and you have been editing records in your hosting panel, nothing you did has had any effect. This one line explains most of the "I already added it" cases.

MX second. These say where incoming mail goes. They should point at your mail provider and nowhere else.

TXT third. This is where SPF, DMARC and every verification string live. You are looking for exactly one record beginning v=spf1. If you see two, that is a fault in itself, covered below.

2. Get the verdict on SPF and DMARC

The DMARC and SPF checker reads both records live and tells you the policy actually in force: whether SPF ends in a strict -all, and whether DMARC is enforcing with quarantine or reject or only monitoring with none. A great many business domains have SPF, no DKIM, and p=none, which is a reasonable place to start and a poor place to stay.

Two results here are worth stopping for. If it reports more than one SPF record, fix that before anything else: RFC 7208 is explicit that "a domain name MUST NOT have multiple records that would cause an authorization check to select more than one record", and when more than one is found, "check_host() produces the 'permerror' result". Two SPF records are worse than one wrong one. The same trap exists for DMARC, where RFC 7489 says that if the set "contains multiple records or no records, policy discovery terminates and DMARC processing is not applied to this message". A domain with two DMARC records looks configured and is not protected.

3. Check DKIM at its selector

DKIM is the one most small-business domains are missing, and checking it needs one extra piece of information: the selector. The DKIM checker asks for your domain and that selector, then confirms a public key is actually published at selector._domainkey.yourdomain.

There are two reliable ways to find the selector. The first is your mail provider's own DKIM settings, where it is shown next to the key. The second is better, because it tells you what your mail is really being signed with: open a message you have already sent, view its raw source, find the DKIM-Signature header, and read the s= tag. That is the selector in use.

Common values worth trying if you are guessing: default, google for Google Workspace, selector1 and selector2 for Microsoft 365, k1 for Mailchimp, s1 and s2 for SendGrid, and zoho for Zoho Mail. A record that exists but has an empty p= value means the key was revoked or misconfigured, and you need a fresh one from the provider.

4. Check the addresses themselves

The email validator does a syntax check locally and a live MX lookup on the domain. Run it on two addresses: the one customers reply to, and the one your website sends from.

That second one catches a quiet and common fault. Order confirmations are frequently sent from something like noreply@yourdomain.com which has never existed as a mailbox, so every bounce, every out-of-office and every DMARC complaint about it has been going nowhere for years. An address that cannot receive is a different fault from an address that cannot authenticate, and they get confused constantly. Note the honest limit: no tool can confirm that a specific mailbox exists, because receiving servers deliberately do not reveal it, and anything claiming otherwise is overselling.

5. Read the headers of one message that actually failed

This is the single most decisive check on the page and it costs nothing. Find a message of yours that landed in somebody's spam folder, and look at its raw source. In Gmail that is Show original in the message's menu.

Look for the Authentication-Results header. It will contain spf=, dkim= and dmarc= with a result beside each. Three passes mean your authentication is fine and the cause is somewhere in the final section of this page. Any fail tells you precisely which record to go and fix, and the header usually names the domain it checked, which is the clue you need for the From-address problem below.

If you changed a record in the last day or two and the checkers still show the old value, that is caching rather than a mistake. The DNS propagation checker will show you how far the change has spread before you start editing things that were already correct.

Where the records actually live, and why "I already added it" is usually true

In a typical Indian small-business setup there are three places that will happily let you type a TXT record, and usually only one of them is authoritative.

The registrar's own DNS editor. GoDaddy, BigRock, Hostinger and the rest all include one. It is in force only if the domain is still using that registrar's default nameservers.

The hosting control panel. cPanel has a Zone Editor, and it is in force only if the nameservers point at the hosting company. This is the one that most often turns out to be dead, because a developer moved the domain to Cloudflare at some point and nobody wrote it down.

Cloudflare. Once a domain is on Cloudflare's nameservers, Cloudflare's DNS tab is the zone. Cloudflare's own documentation puts it plainly: "Cloudflare is your primary authoritative DNS provider, which means that, when a visitor tries to access your website or application, DNS resolvers will consider the DNS records that you have on Cloudflare." Records left behind at the registrar or the host are still visible in those panels, still look correct, and are read by nobody.

So the rule is: read the NS records from step one, decide from them which panel is real, and make every change there. If the records you want already exist in a panel that is not authoritative, copying them across is a ten-minute job and it is the whole fix.

One more thing to check while you are in the zone: whether anything else was pointed at your domain. If you moved mail to a new provider and the old MX records are still present at a lower priority number, some senders will keep delivering to the old server. If you are untangling a setup somebody else built, getting your website back from a previous developer walks through the whole asset list in the order that works.

The records themselves, in the syntax that goes in the box

Every record below is a DNS record. Add them in the authoritative panel you identified above, then re-run the checkers.

SPF: exactly one record, listing every server that sends for you

SPF is a single TXT record on the domain itself. The host or name field is usually @, or blank, depending on the panel.

For Zoho Mail, Zoho's documentation gives the value as:

v=spf1 include:zohomail.com -all

For a domain using several Zoho services, Zoho gives v=spf1 include:one.zoho.com -all instead. For Google Workspace, Google gives:

v=spf1 include:_spf.google.com ~all

Now the part that is missing from most instructions. You get one SPF record, not one per provider. If your mail is on Zoho and your website also sends order confirmations from the hosting server, both have to be inside the same record. Zoho states the rule and the merge pattern directly: "There should be only a single SPF record for the domain", and "Every domain should have a single SPF record, including all the servers that the domain uses to send emails", with a merged example of v=spf1 include:abc.com include:def.com include:zohomail.com ~all.

So a small business on Zoho Mail whose website sends from its own hosting server publishes one record something like:

v=spf1 include:zohomail.com ip4:203.0.113.25 ~all

where the IPv4 address is the actual sending address of your hosting server, which your host will tell you. Three details decide whether this works:

• The ending matters. -all means "anything not listed above is forged, reject it". ~all is a softer "treat it as suspicious". Start at ~all while you are still discovering which services send for you, and tighten to -all once nothing legitimate is failing.
• There is a hard lookup limit. RFC 7208 requires implementations to "limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS". The terms that count are include, a, mx, ptr and exists, plus the redirect modifier. ip4, ip6 and all are free. Stack up five providers each with their own nested includes and your SPF record silently stops evaluating, which looks exactly like a record that is not there.
• Order of magnitude, not order of preference. SPF has no priority. It is one list, and every entry is equally authorised.

DKIM: a key published at a selector you choose

DKIM is a TXT record whose name is selector._domainkey, and whose value is the public key your provider generates. You do not write the value by hand: you generate it in the provider's console and paste it.

For Google Workspace, Google says "The default prefix selector is google. If you are using Google Workspace, this is the recommended option", which makes the record name google._domainkey. Google offers 2048-bit and 1024-bit keys and says of the longer one: "If your domain provider supports 2048-bit keys, select this option. Longer keys are more secure than shorter keys." Take the 2048 unless your DNS panel refuses it.

For Zoho Mail, you add a selector in the Admin Console under the domain's DKIM settings, and Zoho generates the TXT value for you. Zoho's instruction for the record name is to "Create a TXT record in your DNS with the title as <selector>._domainkey.<yourdomainname.com>", with a caveat that matters in practice: "Some DNS providers (like GoDaddy, Wix, Squarespace, Namecheap, etc) append the domain name automatically. In such cases, you can just provide <selector>._domainkey as the TXT record name." Getting this wrong produces selector._domainkey.yourdomain.com.yourdomain.com, which is the most common reason a DKIM record that was definitely added cannot be found.

Publish the record first, then press Verify in the provider's console. Doing it the other way round fails and sends people back to support.

DMARC: one record at _dmarc, starting at none

DMARC is a TXT record at the host _dmarc, and it is the record that ties the other two to the address your recipient can actually see. The minimum useful version, which is also the exact value Microsoft's own documentation gives for its hostname _dmarc, is:

v=DMARC1; p=none

Add a reporting address and it starts earning its keep:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The rua tag is defined in RFC 7489 as "Addresses to which aggregate feedback is to be sent". Those reports are XML, they arrive daily from the large providers, and they are the only way to find out which services are sending as your domain before you start blocking them. Use an address that exists.

Two optional tags are worth knowing. sp sets a separate policy for subdomains, which matters because an unprotected subdomain is a convenient thing to forge. pct applies the policy to a percentage of mail, and RFC 7489 gives its "default is 100", so leaving it out means the policy applies to everything.

MX: check the value against your own console, not a blog

Two current details that catch people out.

Google Workspace has moved to a single MX record. Google's documentation says "The Google Workspace MX record value is smtp.google.com" at priority 1, and that "If you started using Google Workspace before 2023, your domain might have different MX record values that start with 'aspmx'. If your email is working, no changes are required."

Zoho's MX hostnames depend on which data centre your account sits in, which is the detail that trips up Indian customers copying a value from a generic guide. Zoho's own documentation says "The TLD for the MX record will vary based on the DC in which your data is hosted in Zoho. Refer to the correct value for your domain from Tools & Configurations section in Admin Console." The same applies to Zoho's SMTP hostnames. Read them out of your own console rather than from a page like this one.

The From address is what gets checked, and form mail usually gets it wrong

This is the failure that makes a correctly configured domain still fail authentication, and it is the one nobody explains.

DMARC does not check the server that sent the message. It checks whether the domain in the visible From address lines up with a domain that SPF or DKIM authenticated. RFC 7489 defines it exactly: "When the domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier Alignment." Microsoft says the same thing in plainer words for its own requirements: "The SPF and/or DKIM record (at least one) must align with (effectively, 'include' or 'match') the domain in the 5322.From address."

Now consider what a typical contact form does. A visitor types their own address into the form, and the script sends you the notification with From: visitor@gmail.com so that you can hit reply. That message leaves your hosting server, which is obviously not authorised to send as gmail.com, and Gmail publishes a strict policy for its own domain. The message fails, and no amount of work on your records will fix it, because your records are not the ones being checked.

The fix is two lines in the form's code. Send the notification from an address at your own domain, and put the visitor's address in Reply-To instead of From. Reply still works, and the message is now making a claim your DNS can back up.

That fix covers the filtering case. If your form's mail never arrives at all, not even in spam, you are on a different fault, and contact form emails going to spam splits the three ways a submission can disappear and tells you which one you are on.

The same logic explains the WordPress case. Left alone, WordPress sends from wordpress@ your site's domain: the documentation describes the default as "wordpress@thesitedomainname". That is an address on your own domain, which sounds better, and it still fails if the hosting server is not in your SPF record and the message carries no DKIM signature at all. Hence the single most effective change you can make to website mail: stop letting the web server send mail directly, and send it through your mail provider's authenticated SMTP instead. Then the message is signed by the same provider that signs the mail you type by hand, and the website inherits all the authentication you already paid for.

Two practical constraints when you wire that up:

• The From address has to belong to the SMTP account. Zoho's SMTP documentation states that "The email address should match the email address/ email aliases of the account, for which the authentication details are provided", and a mismatch produces a "Relaying Disallowed" error. Create a real mailbox or alias for the website to send as, and use that.
• Watch cPanel's email routing. If your MX records point at Zoho or Google but cPanel still has the domain set to Local Mail Exchanger, which cPanel documents as "the server will always accept mail for the domain. The system will deliver mail to the local mailbox", then mail your website sends to an address at your own domain never leaves the server and lands in a local mailbox nobody reads. Setting it to Remote Mail Exchanger means "the server will not accept mail for the domain. The system will send all mail for the domain to the lowest-numbered mail exchanger", which is what you want once your mail lives elsewhere.

One last clue for this category. If Gmail shows the word via next to your sender name, it is telling the recipient about a mismatch: Gmail's help explains that it appears when "The domain it was sent from doesn't match the domain in the 'From:' address." It is not fatal on its own, and it is a strong hint that something in your setup is sending as you without being signed as you.

From none to quarantine to reject, and when to move

The p tag has three values, and RFC 7489 defines what each one asks the receiving server to do:

• p=none is where everybody starts: "The Domain Owner requests no specific action be taken regarding delivery of messages." It blocks nothing. Its entire value is the reports.
• p=quarantine means the owner "wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious", which in practice is the spam folder.
• p=reject means the owner "wishes for Mail Receivers to reject email that fails the DMARC mechanism check". Failed mail does not arrive at all.

The progression is not a schedule, it is a gate. Move up when, and only when, the evidence says nothing legitimate is failing.

1. Publish p=none with a rua address and leave it for a few weeks. Collect the reports.
2. Read them and build a list of everything that sends as your domain. The mail provider. The website. The accounting software that emails invoices. The CRM. The booking plugin. The courier's tracking notifications. There are always more than the owner expects, and that list is the real deliverable of this stage.
3. Authenticate every one of them, by adding it to SPF or by setting up DKIM signing at the service, until the reports show no legitimate sender failing.
4. Move to p=quarantine. Watch the reports again, and watch your own sent mail.
5. Move to p=reject once a period of quarantine has produced no surprises. This is the point at which nobody can send mail as your domain, which is the entire objective.

Do not jump to p=reject the day you add the record. A domain with an incomplete SPF record and a reject policy does not have good deliverability, it has outbound mail that fails silently, and the service you forgot about is always the one that sends your invoices.

For free visibility on the Gmail side, Postmaster Tools provides what Google describes as "detailed information about spam rate, reputation, message authentication, and delivery errors" for mail you send to personal Gmail addresses. It needs a verified domain, and you can add "either the DKIM (d=) domain or the SPF (Return-Path) domain".

What the big three providers actually require

Worth reading closely, because this is where most advice goes wrong: it applies bulk-sender rules to a company sending forty emails a day. Each requirement below is stated as that provider's own current documentation states it.

Gmail. Google's Email sender guidelines ask every sender to "Set up SPF or DKIM email authentication for your sending domains", to "Ensure that sending domains or IPs have valid forward and reverse DNS records", to "Use a TLS connection for transmitting email", to "Keep spam rates reported in Postmaster Tools below 0.3%", and to "Format messages according to the Internet Message Format standard, RFC 5322". Senders of 5,000 or more messages a day to personal Gmail accounts have additional requirements: DMARC, where "Your DMARC enforcement policy can be set to none"; alignment, because "For direct email, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain"; one-click unsubscribe on marketing and subscribed messages; and "a DKIM key of 1024 bits or longer".

Yahoo. Yahoo's sender best practices ask all senders to "Implement SPF or DKIM at a minimum" and to keep the spam rate below 0.3%. Bulk senders are asked to "Implement both SPF & DKIM", to "Publish a valid DMARC policy with at least p=none", to ensure "the domain in the From: header is aligned with either the SPF domain or the DKIM domain", to "Implement a functioning list-unsubscribe header, which supports one-click unsubscribe", and to "Honor unsubscribes within 2 days".

Microsoft. Microsoft's guidance on the 550 5.7.515 error defines a high-volume sender as one that sends "5,000 or more email messages to Microsoft consumer email services" where "All of the messages use the same domain in the 5322.From address". Such senders must "Publish SPF and DKIM records for the domain: Both SPF and DKIM checks must pass", "Publish a DMARC record for the domain" at hostname _dmarc with the value v=DMARC1; p=none, and pass DMARC validation through alignment.

Read that the way it is written. At small-business volume, the mandatory floor is SPF or DKIM, valid reverse DNS and TLS. One-click unsubscribe and the bulk DMARC requirement are not aimed at your quotation emails. But note where the floor is heading, and note that it is already higher than most business domains clear, and note that none of these providers will tell you which of their rules your particular message tripped. That is why the header from step five of the diagnosis is worth more than any amount of inference.

What is not an authentication problem

If steps one to five came back clean and your mail still lands in spam, stop editing DNS. Every item below produces the same symptom and none of them is fixed by a record.

• The recipient's own rule or folder. One person once dragged a message of yours to junk, and their mailbox has been obliging ever since. Ask them to mark one message as not spam and move it to the inbox. This resolves a surprising share of "our emails go to spam at this one client".
• The recipient's company gateway. A Microsoft 365 or corporate filter can quarantine your mail on policy grounds that have nothing to do with you, and the recipient often cannot see the quarantine themselves. Their IT can, and they can allow your domain in about a minute.
• A shared hosting IP address with a history. When your website sends mail directly, it sends from an address shared with every other site on that server, and you inherit their reputation. This is one more argument for routing website mail through your mail provider instead.
• A brand new domain with no sending history. Reputation is earned over time, and a domain that sent nothing for two years and then started sending invoices looks exactly like a domain somebody just bought for a scam. Authentication helps. Patience is the rest of it.
• Forwarding. If a recipient's address auto-forwards to another mailbox, the forwarding server becomes the sender and SPF breaks at that hop by design. DKIM survives forwarding, which is one more reason not to rely on SPF alone.
• The content and the links. A short message that is almost entirely one link, an attachment type that filters dislike, a link to a shortener or to a domain with a bad reputation. Content filtering is real, it is just much less often the cause than the people selling subject-line advice suggest.
• Volume that appeared overnight. Importing two thousand contacts and emailing all of them on a Tuesday is a pattern filters are built to catch, whatever your records say.
• A blocklisted IP or domain. Worth checking, and worth knowing that delisting is a request to somebody else's organisation rather than something you control.

The useful distinction is this: authentication decides whether a receiver can tell the message is genuinely from you. Reputation and content decide whether it wants the message anyway. The records fix the first problem completely and the second one only partly, and knowing which one you have is the difference between a twenty-minute fix and a month of guessing.

While you are in the DNS panel, the other half of a business domain's exposure is the website itself, and the security headers checklist covers what to send there.

Frequently asked questions

Why are my emails going to spam?

For a business domain the usual order is authentication first, then where the mail leaves from, then reputation, then content. A message that cannot be tied to your domain by SPF, DKIM and DMARC is the commonest cause, and it is the one you can check for free in minutes.

Why do emails from my domain go to spam?

Because your domain sends from more than one place, and each place needs its own authentication. Your mailbox provider, your website's contact form and any newsletter or invoicing tool all send as your domain. One of them is usually unauthenticated, as the two-senders section above explains.

Why do good emails go to spam?

Because filters judge who sent a message before they judge what it says. A well-written quotation from a domain with no DKIM, a duplicate SPF record or a shared hosting address can be junked while a poorer message from a trusted sender is not. Authentication and reputation decide this far more often than wording does.

What causes emails to go to the spam folder?

Missing or failing SPF, DKIM or DMARC, a sending server with a poor reputation, a brand new domain with no history, a sudden jump in volume, forwarding that breaks SPF, and the recipient's own rules. The "not an authentication problem" section above lists the ones DNS cannot fix.

How do I stop my emails going to spam?

Send one test to a personal Gmail address, open it with Show original, and read the spf=, dkim= and dmarc= lines. Fix whatever failed, starting with one correct SPF record, a DKIM key at your provider, and a DMARC record at p=none with a reporting address. Then test again, allowing for DNS propagation.

Why are my emails going to spam with Google Workspace, GoDaddy or Namecheap?

The provider name matters less than where your DNS is actually served. Records added in a panel that is not authoritative for the domain do nothing, which is why "I already added it" is so often true. Check the NS records first, as in step one of the diagnosis.

Do Mailchimp emails go to spam?

They can, if the sending domain is not authenticated for the tool. A newsletter service sends as your domain only if you publish the records it gives you, usually a DKIM key and an SPF include. Check what is published with the DMARC and SPF checker and the DKIM checker, and keep to one SPF record.

Is there a test to see if my email is going to spam?

The most reliable test is a real message to a real Gmail address, opened with Show original. Free checkers read the records you publish, but no checker can promise how a particular receiver will file a particular message, and we do not claim a spam score.

Do I need DMARC if I send only a few emails a day?

Google's published sender guidelines require DMARC from senders of 5,000 or more messages a day to personal Gmail accounts, and ask every sender for SPF or DKIM. A DMARC record at p=none is still cheap, and its reports show what else is sending as your domain.

Start here

1. Send two tests to a personal Gmail address: one reply from your mailbox, one through your own contact form. Note which lands in spam.
2. Run the DNS checker and read the NS records first, so you know which panel is the real one.
3. Run the DMARC and SPF checker and the DKIM checker, and write down what is missing rather than fixing it yet.
4. Open one message that failed and read its Authentication-Results header. That tells you which record is actually wrong.
5. Fix in this order: one correct SPF record in the authoritative panel, DKIM at the provider, then _dmarc with p=none and a reporting address. Move website mail onto authenticated SMTP. Tighten the policy later, on evidence.

Most domains in this state need one SPF record merged properly, one DKIM key published, one DMARC record added, and one contact form taught to use Reply-To. That is an afternoon, and it holds.

If you would rather hand it over, this is routine work for us: we measure what is actually failing, fix the records in the panel that is actually in force, move website mail onto authenticated sending, and leave you with the reports so the next person can see it is working. That is website fixes and maintenance.

Either way, start with step one. Knowing which of your two senders is broken removes most of the guesswork before you touch a single record.