Why Your Business Email Lands in Spam: SPF, DKIM, DMARC

If a quote or an invoice you sent landed in a customer’s spam folder, do not start by rewriting the email. Start by getting Gmail to tell you what is wrong, because it publishes the answer in two places.

The first is the bounce message, the automatic reply that comes back when mail does not arrive. Gmail puts a numbered code in it, and each code names one missing thing. 4.7.27 is SPF. 4.7.30 is DKIM. 4.7.31 is a missing DMARC record. 4.7.32 means the From: address your customer reads does not match the domain that was actually checked.

The second is the Compliance status dashboard in Google Postmaster Tools, a Google service that reports on the mail your domain sends to Gmail. It lists Google’s requirements one per row and marks each row Compliant, Needs work, or No data found. Signing in needs a Google Account or a Google Workspace account, which you already have.

Then fix what those two name. Both of them report per requirement rather than in general, so they will name the specific thing that failed. SPF, DKIM and DMARC are three separate settings at your domain’s DNS, the address book that tells the internet where your domain’s services live, and a bounce code points at one of them rather than all three.

One warning before you test anything. If you check by emailing a colleague, you have proved nothing, and the reason is in the next section.

Google’s help pages were checked on 4 September 2026. Four of the pages this guide draws on, Set up SPF, Troubleshoot SPF issues, Set up DKIM and Set up DMARC, carry their own date and read “Last updated 2026-08-26 UTC”. This guide covers Google Workspace and Gmail only, and not Microsoft or Outlook.

Why mailing a colleague proves nothing

Google’s sender rules do not apply to mail between Google Workspace accounts. They apply to mail you send to personal Gmail addresses, which Google defines as an account “that ends in @gmail.com or @googlemail.com”.

Google states both halves plainly. On the one hand: “The Email sender guidelines don’t apply to messages sent to Google Workspace accounts. Sender requirements and Google enforcement apply only when sending email to personal Gmail accounts.” On the other: “All senders, including Google Workspace users, must meet the requirements in our Email sender guidelines when sending messages to personal Gmail accounts. The requirements don’t apply to Google Workspace inbound and intra-domain messages.”

Intra-domain means mail from your domain to your own domain. So the two tests people reach for first, mailing a colleague at the same company and mailing a friend at another business that also runs Workspace, both sit outside the rulebook you are trying to test.

Send your test to a personal Gmail address instead. That is the only kind of recipient these requirements govern.

Read the bounce code first, because Gmail names the record

When Gmail refuses a message it says why. In Google’s words: “when messages are rejected, we send a rejection code and a reason for the rejection. You can also see this information in Postmaster Tools.”

The code arrives inside the bounce message, usually a few lines down, in a paragraph that looks like machine output. Find it. It turns a vague problem into a named one.

Read the code as two halves. The three-digit number comes first, then a dotted code like 4.7.27. It is the dotted code that names the requirement, and Google’s own wording tracks its first digit: codes starting 4 are the ones Google describes as “rate limited”, and codes starting 5 are the ones it describes as “blocked”.

The dotted codes mostly pair up, one rate-limited and one blocked for the same problem, but they do not all pair neatly. Two do not: PTR is 4.7.23 and 5.7.25, and DMARC is 4.7.31 or 4.7.40 rate-limited against 5.7.40 blocked. So look the code up rather than assuming the other half of the pair from the one you have.

Read the sentence Gmail sends you, not only the number. Google reuses several of these dotted codes for unrelated problems, and the three-digit number and the wording are what separate them. 5.7.40 is a missing DMARC record as 550, but as 504 it is an authentication problem with your mail client and has nothing to do with DNS. 5.7.26 covers three different situations. Every entry Google publishes carries a sentence explaining it, and that sentence is the reliable part.

4.7.32 is the one that catches people who have already done the work. Alignment means the domain your customer sees in the From: line has to match the domain that SPF or DKIM actually authenticated. Add a newsletter tool or an invoicing app to your SPF record and the mail can pass SPF while still failing alignment, because the service sent it under its own domain. You did the setup; it still fails.

Two other codes turn up often enough to name. 5.7.26 is the one Google uses for authentication trouble, and its first published form is a message blocked “because the sender is unauthenticated”. 4.7.28 means you sent too much too fast rather than that anything is misconfigured.

