Your Marketing Emails Land in Spam. Customers See Fake Messages From You. Now What?
Your marketing team tells you half the campaign emails didn't reach the inbox. Your head of sales asks why a follow‑up ended up in spam. Then a customer forwards you an email that looks like it came from your company — but you didn't send it. Somewhere in these conversations, someone mentions SPF, DKIM, DMARC. You nod, but honestly, you have no idea which does what or whether yours are set up right.
You're not alone. Most organisations have at least one gap. Email authentication is a three‑layer system, and running just one or two of them gives you partial protection at best.
The Real Reason Partial Setups Hurt You
SPF, DKIM, and DMARC are not three separate initiatives. They form a stack. SPF lists the servers allowed to send mail from your domain. DKIM adds a cryptographic signature that proves the message hasn't been tampered with on its way to the recipient. DMARC tells receiving mail systems what to do when a message fails those checks — and reports the results back to you.
A gap in any layer breaks the chain. If you have SPF but no DKIM, DMARC can't enforce strict policy because the message lacks a second, independent proof of legitimacy. If you have DKIM but a broken SPF, your authorised marketing platform might fail the server‑level check and still land in spam. And if you have both SPF and DKIM but no DMARC, spoofed messages that fail both checks will still be delivered because you never told receivers to reject them.
Most companies set up SPF for their primary email service, maybe DKIM for one platform, and leave DMARC as an afterthought. That partial setup is why legitimate mail sometimes gets delivered and sometimes doesn't — and why impostor mail keeps reaching inboxes.
Where Email Authentication Gaps Hide
SPF: Who Gets to Send Mail as You
The Problem
The SPF record is missing, has syntax errors, or doesn't include every service that sends email for your domain. A typical scenario: you use Google Workspace for company email, but also HubSpot for marketing, Zendesk for support, and a recruiting tool that sends outbound messages. If your SPF only lists include:_spf.google.com, all those other services will fail authentication. Even if you remember to add them, an SPF record that exceeds 10 DNS lookups causes SPF PermError, which invalidates the entire check. You might even have two SPF records because someone added a second TXT record without deleting the old one — that also breaks the check.
How to Fix It
Audit every platform that sends email on behalf of your domain — transactional email, sales outreach, CRMs, survey tools, HR systems. Build a single SPF TXT record that includes them all using the include: mechanism where supported. If you're approaching the 10‑lookup limit, use an SPF flattening service to keep the record valid. Never publish more than one SPF record. Test afterward to make sure the record resolves correctly. Read more about building a reliable SPF record in SPF.
DKIM: Is the Message Still Intact
The Problem
DKIM is missing entirely for some sending services. Even if your email platform signs outgoing messages with DKIM, third‑party tools you've added might not. Worse, if the DKIM key is 1024‑bit instead of 2048‑bit, some receivers will treat it as weak and lower trust. Signature mismatches happen when a service rotates keys but the DNS record isn't updated, or when your domain uses a selector that conflicts with a legacy setup. A partial DKIM means a message that passes SPF can still fail DMARC because there's no valid signature.
How to Fix It
For every sending service, generate a DKIM key pair. Use at least 2048‑bit keys. Publish the public key as a TXT record at selector._domainkey.yourdomain.com using the selector that the service provides. Keep the private key secure on the sending platform. If you change services, don't let old DKIM records linger — they can cause confusion and validation failures. Check each service's DKIM documentation carefully. We cover the full setup in DKIM Explained.
DMARC: Turning Checks Into Enforcement
The Problem
Most companies don't have a DMARC record at all. Those that do often set p=none and forget about it. That means receivers get no instructions on what to do with authentication failures, so spoofed emails get delivered as if nothing is wrong. Without a rua tag to collect DMARC aggregate reports, you have no visibility into who is attempting to spoof your domain or whether your legitimate tools are passing. Without a gradual move from p=none to p=quarantine or p=reject, you never build enforcement.
How to Fix It
Start by publishing a DMARC record at _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. This will not block anything but will generate reports showing which sources send email claiming to be from your domain and how they perform on SPF and DKIM. Analyse those reports over a month. Once you see that your legitimate services align, change the policy to p=quarantine to mark failing messages as spam. Eventually, when confidence is high, move to p=reject to block unauthenticated messages outright. Full guidance on policy progression is in DMARC.
How to Keep Your Authentication Stack Intact
The Bottom Line
Email authentication isn't a checkbox — it's a living configuration that changes every time you add a new tool. SPF, DKIM, and DMARC work best as a complete set. Leaving one layer weak undoes the protection of the others. Start by auditing what you have today.
Scan your domain with TechSpy to see where your gaps are — it takes less than a minute and gives you a clear picture of exactly what needs fixing.