Why does business email go to spam? SPF, DKIM and DMARC in practice

Business email can look as if it works correctly. The mailbox opens, messages are sent, the contact form submits requests, and the mail client does not show any obvious error.

The problem starts when recipients say:

• “the message went to spam”,
• “I did not receive the email”,
• “Gmail shows a warning”,
• “contact form messages are not arriving”,
• “some people receive the messages and others do not”.

In that situation it is easy to blame the message content or the mail client itself. Sometimes that is part of the problem, but very often the real cause is deeper: domain configuration, DNS, SPF, DKIM, DMARC, or the fact that several different services send email on behalf of the same domain.

That is why email problems can be misleading. A message can be sent successfully from a technical point of view and still be treated as suspicious by the receiving server.

Delivery is more than pressing “send”

When you send an email from a business domain, the receiving server tries to answer a few questions:

• is this server allowed to send email for this domain?
• was the message signed by the sender’s domain?
• does the domain have a policy for handling suspicious messages?
• does the domain or IP address have a good reputation?
• does the message content look like spam or phishing?

SPF, DKIM and DMARC mainly help with the first three questions.

They do not guarantee that every message will land in the primary inbox. Deliverability also depends on reputation, message content, sending history and recipient behavior. But without correct SPF, DKIM and DMARC, you start from a much weaker position.

SPF: who is allowed to send email for the domain

SPF is a DNS record that says which servers are allowed to send email on behalf of a domain.

For example, if you use email at a hosting provider, a newsletter platform and a contact form on your website, each of those services may send messages as your domain.

This is where problems often begin.

Common SPF mistakes:

• the domain has no SPF record,
• the domain has multiple SPF records instead of one,
• SPF includes only one service and omits other legitimate sending sources,
• the record was assembled by copy-pasting snippets from several guides,
• the configuration is too permissive and allows almost anyone to send mail.

In practice, SPF needs to be built deliberately. One record should include all places that really send email for your domain.

If you send mail from hosting, an invoicing system, a CRM, an online store and a contact form, setting SPF only for the mailbox provider is not enough.

DKIM: a signature for the message

DKIM works differently from SPF. Instead of listing which servers may send mail, DKIM cryptographically signs the message.

In simplified terms:

• the sending server adds a signature to the message,
• the public key is published in DNS,
• the receiving server checks whether the signature matches.

This helps the receiver verify that the message was actually signed by the domain that claims to send it.

Typical DKIM problems:

• DKIM is not enabled at the email provider,
• the DNS record with the DKIM key was not added,
• the wrong selector is used,
• the DNS record was truncated or pasted incorrectly,
• the domain sends mail through several services, but DKIM works for only one of them.

DKIM is especially important when messages pass through intermediate systems. SPF may fail in some forwarding scenarios, while a valid DKIM signature can still help confirm that the message is authentic.

DMARC: what to do when something does not match

DMARC uses SPF and DKIM results, but adds a domain policy.

It tells receiving servers, roughly:

• what to do if a message fails authentication,
• whether to only observe the problem,
• whether to mark messages as suspicious,
• whether to reject messages impersonating the domain,
• where to send reports.

At the beginning, it is often reasonable to use DMARC in monitoring mode. This helps you see who is actually sending email from your domain before making the policy stricter.

Setting a strict DMARC policy too early can cause legitimate messages to stop arriving, especially if all systems sending mail from the domain have not been checked first.

One email provider is not the whole story

In small companies, email often looks like just one mailbox at one provider. In practice, messages may be sent from many places.

Examples:

• the business mailbox at a hosting provider,
• the contact form on the website,
• an online store,
• an invoicing system,
• a CRM,
• a newsletter tool,
• automatic notifications from an application,
• an external helpdesk,
• a VPS that sends alerts or reports.

Each of these services may require separate SPF or DKIM configuration. If one of them is missing, some messages may go to spam even though regular mailbox email works correctly.

This explains situations where manually sent emails are delivered, but contact form messages are not. Or the other way around: the newsletter works, but replies from the business mailbox go to spam.

What not to change blindly

Email issues often tempt people into quick fixes. Unfortunately, those fixes can make the situation worse.

It is usually not a good idea to:

• add a second SPF record because “one service told me to add theirs”,
• copy an SPF record from a random tutorial,
• set a strict DMARC policy without checking who sends email from the domain,
• ignore DKIM because “SPF already exists”,
• assume that if email leaves the mailbox, the configuration is correct,
• test delivery only to your own mailbox.

A very common mistake is having multiple SPF records for one domain. SPF should be a single record. If different services require their own mechanisms, they need to be combined into one valid SPF record.

What practical diagnosis looks like

With this kind of problem, I would not start by guessing. It is better to collect facts first.

I would check:

• the domain’s DNS records,
• whether SPF exists and is valid,
• whether DKIM is enabled and the key is visible in DNS,
• whether the domain has DMARC,
• which services send email on behalf of the domain,
• headers of a sample message that went to spam,
• whether the problem affects all recipients or only some of them,
• whether it affects mailbox email, a contact form, a newsletter or an application.

Message headers are very useful because they show what happened along the way. They can contain SPF, DKIM and DMARC results and the servers through which the message passed.

Without that, it is easy to fix the wrong part of the setup.

Example scenario

Assume a company uses the domain example.com.

Email is hosted at a provider. The website also sends contact form messages, and invoices are sent from a separate system.

DNS contains SPF only for the hosting provider. Normal emails sent from the business mailbox pass authentication. But the contact form and invoicing system send email from different servers that are not covered by SPF.

The result:

• some messages look fine,
• some messages go to spam,
• the domain owner feels that the problem is random.

It does not have to be random. It may simply be a consequence of different sending sources having different configurations.

SPF, DKIM and DMARC are not magic

It is also worth being clear about what these mechanisms do not do.

SPF, DKIM and DMARC will not automatically make every message land in the primary inbox. They will not repair a poor reputation after mass mailing. They will not help if the message content looks suspicious. They do not replace proper mail server configuration.

But they are a foundation.

If a business domain does not have proper email authentication configured, receiving servers have fewer reasons to trust messages from that domain.

Summary

If business email goes to spam, it is not worth starting with random changes.

First, you need to establish:

• where messages are actually sent from,
• which messages have a problem,
• what SPF, DKIM and DMARC results look like,
• whether DNS matches the real sending setup,
• whether the domain and servers have a reasonable reputation.

Only then does it make sense to change records and test the result.

If your business email goes to spam or contact form messages are not arriving, I can check your domain, DNS, SPF, DKIM and DMARC configuration and point out what needs to be fixed.

I described this kind of support on the Business Email, DNS and Deliverability service page.