The client has SPF but not DKIM or DMARC — is that good enough?

It's better than nothing, but it's incomplete. SPF alone stops some spoofing but doesn't protect against a forged "From" address the way DKIM does, and without DMARC, nobody's actually enforcing what happens when a message fails these checks — mailbox providers are left to guess. Recommend filling in the gap, but don't frame SPF-only as broken; it's a partial setup, not a failed one.

Will adding these records fix deliverability immediately?

Often yes for the specific spoofing/spam-classification problems these records address, but not always instantly — DNS changes need to propagate, and some mailbox providers factor in sender reputation built up over time, which a DNS record alone can't retroactively fix. Set the expectation that this fixes the configuration, and reputation may take a little longer to catch up.

How does this fit with the other guides?

The DNS Records checklist covers SPF at a high level as one of five record types worth checking generally. This guide is the deeper, deliverability-specific reference — pull it out any time a client's actual complaint is "our email is going to spam" or "customers say they never got our message," not just during a general DNS audit.

Diagnosing Email Deliverability Issues: SPF, DKIM, and DMARC Explained for Client Work

A practical guide for freelance IT consultants and small MSPs: how to diagnose "our emails are going to spam" complaints by checking SPF, DKIM, and DMARC — what each one does, and how to explain a gap without blaming the last IT person.

"Our emails are going to spam" is one of the most common client complaints you'll hear, and it's also one of the most satisfying to actually fix — because more often than not, the cause is a missing or incomplete DNS record, not some mysterious email provider vendetta against the client. This is how to diagnose it properly: SPF, DKIM, and DMARC, what each one does, and how to check all three in a few minutes.

Start by looking at what's actually there

Run the client's domain through DNS Lookup and pull up the TXT records. You're looking for three specific things, and it's normal to find only one or two of them:

A record starting with v=spf1 — this is SPF.
DKIM doesn't show up as a plain TXT record on the bare domain — it lives on a selector subdomain, like google._domainkey.clientdomain.com or selector1._domainkey.clientdomain.com, so you'll need to check that specific subdomain once you know which email provider the client uses.
A TXT record on _dmarc.clientdomain.com starting with v=DMARC1 — this is DMARC.

Finding all three present is the good outcome. Finding one or two missing is extremely common, and is usually the actual answer to "why is our email going to spam."

SPF — who's allowed to send as this domain

What it does: SPF (Sender Policy Framework) is a published list of which mail servers are authorized to send email claiming to be from this domain. When a receiving mail server gets a message "from" the client's domain, it checks SPF to see if the sending server is on the approved list.

What it looks like: a TXT record like v=spf1 include:_spf.google.com include:sendgrid.net ~all — each include: is a service allowed to send as this domain (here, Google Workspace and SendGrid).

What missing or broken looks like: no SPF record at all means any server can claim to send as the client's domain, and receiving mail providers have nothing to check that claim against — a common reason legitimate mail (from a CRM, an invoicing tool, a marketing platform) lands in spam instead of the inbox. The other common gap: an SPF record that exists but is missing a service the client actually uses — usually because a new tool got added after the record was last touched.

DKIM — proof the message wasn't altered in transit

What it does: DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing mail, generated using a private key the sending service holds. The receiving server checks that signature against a public key published in DNS. If it matches, the receiver knows the message genuinely came from where it claims and wasn't tampered with along the way.

What it looks like: a TXT record on a selector subdomain specific to the sending provider — for example google._domainkey.clientdomain.com for Google Workspace — containing a long string starting with v=DKIM1; k=rsa; p=....

What missing or broken looks like: no DKIM record means outgoing mail has no way to prove its own authenticity, which weakens how mailbox providers score the message even if SPF passes. Broken usually means the key was rotated by the sending provider but the old DNS record was never updated, or the client switched email providers and the new provider's DKIM setup step was skipped.

DMARC — what happens when a message fails the check

What it does: DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving mail servers what to actually do when a message fails SPF or DKIM — and tells the domain owner about it. Without DMARC, SPF and DKIM are just information; DMARC is the enforcement layer.

What it looks like: a TXT record on _dmarc.clientdomain.com, such as v=DMARC1; p=none; rua=mailto:reports@clientdomain.com — the p= tag is the important part: none just monitors and reports, quarantine sends failing mail to spam, reject blocks it outright.

What missing or broken looks like: no DMARC record means there's no policy at all — mailbox providers are left to make their own judgment call on failing messages, inconsistently. When you do find one, check the p= value: p=none is a reasonable starting point but isn't actually enforcing anything yet, which is worth knowing before assuming DMARC is "handled."

Why you need all three, not just one

SPF alone stops the crudest spoofing but doesn't prove message integrity, and does nothing to tell receivers what to do about a failure. DKIM alone proves authenticity but doesn't restrict which servers can send as the domain in the first place. Neither one, alone, tells a receiving server what to actually do with a failing message — that's DMARC's job, and DMARC without SPF or DKIM underneath it has nothing to enforce. They're a layered system: SPF authorizes senders, DKIM proves integrity, DMARC enforces the outcome and reports back. A client with only one of the three is partially protected, not fully protected, and it's worth explaining that distinction plainly rather than treating "we have SPF" as a solved problem.

What to tell the client when you find a gap

Finding a missing record is good news framed correctly, and bad news framed carelessly. A few things that help:

Lead with the fix, not the failure. "I found the specific reason some of your emails are landing in spam, and it's a quick DNS fix" lands better than "your email security is misconfigured."
Don't speculate about who should have set this up. You often won't know if a previous provider skipped it, if it was never needed until the client added a new sending tool, or if it quietly broke after a migration. "This wasn't set up" is a neutral fact; "someone dropped the ball" is a guess you don't need to make out loud.
Explain the "why now" if it's relevant. If the client only recently started using a marketing or CRM tool that sends email on their behalf, it's worth explicitly noting that SPF/DKIM needs are directly tied to which services send mail — new tool, new entry needed — so this doesn't read as "this has been broken forever and nobody noticed."
Set expectations on timing. DNS changes propagate, and mailbox provider reputation can lag behind a fixed configuration. Say plainly that the fix is quick but full deliverability improvement might take a little longer to show up.

Bookmark this page — it's built to be the reference you pull up any time a client says their email is going to spam and you need to check SPF, DKIM, and DMARC properly.