Why business email
lands in spam

The receiving server has to decide whether to trust you

When your message reaches the recipient's server, it decides in a fraction of a second whether to deliver it to the inbox, push it to spam, or reject it. That decision is based on several signals. Domain authentication is one of the most important technical foundations because it helps the recipient verify who is authorised to send for your domain. Delivery is also affected by sender reputation, DNS configuration, sending behaviour, spam complaints and other signals.

Sending email in someone else's name is technically trivial — the sender address is just text somebody types. That is why three records in your domain's DNS exist to make the claim verifiable. Without them, or with them wrong, the receiving server has no way to tell you apart from someone impersonating you, so it plays safe at your expense.

SPF

A list of the servers allowed to send mail in your domain's name. The recipient compares the address the message actually came from against that list.

DKIM

A cryptographic signature your server adds to every message. The recipient checks it with a public key published in your DNS, and so knows the message was not altered in transit and was signed by your domain.

DMARC

An instruction to the recipient about what to do when SPF and DKIM fail — nothing, quarantine, or reject — and an address for reports about who is sending in your name.

Where it usually breaks

It is rarely that the records are missing entirely. More often they exist but are quietly wrong.

A new tool nobody added to SPF

You introduced a newsletter tool, an invoicing system or a CRM that sends confirmations. Each sends from its own servers. If they are not in the SPF record, their mail fails the check — and those are usually exactly the messages that most need to arrive.

Two SPF records

A domain may have exactly one SPF record. When a second is added, the list is not extended: the check becomes invalid and typically fails altogether. This happens when two people, a year apart, each add their own.

The ten-lookup limit

The SPF specification allows at most ten DNS lookups when evaluating a record. Every include for an external service costs at least one. With four or five services included, the limit is reached without anyone noticing, and the result is a permanent failure that is reported nowhere.

DKIM that was never switched on

With many providers, DKIM needs to be enabled separately or at least checked to confirm that it is configured correctly. A key has to be published in DNS and signing has to be switched on at the server. If one is done and the other is not, the signature is absent or does not validate.

DMARC set to reject too early

The opposite problem: somebody applies the strictest policy immediately while one legitimate service is not properly set up. Its mail stops arriving, and nobody connects the two, because there is no error message — the mail simply disappears.

The order to do it in

1. List everything that sends in your name. Mail server, newsletter tool, invoicing system, forms on the website, service notifications. This step is the one most often skipped, and without it every later step is guesswork.
2. Build one SPF record that covers everything on the list and stays under ten lookups. If it does not fit, there are ways to reduce the count — but first you have to know the limit has been reached.
3. Enable DKIM on every sender, not only on the main mail server.
4. Publish DMARC in observation mode, with a reporting address. Nothing is discarded in that state, but the data starts arriving.
5. Read the reports for a few weeks. They reveal senders you did not know about — your own and other people's.
6. Tighten the policy gradually, to quarantine and then to reject, once every legitimate sender is in order.

A stricter DMARC policy can help receiving systems reject messages that are not authorised to use your domain. It does not prevent every form of phishing, such as lookalike domains or display-name spoofing.

What you can check yourself, today

Send a message from your business address to any Gmail account. Open it, choose to show the original from the message menu, and look at the SPF, DKIM and DMARC lines at the top. Each says whether it passed.

If all three pass, the basic authentication layer is in place, but other deliverability signals can still cause problems. If one of them fails, you have found a concrete technical issue that needs to be fixed.

When the records are not the cause

Less often, but it happens. These are worth checking too.

• Shared address reputation. On shared hosting, outbound mail may use an IP address shared with other customers. In that case, the reputation of the shared sending address can also affect your deliverability.
• A new domain. A domain with no sending history is treated cautiously at first. That passes on its own if you send properly.
• A missing reverse DNS record for the sending server. Some recipients insist on it.
• Content that looks like bulk mail: a message that is one large image with no text, or links shortened through a service with a poor reputation.
• A rule at the recipient's end. Sometimes the filter is set up at the client, not at you. That is why checking against a neutral account comes first.

Why it is worth fixing

Mail that does not arrive does not announce itself as a fault. There is no error, no report, no trace — only a quote nobody answered and an invoice nobody paid because nobody saw it. That is why the problem often runs for months before anyone connects it to the domain settings.

The amount of work depends on how many systems send for the domain and on the current state of DNS, authentication and sender reputation. After the initial setup, the configuration should be reviewed again when new sending services are introduced.

Sources and further reading

• Google — Email sender guidelines Official requirements and guidance covering email authentication, DNS, TLS, spam rates and other signals that affect delivery to Gmail.
• RFC 7208 — Sender Policy Framework (SPF) The standards-track specification for SPF and domain-based authorisation of sending hosts.
• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures The DKIM specification describing cryptographic message signatures and DNS-published public keys.
• RFC 9989 — Domain-Based Message Authentication, Reporting, and Conformance (DMARC) The current DMARC standards-track specification for domain authentication policy, message handling and reporting.