The dashboard that checks all eight requirements

If you have no bounce message to read, or you want to see everything at once, this is the place to look. Signing up is a short job; the data behind it takes longer to arrive, which the caveats below cover.

Google Postmaster Tools has a Compliance status dashboard that lists the sender requirements one per row and tells you which ones you fail. Google describes it as available “to all email senders, including bulk senders, that send messages to personal Gmail accounts”, so it is not a big-sender feature.

Eight rows, and Google splits them by who they apply to.

Each row reads one of three ways. Compliant means, in Google’s words, “Your email system is correctly set up to meet the requirement… No action is needed.” Needs work means you have something to fix, and Google warns that after you fix it “it can take up to 7 days for changes to be reflected in the dashboard”. No data found means Google did not have enough of your mail to judge.

To use it you add your domain in Postmaster Tools and prove you own it with a DNS record, the same way you would verify a domain anywhere else. You need a Google Account or a Google Workspace account to sign in.

Two honest caveats Google prints beside it

A small sender’s dashboard will be empty, and that is by design. Google’s wording: “If your email traffic volume to personal Gmail accounts is too low, Postmaster Tools dashboards might not include data for your sending domain. This is to protect the privacy of Gmail users.” If you send twenty invoices a week, expect No data found on most rows. It is not a fault and there is nothing to fix.

A spam rate that looks too good can mean the opposite of what you think. Google is direct about this. “If Gmail automatically sends a significant number of your messages to spam, the rate shown in the dashboard might seem low, because recipients get fewer of your messages in their Inbox.” And: “Although we recommend you keep spam rates as low as possible, if your spam rate is extremely low, something might be impacting the accuracy of the data.”

Read together, a suspiciously clean spam rate can mean Gmail is filtering your mail before anyone gets the chance to complain about it. That is exactly the situation this article is about.

One more thing before you act on what you see. For the DNS row, Google says your status “reflects the settings observed when those emails are received, not your current configuration”. So the dashboard is telling you about the mail it has already handled, not about the record you fixed an hour ago.

What Google actually requires, and of whom

There are two lists, and which one you are on is decided by how much you send to personal Gmail addresses in a day.

Every sender to Gmail, since 1 February 2024, has to set up “SPF or DKIM email authentication”, have valid forward and reverse DNS records, use a TLS connection, keep the spam rate below 0.3%, format messages to RFC 5322, and not impersonate Gmail From: headers. Note the “or” in the first one. DMARC is not on this list at all.

Senders of more than 5,000 messages a day to Gmail accounts have to set up “SPF and DKIM” together, add DMARC, and keep the spam rate below 0.30%. Google adds that for DMARC, “Your DMARC enforcement policy can be set to none”, which is the setting that reports on your mail without changing what happens to it.

So if you are under that threshold, Google requires one of SPF or DKIM, and DMARC is a recommendation rather than a rule. Our advice to our own clients is still to set up all three, because SPF alone is fragile and DMARC is the only one of them that ties the check to the From: address a customer actually reads. But that is our advice, not Google’s requirement, and it is worth knowing which is which.

On the spam rate, Google gives two figures on the same page and they are not in conflict. The requirement rows say below 0.3%. The monitoring section says “Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher”. Read 0.30% as the line you must not cross and 0.10% as the level to run at.

The 5,000-message line is a one-way door

This is the part most likely to catch a growing business, and it is the reason the two lists above are not simply “small” and “large”.

Cross the bulk-sender threshold once, ever, and you are a bulk sender permanently. Google’s wording leaves no room in it: “Senders who meet the above criteria at least once are permanently considered bulk senders.” And, answering the obvious follow-up question directly: “Bulk sender status doesn’t have an expiration date. Email senders that have been classified as bulk senders are permanently classified as such. Changes in email sending practices will not affect permanent bulk sender status once it’s assigned.”

Three things follow from that, and they matter in this order.

First, the threshold is lower than it sounds and it is counted across your whole domain. Google defines a bulk sender as “any email sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period”. Note “close to”. Then: “Messages sent from the same primary domain count toward the 5,000 limit.” A primary domain is your main one, such as yourcompany.com.sg. Anything sending under a subdomain, a name in front of it like news.yourcompany.com.sg, adds to the same total. Google’s own example is a business sending 2,500 messages from one and 2,500 from the other, and its verdict is that “You’re considered a bulk sender because all 5,000 messages were sent from the same primary domain”, which in Google’s example is the parent domain of both.

