If email from your business domain keeps landing in spam folders, the most common cause is not what you wrote. It is three DNS records on your domain called SPF, DKIM and DMARC, and whether they are set up, set up once, and set up to agree with each other. Gmail and Yahoo now check them on every message, and since 2024 they have published requirements that say so. A domain with these records done right gets through. A domain with them missing, doubled, or contradicting each other gets filtered, and sometimes gets impersonated.
This is the plain-English version I give business owners in central Connecticut when they ask why a quote they sent never arrived.
The problem these records solve
Email was designed in a time when nobody imagined pretending to be someone else. The "From" address on a message is just text. Anyone can put [email protected] in it and send the message from anywhere. Spam filters know this, so they look for proof that a message claiming to come from your domain actually did. SPF, DKIM and DMARC are that proof. Each is a short text record published in your domain's DNS.
If you have ever had a customer say "I got a weird email from you," or had your own mail bounced as suspicious, this is the machinery involved.
SPF: who is allowed to send as your domain
SPF (Sender Policy Framework) is a list of the mail servers permitted to send email for your domain. When Gmail receives a message from yourcompany.com, it looks up your SPF record and checks whether the server that delivered the message is on the list.
For a typical small business the list is short: Microsoft 365 or Google Workspace, plus whatever sends on your behalf, such as your invoicing software, your newsletter tool, or your website's contact form. Each of those has to be in the record, usually as an "include" line the vendor gives you.
SPF has two rules that cause most of the trouble I see:
- Exactly one record. A domain is allowed a single SPF record. If a second one gets added (commonly when a new vendor's instructions say "add this record" and someone adds it instead of merging it), the standard says the result is a permanent error and the check fails for everything (RFC 7208, section 3.2). I find doubled SPF records on a surprising number of domains.
- No more than ten lookups. Every "include" and a few other mechanisms count as a DNS lookup, and the standard caps a record at ten (RFC 7208, section 4.6.4). Includes nest, so one vendor's include can cost three or four lookups by itself. Go over ten and SPF fails. Domains that have accumulated vendors over the years hit this without anyone noticing.
The record ends with a qualifier for everyone not on the list. "~all" (soft fail) is the common choice; "-all" (hard fail) is stricter. Either is fine as long as the list is complete.
DKIM: a signature that proves the message was not altered
DKIM (DomainKeys Identified Mail) is a cryptographic signature added to each outgoing message by your mail provider. The matching public key is published in your DNS. The receiving server checks the signature against the key, which proves two things: the message came from a system holding your private key, and nothing in it changed in transit.
The practical part: DKIM has to be turned on at the provider and the key records added to DNS. Microsoft 365 does not sign with your own domain until you enable it; many tenants I take over have never had it switched on. Each sending vendor (invoicing, newsletters, the website) needs its own DKIM setup if it sends as your domain. Google's guidelines also require keys of at least 1024 bits; 2048 is the normal choice now.
DMARC: the policy that ties them together
DMARC (Domain-based Message Authentication, Reporting and Conformance) does two jobs.
First, it tells receiving servers what to do with a message that fails SPF and DKIM: nothing (p=none), send it to spam (p=quarantine), or reject it (p=reject). Second, it asks them to send you reports about who is sending mail as your domain, which is how you discover the forgotten vendor, or the person in another country impersonating you.
DMARC also requires alignment: the domain in the From address a human sees has to match the domain that passed SPF or the domain in the DKIM signature. A vendor can pass SPF on its own domain all day and still fail DMARC for yours if the alignment is off. This is the reason "SPF passes but mail still goes to spam" happens.
Start at p=none with a reporting address, read the reports for a few weeks, fix what they reveal, then move to quarantine and eventually reject. Jumping straight to reject on a domain nobody has audited is how a business blocks its own invoices.
What Google and Yahoo require now
Both published sender requirements that took effect in February 2024, and they are still the rules in 2026.
For every sender, Google requires SPF or DKIM, valid forward and reverse DNS for the sending server, TLS in transit, and a spam complaint rate under 0.3 percent in Postmaster Tools (Google email sender guidelines). Yahoo's list is the same at this level: SPF or DKIM at minimum, valid DNS, complaint rate under 0.3 percent (Yahoo sender requirements).
For bulk senders, which Google defines as 5,000 or more messages a day to Gmail addresses, both require SPF and DKIM together, a DMARC record of at least p=none, alignment between the From domain and the SPF or DKIM domain, one-click unsubscribe on marketing mail, and unsubscribes honored within two days.
Most small businesses are not bulk senders. The reason the bulk rules still matter is that the filters treat the full set (SPF plus DKIM plus DMARC, aligned) as the standard of a trustworthy domain, and domains that meet it get the benefit of the doubt. Google's page also notes it is moving toward quarantining unauthenticated mail that claims to be from Gmail addresses, which is the direction everything is heading.
How to check your own domain
You do not need to read DNS by hand.
- Go to a free lookup tool such as MXToolbox and run an SPF check, a DKIM check (you will need the selector, which your provider shows you; Microsoft 365 uses "selector1" and "selector2"), and a DMARC check on your domain.
- Send an email from your business account to a Gmail address you control. Open it, choose "Show original," and look at the three lines near the top: SPF, DKIM and DMARC, each with PASS or FAIL.
- If anything fails, note which sender it was. Mail from Outlook can pass while mail from your invoicing software fails, and the fix is in the vendor's settings, not Microsoft's.
Ten minutes, and you will know more about your domain's reputation than most of your competitors.
The mistakes I fix most often
- Two SPF records. Usually one old, one new. Merge them into one.
- Too many lookups. Remove vendors you no longer use; some providers offer a flattened include to get under the limit.
- DKIM never enabled in Microsoft 365 or Google Workspace. Everything sends unsigned.
- A third-party sender nobody listed. The website's contact form or a CRM sending "from" your domain through a server that is not in SPF and has no DKIM. The notifications fail, which is one reason a contact form can stop delivering without visibly breaking.
- No DMARC record at all. The domain gets no reports and no protection against impersonation.
- DMARC set to reject without alignment checked. The owner's own newsletters start bouncing.
- Records left behind at the old DNS host after a website move. If you have moved providers recently, moving your website off a site builder covers which records to carry across.
A manufacturing client moved from cPanel email to Microsoft 365 and staff started seeing "unverified sender" warnings. The DNS zone had MX and SPF right but no DKIM and no DMARC at all. Adding the two DKIM CNAMEs, copied from the Microsoft Defender portal because newer tenants use a different target than the old guides show, plus a DMARC record, fixed it. Then DKIM signing had to be switched on in the portal, which took a second try a few hours later. We have also caught our own domain's SPF still listing only the old host after a move.
Why this is a security item, not just a deliverability item
A domain with no DMARC policy is a domain anyone can send as. The phishing email that says "please update the wiring instructions for this invoice" works far better when it genuinely appears to come from your address, and the recipient's filter has no record from you saying it should be rejected. Email authentication is item five on our small business IT security checklist for that reason, and it pairs with the Microsoft 365 security settings every business should turn on.
The bottom line
SPF says who may send as your domain, DKIM signs what they send, and DMARC tells the world what to do when the first two fail, and reports back to you. Google and Yahoo check all three. One record each, under ten lookups, DKIM switched on at every sender, DMARC starting at p=none and tightening from there. Most small business domains fail at least one of those, and most of the fixes take less than an hour once somebody looks.
Want to know where your business stands? Get your company's free IT health report: an on-site look at your email, computers and backups with a written summary of what we found, no software installed and no obligation. Email authentication is one of the first things we check. Our managed IT page explains how we handle it on an ongoing basis, month to month and with no retainer, or contact us if you would rather just ask.