Why Your Business Email Lands in Spam, and the Three Records That Fix It

You sent the quotation on Tuesday. On Friday the client says they never received it. They look, and there it is in spam, unopened, next to an offer for a loan.

Nothing was wrong with your message. The problem is that the receiving mail server could not prove the message really came from you, so it treated your quotation the way it treats a stranger pretending to be you.

Three short lines of text in your domain's settings decide this. They are called SPF, DKIM and DMARC, they are free, and they take one sitting plus a few days of waiting. This guide explains what each one proves, what Google now requires, and exactly how to set them up if your email runs on Google Workspace. Every rule quoted here is from Google's own sender documentation, read on 12 November 2026.

The Question a Receiving Server Is Actually Asking

Anybody in the world can type your email address into the From field of a message. Nothing stops them. That is how a supplier receives a convincing invoice "from" your finance team with somebody else's bank details in it, and it is why mail providers became strict.

So when a message arrives claiming to be from yourbusiness.co.ke, the receiving server asks three questions in order:

1. Is the server that sent this allowed to send for that domain? That is SPF.
2. Does the message carry a valid signature from that domain, unchanged in transit? That is DKIM.
3. If the answer to either was no, what does the domain owner want me to do? That is DMARC.

If your domain never answers, the server has to guess, and a guess about an unauthenticated message that mentions money is rarely generous. Google is explicit: messages that are not authenticated with these methods might be marked as spam or rejected outright with a 5.7.26 error. (Gmail: Email sender guidelines)

The Three Records, Side by Side

Notice where they live. Two of the three are not in Google's admin console at all; they are at whoever manages your domain's DNS. Google says so itself for both SPF and DMARC. That split is the reason so many setups are half-finished: the person with the Workspace login and the person with the domain login are different people.

What Google Now Requires, and of Whom

Since 2024 Gmail has had published minimum requirements for anybody sending to personal Gmail accounts. The honest summary for a Kenyan SME:

• Every sender needs SPF or DKIM. This is the one that applies to you, whether you send three messages a day or three hundred. Our advice, and Google's recommendation, is to set up all three anyway.
• Bulk senders need SPF, DKIM and DMARC. Google defines bulk as close to 5,000 messages or more to personal Gmail accounts in a 24-hour period, counted across your primary domain. (Gmail: sender guidelines FAQ)
• Bulk marketing mail needs one-click unsubscribe using the List-Unsubscribe headers, not just a link in the footer. Google says transactional messages, such as a receipt, are excluded from that requirement.
• Spam complaints have a hard line. Google asks senders to keep the user-reported spam rate below 0.1% and says it must never reach 0.3% or higher.
• Encryption is required. A TLS connection for transmitting email was added to the requirements in December 2023.

Step 0: Get Your MX Records Right First

Before authentication, make sure delivery itself is clean. MX records decide where your incoming mail goes. Google Workspace now uses a single MX value:

Type:     MX
Name:     @   (or blank)
Priority: 1
Value:    smtp.google.com

Google's instructions are to remove any other MX records, because old or incorrect ones stop email working correctly, and to allow up to 72 hours for the change to be recognised. If you started on Workspace before 2023 you may still have the older aspmx records; Google says those are still supported, so if mail is working there is nothing to change. (Google: Set up MX records)

The common Kenyan version of this problem: a business moves from cPanel email to Workspace, the MX records are pointed at Google, but the old mailboxes on the web host are never switched off. Half the mail arrives in Gmail, half sits in a webmail inbox nobody opens.

Step 1: SPF, the Guest List

For a domain whose mail is sent only through Google Workspace, the whole record is:

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

Add it as a TXT record on your domain, at the root (@). One SPF record per domain, never two.

The part people get wrong is the guest list. Google tells you to identify all your email senders first, and specifically names web servers, on-premise mail servers, your host's mail servers, outbound gateways, services that send automatic email such as "Contact us" forms, and any third-party provider that sends for your domain.

In practice, for a Kenyan business, that list usually includes:

• Your website's contact form, if it sends from your domain
• Your invoicing or accounting system
• A newsletter platform
• An SMS or bulk email provider that sends on your behalf
• Any booking or e-commerce plugin that emails customers

This site is its own example. Our forms do not use the web server's mail function; they send through a mail provider's API from a Cloudflare Worker. That provider is a third-party sender for our domain, so it has to be authorised in DNS exactly like Google is, or our own enquiry notifications would be the ones landing in spam.

Step 2: DKIM, the Signature

DKIM is the one that is genuinely set up inside Google Workspace. You generate a key pair; the private half stays with Google and signs every outgoing message, and you publish the public half in DNS so receiving servers can check the signature.