Second, one campaign is enough. A Chinese New Year greeting to a customer list. A product launch. The email telling every customer you have moved premises. Send one of those to enough personal Gmail addresses in a day and the status attaches, and no amount of quiet sending afterwards removes it.

Third, from that day the requirement list changes and stays changed. SPF or DKIM becomes SPF and DKIM. DMARC stops being optional. One-click unsubscribe and the 48-hour rule apply to your marketing mail. None of it reverts when your volume drops back.

The practical advice is short. If a big send is anywhere in your plans, set up all three records before it rather than after, because the alternative is discovering the new requirements from a bounce message during the campaign you cared about.

Two related definitions round this out. Google treats a “new domain” as one that “hasn’t sent more than 5,000 emails a day to personal Gmail accounts since January 1, 2024”, and says enforcement on new domains runs “on an accelerated timetable”. And Google has said more enforcement is coming: “Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic. Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections.”

Failing one requirement is not like failing another

Google publishes a table of what happens when you miss each requirement, and it splits into two very different outcomes. Read it before you decide what to fix first.

The top five are the ones Google says draw failure codes or spam foldering. For three of the bottom four, “Delivery support or mitigations unavailable” means Google will not help you when something else goes wrong. That is the difference between a fault and a lost safety net.

The spam rate is the exception, and it is worth being clear about. Google puts it in the second group of that table, but says elsewhere on the same page that it hurts delivery too: “The user-reported spam rate’s impact on delivery is graduated, and rates of 0.3% or higher have an even greater negative impact on email inbox delivery.” Its sender guidelines put it more plainly still: “Maintaining a high spam rate leads to increased spam classification.” So a high spam rate costs you both things at once.

What this is useful for is deciding what to look at on a Tuesday afternoon. A missing DMARC record, on its own, is not in the group Google says draws failure codes or spam foldering. Read the bounce code first, and if the Compliance status dashboard shows a spam-rate problem, treat that as its own cause rather than as paperwork.

The three records, and where to set them up

We have written the setup out in full, in order, as a free three-page PDF with every requirement sourced to Google’s own documentation. It is called Business email that lands in the inbox, it covers SPF, DKIM and DMARC for Google Workspace in the order to set them up, and it sits with our other guides on the resources page. No email address, no form.

What each record does, in one line each:

• SPF is a list of the services allowed to send mail in your name. For a domain that sends only through Google Workspace, Google’s recommended record is v=spf1 include:_spf.google.com ~all.
• DKIM is a tamper-evident seal on each message. It is the only one of the three you set up inside the Google Admin console, and it needs a super administrator account, the most powerful kind of Google Workspace account.
• DMARC is a standing instruction to receiving servers about what to do when the first two fail, plus a report telling you what is being sent in your name. It goes on the host _dmarc.yourdomain, and Google recommends starting with the policy set to none.

Four things that are easy to get wrong, all of them covered in the guide:

• You can only have one SPF record. Adding a second, rather than adding to the first, is a common way to break a working setup.
• SPF has a limit of ten DNS lookups. Google’s page states that “The SPF specification allows for a maximum of 10 DNS lookups”, and a record with several third-party services in it can exceed that. When it does, the errors can report that you have no SPF record at all, even though you do.
• SPF and DMARC are not in the Admin console. Google says so outright on both pages. They are TXT records at whoever manages your domain’s DNS, which is often your registrar or your web host rather than Google.
• You cannot check DKIM by emailing yourself. Google’s setup page says this in as many words. Send to a Gmail or Workspace recipient and read the authentication results in the message header instead.

One Google requirement here is a floor rather than a suggestion: “Sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer.” Google’s recommendation above that floor carries a condition: “we recommend using a 2048-bit key if your domain provider supports this”. The Admin console offers both lengths and tells you to pick 2048 if your provider supports it.

If you are moving mail onto Google Workspace from a web hosting account, do this at the same time rather than afterwards. Our guide to which tool moves hosting email into Google Workspace covers the move itself, and the records have to be rebuilt on the other side of it either way.

