Why Your Quotes Land in Spam When You Only Send Forty Emails a Day

The rules apply to you. The volume only sets how much

Google requires all senders to have SPF or DKIM, valid forward and reverse DNS, a TLS connection and a spam rate below 0.3 percent. Above 5,000 messages a day the requirement becomes SPF and DKIM plus DMARC, alignment and one-click unsubscribe.

Take the all-sender list literally, because it is short and most small businesses fail part of it. Google requires you to set up SPF or DKIM authentication for your sending domains, to have valid forward and reverse DNS records for the sending domain or IP, to use a TLS connection for transmitting email, to keep spam rates in Postmaster Tools below 0.3 percent, to format messages according to RFC 5322, and not to impersonate Gmail From: headers.

Notice the word "or" in the first item. The minimum is SPF or DKIM, not both, which is a lower bar than nearly all coverage of this topic implies. Google does separately recommend that you always set up SPF, DKIM and DMARC for your domains¹, and it is worth being clear with yourself about which of those two standards you are meeting, because they are not the same standard.

Above 5,000 messages a day to Gmail the requirements tighten to SPF and DKIM together, a DMARC record, alignment between the From: header domain and either the SPF or DKIM domain, and one-click unsubscribe on marketing and subscribed messages¹. Most Southwest Florida businesses will never reach that threshold, and that is precisely why they stopped reading.

One more detail worth acting on even if you send almost nothing. Google recommends setting up email authentication for the domain that hosts your public website¹. That is not about your own sending. It is about making it harder for somebody else to send mail that appears to come from you, which is a different problem and arguably a worse one.

The usual cause is the tools sending on your behalf

Google states that your SPF record should include every sender for your domain, and that third-party senders missing from it are more likely to be marked as spam. Invoicing tools, booking systems and form handlers accumulate one at a time, and the record rarely gets updated.

Here is the pattern behind most small-business deliverability complaints, and it is not about volume or content. Your own mail, sent from your own mailbox, arrives fine. The quote from the estimating tool, the receipt from the invoicing system, the notification from the website contact form and the reminder from the booking platform all behave unpredictably, and nobody connects them because they arrive through different products.

They have one thing in common. Google states that the SPF record for your domain should include all email senders for your domain, and that if your third-party senders are not included in your SPF record, messages from these senders are more likely to be marked as spam¹. Each of those tools sends mail that claims to be from your domain. If your record does not vouch for them, the receiving server has no reason to believe them.

The failure is procedural rather than technical. A business adds a booking system in year one, an invoicing tool in year three and a CRM in year five, each set up by a different person in an afternoon, and the DNS record is not part of anybody’s checklist. There is no error message when this goes wrong. There is only silence, and a customer who assumed you never replied.

There is a second trap for anyone who has been diligent. Microsoft states that if you exceed ten DNS lookups, your SPF check might fail². Each include consumes lookups and some expand into several more, so a record that has been fine for years can begin failing when one more tool is added. If you have a long SPF record, the number of lookups is worth counting rather than assuming.

The practical version of this: list every system that sends email as your business, then check each one appears in your SPF record. Most owners are surprised by the length of the list. We cover the neighboring problem, who actually controls the DNS these records live in, separately.

What the three records actually do

SPF lists who may send for your domain. DKIM signs messages so a receiver can verify they were not altered and really came from you. DMARC tells receivers what to do when the first two fail, and can start harmlessly at p=none.

SPF is a published list of who is allowed to send email using your domain name. Google describes it as preventing spammers from sending unauthorized messages that appear to be from your domain, set up by publishing an SPF record that should include all email senders for your domain¹. It answers one question for a receiving server: was this message sent by a system you vouch for?

DKIM is a cryptographic signature on the message itself. Receiving servers use DKIM to verify that the domain owner actually sent the message¹, which also means the message was not altered along the way. One practical specification matters here: Google states that sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer, and recommends 2048 bits where your provider supports it. An older, shorter key is a real and quiet failure.

DMARC is the instruction for what happens when the first two fail. Google describes it as telling receiving servers what to do with messages that do not pass SPF or DKIM, and notes that to pass DMARC the authenticating domain must be the same domain that appears in the From: header¹. Microsoft asks for at least p=none, aligned with either SPF or DKIM and preferably both².

