Business emails usually land in spam because the sending domain has not been authenticated with SPF, DKIM and DMARC. These DNS records prove to receiving servers that your mail is genuinely from you, has not been altered, and should be rejected when it fails those checks. Without them, quotes, invoices and replies from a branded address are increasingly treated as untrusted.

Most small business owners discover email deliverability only after something has gone wrong: a quote that was never answered, an invoice the customer insists they never received, or a follow-up that surfaced weeks later in a spam folder. By the time the problem is visible, the trust and the timing have already been lost.

This guide explains why business emails land in spam, what SPF, DKIM and DMARC actually do, and how to set up domain authentication so that mail sent from your branded address reaches the inbox. It is written for South African business owners, not email engineers, so the technical detail stays in service of the practical outcome.

Why this problem is getting worse

For years, free email addresses like Gmail and Yahoo could send mail with relatively little friction. That changed in 2024, when Google and Yahoo introduced stricter sender requirements for bulk senders and, increasingly, for all senders. The direction of travel is clear: receiving providers trust mail less by default, and require explicit proof that the sender is who they claim to be.

This affects every business that sends email from its own domain. A branded address like [email protected] now needs to be properly authenticated, or its mail is more likely to be filtered, delayed or silently dropped. The same applies to mail forwarded from a website contact form, automated notifications, and replies sent from accounting or CRM tools.

The three records that decide whether your mail is trusted

SPF, DKIM and DMARC are three DNS records published on your domain. Together, they answer the three questions a receiving mail server asks when a message arrives:

  1. Is this server actually allowed to send mail for this domain? (SPF)
  2. Has the message been altered in transit? (DKIM)
  3. What should we do if either check fails? (DMARC)

Without these records, the receiving server has no reliable way to confirm the mail is genuinely from you. With them, you give the server a clear set of rules and a way to enforce them.

SPF: who is allowed to send for your domain

SPF (Sender Policy Framework) is a list, published in your DNS, of the mail servers permitted to send email from your domain. When a message arrives, the receiving server checks whether the sending server is on that list.

If you send mail through Google Workspace, Microsoft 365, your web host, an accounting package and a marketing tool, each of those needs to be in your SPF record, or mail sent through them will fail the check.

A simplified SPF record looks like this:

yourbusiness.co.za.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

The most common SPF mistakes are:

  • Leaving out a service that sends mail on your behalf (so its mail fails SPF).
  • Setting the record to -all (hard fail) before all legitimate senders are listed (so genuine mail is rejected).
  • Setting the record to +all or ?all (which effectively disables the check).

DKIM: proving the message was not altered

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message. When the message arrives, the receiving server uses a public key published in your DNS to verify that the message was sent by you and was not altered in transit.

DKIM is usually enabled at your email provider (Google Workspace, Microsoft 365, your host) and then the provider’s public key is added to your DNS. Each provider has its own selector and key, so a domain using multiple sending services can have several DKIM records.

The most common DKIM mistakes are:

  • Never enabling it at the provider at all.
  • Enabling it but not publishing the key in DNS.
  • Losing the record when changing email providers.

DMARC: telling receivers what to do with failures

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and tells receiving servers what to do when a message fails one or both checks. It also lets you receive reports about which mail is passing and failing.

A DMARC record has three main parts: a policy (none, quarantine, or reject), an email address for reports, and a percentage of mail to apply the policy to.

A starting DMARC record looks like this:

_dmarc.yourbusiness.co.za.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected];"

The most important DMARC practice is to start with p=none (monitor only), review the reports to see which legitimate senders are failing, fix those senders, and only then move to p=quarantine and eventually p=reject. Moving straight to p=reject without monitoring will block legitimate mail, including your own.

The DMARC.org overview explains this escalation path in more depth; the principle of monitor-then-enforce is the same everywhere.

How the three work together

The three records are complementary, not interchangeable.

  • Without SPF, you have no list of authorised senders.
  • Without DKIM, you cannot prove individual messages were not tampered with.
  • Without DMARC, receivers have no instruction on what to do with failures, and you get no reports.

Many domains have SPF set up but no DMARC, or DKIM enabled but no SPF. Each gap weakens deliverability independently. A properly authenticated domain has all three, configured for every service that sends mail on its behalf.

Beyond authentication: the other reasons business mail lands in spam

Authentication is the foundation, but it is not the whole picture. Several other factors affect whether a message reaches the inbox.

Sending reputation