Four ways to damage your own domain that have nothing to do with DNS

All four are on Google’s own pages, and none of them involves a record.

Your own staff marking internal mail as spam. Google: “Don’t mark internal messages as spam. This can negatively affect your domain’s reputation, and future messages might be marked as spam.” If your team clears the newsletter out of their inbox with the spam button rather than by deleting it, that is a real cost.

Running phishing drills from your own domain. Google: “Don’t send test phishing messages or test campaigns from your domain. Your domain’s reputation might be negatively affected, and your domain could be added to internet blocklists.” Staff security training is a good idea. Sending the fake phishing mail from the domain you invoice customers on is not.

Reading your open rate as a delivery report. Say your mailing tool shows a healthy open rate and you conclude the mail is arriving. It does not follow, and Google is unusually direct about why: “Google doesn’t track open rates. Google can’t verify the accuracy of open rates reported by third parties. Low open rates aren’t necessarily an accurate indicator of deliverability or spam classification issues.” An open rate is measured by your sending tool, not by Gmail, so it cannot tell you what Gmail did with a message. The Compliance status dashboard can.

Trying to get onto an allowlist. Google: “Google and Gmail don’t accept allowlist requests from email providers. We can’t guarantee messages sent by email providers will pass Gmail’s spam filters.” So a supplier who offers to put your domain on Gmail’s good list is selling access Google says it does not grant.

One more that is not a Google rule but decides who gets blamed. Addresses like info@ and sales@ are often forwarders or shared mailboxes rather than real accounts, so mail that appears to come from them may leave through something you have not authorised. Our piece on shared inboxes and Gmail delegation covers how those are put together in Workspace.

Common questions

Do I need all three records? Google requires SPF or DKIM from every sender, and adds DMARC only above 5,000 messages a day to Gmail accounts. So strictly, a business under that threshold needs one. We recommend all three anyway, and the section above on the one-way door is the reason.

Will adding DMARC stop my mail going to spam? On its own, no. Google’s own enforcement table puts a missing DMARC record under “Delivery support or mitigations unavailable” rather than under the failures that bounce mail or send it to spam. Authentication and alignment are the ones to check first.

I sent one big mailer last year. Does that matter? If it was close to 5,000 messages or more to personal Gmail addresses in 24 hours, yes, permanently. Google’s FAQ says bulk sender status “doesn’t have an expiration date” and that changing your sending practices “will not affect permanent bulk sender status once it’s assigned.”

My Postmaster Tools dashboard is empty. What did I do wrong? Probably nothing. Google withholds data when volume to personal Gmail accounts is too low, and says it does so “to protect the privacy of Gmail users”. Small senders should expect this.

Can I ask Google to allowlist our domain? No. Google says it doesn’t accept allowlist requests from email providers and cannot guarantee that mail sent through them passes Gmail’s filters.

How long until a change takes effect? Google says Compliance status data is “typically… updated within 24 hours but can take longer”, and that a fixed requirement can take up to 7 days to show as Compliant. DKIM has its own lag of up to 48 hours after the record is added.

Does any of this apply to mail between our own staff? No. Google says the requirements “don’t apply to Google Workspace inbound and intra-domain messages”.

Where to start

In order, and the first two need nothing you do not already have.

1. Find a bounce message and read the code. If you have one, it names the requirement and you can skip straight to fixing that.
2. Add your domain to Postmaster Tools and open the Compliance status dashboard. Eight rows, three possible answers each. If most of them say No data found, you are a small sender and that is expected.
3. Set up the records you are missing, using our SPF, DKIM and DMARC guide. Do the ones on the bouncing list first.
4. Test by sending to a personal Gmail address, never to a colleague, and read the authentication results in the message header.

If nobody in your business wants to own DNS records, that is a fair position and it is part of what we do. We set up and manage Google Workspace for Singapore businesses, including the DNS side, and we are an authorised reseller. Our Google Workspace services page explains how we work, and Google Workspace pricing in Singapore is the other page to read before you commit.

The honest test is whether anyone in your team will notice the next time this breaks. Records drift when a new marketing tool is added, and nothing announces it. The two checks at the top of this page are the ones that would tell you, so the question is whether somebody opens them now and again, or whether the first sign is a customer who never replied.