The gotcha that catches every new setup: Google says that after you turn on Gmail for your organisation, you must wait 24 to 72 hours before you can get your DKIM key, and trying earlier returns an error saying the DKIM record was not created. It is the one part of a Workspace setup that cannot be finished on the first day. (Google: Set up DKIM)

On key length, Google is specific: sending to personal Gmail accounts requires a DKIM key of at least 1024 bits, and 2048 is recommended.

Step 3: DMARC, the Instruction

DMARC is a single TXT record named _dmarc on your domain. It tells receiving servers what to do with mail from your domain that fails SPF and DKIM, and it asks them to send you reports. Google's example record looks like this:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

Do not start there. Google's own recommendation is to set the policy to none when you begin, so you can read the reports before anything is blocked:

v=DMARC1; p=none; rua=mailto:dmarc@yourbusiness.co.ke

Then three rules from Google's instructions:

• SPF or DKIM must be working first. Allow 48 hours after setting them up before you add DMARC. Adding DMARC first will probably cause delivery problems.
• Send the reports somewhere nobody minds. Google warns that the volume varies and large organisations can receive hundreds or thousands of reports a day, and recommends a dedicated mailbox or group.
• Authorise your other senders before tightening. If a third-party service sends as you and is not authenticated, moving to p=reject is what finally stops its mail.

Read the reports for a few weeks, fix whatever shows up, then move to p=quarantine and eventually p=reject. That last step is the one that actually stops somebody invoicing your clients in your name.

Five Things That Quietly Undo All of It

1. Two SPF records. A domain may publish only one. A second one, often added years apart by two different people, breaks the check for everybody.
2. Auto-forwarding to a personal Gmail. The habit of pointing info@ at a gmail.com address breaks SPF on the forwarded hop, and the DKIM signature becomes the only thing keeping those messages out of spam.
3. A contact form sending as a customer. If your website puts the visitor's address in the From field, your own enquiry notifications fail authentication. Put your address in From and the visitor's in Reply-To.
4. A new tool nobody told you about. Somebody signs up for a mailing platform, sends 400 messages as your domain, and your reports light up. This is what the rua address is for.
5. DNS edited at the wrong place. If your nameservers point somewhere other than where you are editing records, you can add perfect records to a zone nobody reads. Our guide on how DNS works covers that.

How to Check What You Have Now

Before changing anything, find out what your domain currently publishes. Ask your IT person, your developer or whoever holds the domain for three things: your SPF record, whether DKIM is turned on in the admin console, and whether a _dmarc record exists.

While you are looking at the plumbing, two of our free tools cover the next layer out, and neither needs a signup:

• The SSL checker confirms the certificate, redirects and mixed content on the website that your email addresses point people to.
• The security headers checker grades the protections your website sends to visitors' browsers, which is the website half of the same trust problem.

If the whole thing sounds like a job for somebody else, that is reasonable. It is DNS, it is slow to verify, and a mistake is invisible until a customer tells you they never got your mail.

Frequently Asked Questions

What are SPF, DKIM and DMARC in simple terms?

They are three short lines of text in your domain's DNS settings. SPF lists the servers allowed to send mail using your domain name. DKIM adds an invisible signature to each message that proves it was not altered on the way. DMARC tells receiving servers what to do with a message that fails those checks, and sends you reports about it.

Do the Gmail sender rules apply to a small Kenyan business?

Partly. Google requires every sender to have SPF or DKIM. The stricter rules, which add DMARC and one-click unsubscribe, apply to bulk senders, which Google defines as close to 5,000 messages or more to personal Gmail accounts in 24 hours. Most Kenyan SMEs are well under that, but unauthenticated mail from any sender can still be marked as spam or rejected.

What DMARC policy should I start with?

Start with p=none and a reporting address. Google recommends setting the policy to none when you begin, so nothing is blocked while you read the reports and find senders you forgot. Move to quarantine, then reject, once the reports show only your own services sending as you.

How long do these changes take to work?

DNS changes can take up to 72 hours to be recognised, and Google asks you to wait 24 to 72 hours after turning on Gmail before generating a DKIM key, and 48 hours after setting up SPF and DKIM before adding DMARC. A careful setup is therefore a few days of waiting, not an afternoon.

Why does my website's contact form email go to spam?

Usually because it sends from your domain through your web host or an email service that is not listed in your SPF record. Google specifically says to include contact-us forms and any third-party service that sends mail for your domain. Either add that sender to SPF and sign it with DKIM, or have the form send from an address on a domain that is authorised.