SPF, DKIM, DMARC: Why Your Domain Probably Sends Spam Right Now

Most small business domains can be impersonated by an attacker for free, in about ten minutes, using a Gmail account they paid nothing for. The reason is that three DNS records nobody talks about are missing or misconfigured. The records are SPF, DKIM, and DMARC. Together they are the only thing standing between your reputation and an attacker spoofing your CEO to wire $80,000 to a fake vendor.

This post explains what each record does, in plain English, and tells you how to check yours in two minutes.

The three records, in one paragraph each

SPF (Sender Policy Framework) lists which servers are allowed to send email on your behalf. It lives in a TXT record at the apex of your domain. When a receiving mail server gets a message claiming to be from you@yourcompany.com, it pulls your SPF record and checks whether the sending server’s IP appears on the list. If not, the message is suspicious. If your record is missing or wide-open, anyone can claim to be you.

DKIM (DomainKeys Identified Mail) cryptographically signs the body of each outgoing message with a private key your mail provider holds. The matching public key is published in DNS at a selector you choose (selector1._domainkey.yourcompany.com). Receivers verify the signature against the public key. If a message claims to be from your domain but isn’t signed by your key, it gets dinged.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer. It tells receiving mail servers what to do when a message fails SPF or DKIM, and it requests that receivers send you a daily report of who is sending mail using your domain. The policy can be none (just observe), quarantine (send to spam), or reject (refuse delivery).

The three failure modes we see most often

No SPF record at all. Surprisingly common. Anyone with access to a mail server (or a script kiddie with a $5/month VPS) can send From: ceo@yourcompany.com and major receivers will deliver it.

SPF that ends in ?all or ~all. These soft-fail modes tell receivers “we’re not sure if this is legit, deliver it anyway and let the user decide.” A modern SPF record should end in -all (hard fail) once you have confidence in the senders list.

DKIM not signing all your mail. Microsoft 365 and Google Workspace both default DKIM to off until you flip it on per domain. We routinely find tenants where DKIM was never enabled, even though the customer “uses M365 for email.”

DMARC at p=none for years with no progress. The training-wheels policy. It does nothing to stop spoofing. Most domains we audit have been at p=none for two to four years. The point of p=none is to gather data and graduate to p=quarantine then p=reject. Skipping the graduation defeats the entire purpose.

How to check your domain right now

You can do this in a browser without any tools. Replace yourcompany.com with your actual domain in each link:

• SPF: open Cloudflare’s DoH tester or run the Cyber Score, which checks SPF live.
• DKIM: harder to check without knowing your selector. M365 default selector is selector1; Google’s is google. Try selector1._domainkey.yourcompany.com and google._domainkey.yourcompany.com in any DNS lookup tool.
• DMARC: look up the TXT record at _dmarc.yourcompany.com.

If any of those returns nothing, you have work to do. Even if all three return something, the contents matter:

• SPF must end in -all (or at least ~all) and include all of your real senders (M365, Mailchimp, your CRM, your accounting tool).
• DMARC should be at p=quarantine or p=reject, with rua=mailto:dmarc@yourcompany.com so reports come somewhere you can read them.

The quarantine-then-reject march

The right way to deploy DMARC for a business that has been emailing for years is gradual:

1. Start at p=none with rua reporting to a DMARC processor (Postmark’s free tier, dmarcian, EasyDMARC).
2. Watch the reports for two to four weeks. Find every legitimate sender that isn’t yet authenticated.
3. Add those senders to SPF. Enable DKIM where possible.
4. Move to p=quarantine once your authentication coverage is above 95%.
5. Move to p=reject once you’re at 99%+ and confident no legitimate mail is failing.

Most businesses can get from “no DMARC” to p=reject in about 60 days with weekly attention. We do this as part of our Steel and up onboarding.

Why this matters for the bottom line

Two reasons. The defensive reason: business email compromise (BEC) is the most expensive cyber crime in the FBI’s IC3 report year after year. Average loss per incident in 2024 was $137,000. A correctly configured DMARC p=reject makes domain spoofing materially harder.

The deliverability reason: in February 2024 Google and Yahoo started enforcing SPF + DKIM + DMARC for senders of more than 5,000 messages per day to their users. Microsoft followed in early 2025. If you do email marketing or send invoices to gmail.com or outlook.com addresses, your delivery rate is already a function of these records.

What you can do in five minutes

Run the Cyber Score. It checks SPF, MX, and DMARC live against your domain in the browser. The full report is free and includes the exact records you need to change. No follow-up sales calls unless you ask.

If you want us to walk in and do the cleanup, that’s part of every Steel and up plan. Hourly clients can also have us do a one-time DMARC project (typically 4-6 hours).