Receiving providers track how recipients react to your mail over time. A high rate of spam complaints, bounces, or messages that are never opened damages your reputation and increases filtering.

Content and formatting

Certain content patterns trigger filtering: misleading subject lines, heavy image-to-text ratios, broken links, attachments that look suspicious, and HTML that resembles known phishing templates. Plain, well-structured text with a clear purpose is less likely to be filtered than heavily designed marketing templates.

Volume and pacing

Sending a sudden large burst of mail from a domain that normally sends little can trigger filtering, even with perfect authentication. Volume should ramp gradually, especially for newsletters or marketing campaigns.

Forwarding and auto-reply loops

Mail forwarded to another address, or auto-replies sent to no-reply addresses, can break authentication and create loops. Forwarding in particular can cause SPF to fail at the destination; this is a known limitation that DMARC reports will reveal.

Website contact forms

A contact form that sends mail from the website to your inbox is a common source of deliverability problems. If the form is configured to send “from” the customer’s email address through your domain, SPF and DMARC will often fail. Forms should send from a fixed address on your own domain (for example [email protected]) and put the customer’s address in the reply-to field. This is a detail many contact-form setups get wrong.

How to check whether your domain is properly authenticated

You do not need to be an email engineer to run a basic check. Several free tools will tell you the state of your domain’s authentication.

Tools to use

  • Google Admin Toolbox Check MX: inspects your domain’s MX, SPF and DKIM records.
  • Mail-tester.com: send a test email and receive a deliverability score with specific issues flagged.
  • Your email provider’s diagnostic tools: Google Workspace, Microsoft 365 and reputable hosts all include setup checkers.

Run all three. Each surfaces different problems. The pattern of what they agree on is more reliable than any single tool.

What a clean result looks like

A properly authenticated domain should show:

  • SPF present, with all legitimate senders included and an appropriate ~all or -all ending.
  • DKIM enabled and the public key published.
  • DMARC present, with at least a p=none policy and a reporting address configured.
  • No critical errors from the diagnostic tools.

If any of these are missing or broken, that is the most likely reason mail is landing in spam.

Email deliverability is not only a technical problem. It is also a trust problem, and it interacts with the credibility of the business in the ways covered in the article on what makes a business website look trustworthy.

A business that sends quotes from a free address, or whose branded address is not authenticated, is fighting two battles: the technical one of reaching the inbox, and the perceptual one of looking established. Fixing the technical side removes one of them, and the perceptual benefit of branded, authenticated mail compounds across every quote, invoice and reply.

Setting up authentication: the practical order

If your domain is not yet authenticated, work through these steps in order. Each step removes a category of failure.

  1. List every service that sends mail from your domain. Include your email provider, your website host, your accounting tool, your marketing tool, and anything else that sends as you.
  2. Build the SPF record including all of those services. Publish it in DNS with ~all while you verify nothing breaks.
  3. Enable DKIM at your email provider and publish the public key in DNS.
  4. Publish a DMARC record with p=none and a reporting address. Watch the reports for a few weeks.
  5. Fix any legitimate senders that the reports show failing. Add missing SPF includes, enable missing DKIM keys.
  6. Move DMARC to p=quarantine once the reports are clean.
  7. Move DMARC to p=reject once quarantine has been stable.

This sequence prevents the most common disaster: locking the domain down and accidentally blocking genuine mail. Patience in the monitoring phase saves the cost of lost enquiries later.

When to get help

Most of this work is well within reach of a business owner comfortable with their domain registrar. But several situations justify getting help:

  • You cannot identify all the services sending from your domain.
  • The DMARC reports show failures you cannot trace.
  • You have a legacy setup with forwarding or shared mailboxes that complicates authentication.
  • You have moved email providers and authentication is broken.

In these cases, an hour of expert attention is cheaper than months of silently filtered quotes and invoices.

The conclusion

Business emails land in spam most often because the sending domain has not been authenticated with SPF, DKIM and DMARC. These three records are now the baseline that providers like Gmail and Outlook expect, and their absence is treated as a signal that mail cannot be trusted.

The fix is methodical: list your senders, publish SPF, enable DKIM, monitor DMARC, and enforce it once the reports are clean. The result is that quotes, invoices and replies from your branded address reach the inbox, which is both a technical and a trust outcome.

If your domain is not yet authenticated, or your mail has been landing in spam, the Professional Business Email package on the IDJoy pricing page includes SPF, DKIM and DMARC configuration as part of the setup. Describe your current setup and we will tell you what needs fixing.