That p=none setting is the reason there is no excuse for skipping DMARC. It is a monitoring policy: it asks receivers to report what they are seeing without changing how anything is delivered. Google notes that its enforcement policy can be set to none even for bulk senders¹, and recommends setting up DMARC reports so you can see mail sent from your domain, or appearing to be sent from your domain. You find out who is impersonating you without risking a single legitimate message.

• SPF answers who is allowed to send as you.
• DKIM proves the message really came from you and was not altered.
• DMARC says what to do when those fail, and reports what it sees.
• Starting DMARC at p=none changes no delivery outcome.
• A DKIM key under 1024 bits fails for personal Gmail accounts.

Microsoft moved the same way, and nobody has moved back

From May 2025, Outlook requires SPF, DKIM and DMARC from domains sending more than 5,000 messages a day, routing non-compliant mail to the Junk folder with outright rejection signalled for a later date. Two major consumer providers converged on the same standard within about a year of each other, and neither has since relaxed it.

Google went first, and Microsoft followed with materially the same rules. Microsoft announced that for domains sending over 5,000 emails per day, Outlook would require compliance with SPF, DKIM and DMARC, that non-compliant messages would first be routed to Junk, and that if issues remained unresolved they may eventually be rejected². It applies to the consumer service, meaning outlook.com, hotmail.com and live.com addresses.

The specifics match Google closely enough that you can treat them as one standard: SPF must pass for the sending domain, DKIM must pass, and DMARC must be at least p=none and aligned with either SPF or DKIM, preferably both. If you configure for one provider you have very largely configured for the other, which is the one piece of good news in this subject.

The direction of travel is the useful signal here rather than any particular threshold. Two providers that between them handle a very large share of the consumer mailboxes your customers use have introduced authentication requirements within about a year of each other, and each has described its current setting as a step rather than a destination. Nobody has relaxed anything.

Microsoft was also asked directly whether senders below the threshold need to do this. The answer is worth quoting for what it does not say: while enforcement first targets large senders, all senders benefit from these best practices². That is not an exemption. It is a description of who gets enforced against first.

What to do, in order

Inventory every system that sends mail as your business, confirm each appears in SPF, turn on DKIM at the mail provider, publish DMARC at p=none, then watch the reports. None of it requires a marketing platform and all of it is DNS.

Start with the inventory, because every later step depends on it and it is the part people skip. Write down every system that sends email appearing to come from your domain: the mail provider, the website contact form, the invoicing tool, the booking or estimating system, the review request platform, anything with your logo on it. Then check that each one is represented in your SPF record¹, and count your lookups while you are in there.

Then turn on DKIM at your mail provider, which for most businesses is a setting rather than a project, and confirm the key length meets the 1024-bit minimum with 2048 preferred. Then publish a DMARC record at p=none with reporting enabled¹. That order matters: DMARC is the diagnostic, so it is most useful once the first two are in place and you want to know whether they are actually working.

On spam rate there is a distinction worth holding onto, because most coverage flattens it. The stated requirement is to keep spam rates in Postmaster Tools below 0.3 percent¹. Google’s own guidance elsewhere on the same page is stricter: keep spam rates below 0.10 percent and avoid ever reaching 0.30 percent or higher. Treat 0.10 percent as the target and 0.3 percent as the line you are already in trouble at.

And the honest limit on all of this. Passing authentication does not put you in the inbox; it removes a reason to keep you out. Reputation, content and whether people actually want your mail still decide the rest, and Microsoft says plainly that no system eliminates spam entirely. If you would rather this was somebody else’s job, it is part of what our technical SEO services cover, and our free SEO audit is the simplest way to see how your domain is currently set up.

1. List every system that sends as you. Mail provider, forms, invoicing, booking, review requests. The list is usually longer than expected.
2. Check each one appears in SPF. Google says senders missing from the record are more likely to be marked as spam.
3. Count your SPF lookups. Past ten, Microsoft says the check might fail, and there is no error message telling you.
4. Turn on DKIM at the mail provider. Confirm the key is at least 1024 bits, and 2048 if your provider supports it.
5. Publish DMARC at p=none with reports. It changes no delivery outcome and shows you who is sending as your domain.
6. Read the first month of reports. That is where you discover the tool nobody remembered was still sending.