Email Security · 7 min read

SPF, DKIM, and DMARC explained for non-technical business owners

If you've ever gotten a security report flagging "missing SPF record" or "no DMARC policy" and had no idea what that meant, you're not alone — these are three of the most common findings on small business scans, and also three of the least explained. Here's what they actually do, in plain English.

The problem they all solve

Email was never designed with sender verification in mind. By default, anyone can put your business name in the "From" field of an email and send it to anyone — there's no built-in check that stops them. SPF, DKIM, and DMARC are three DNS records that, together, let receiving mail servers (Gmail, Outlook, etc.) verify that an email claiming to be from your domain actually came from a server you authorized.

SPF (Sender Policy Framework)

SPF is a list, published in your DNS, of which mail servers are allowed to send email on behalf of your domain. When an email arrives claiming to be from you@yourbusiness.com, the receiving server checks: does the actual sending server appear on yourbusiness.com's approved list? If not, the email fails SPF.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing email, generated using a private key only your mail provider has. The receiving server checks that signature against a public key published in your DNS. If it matches, the email provably came from your system and wasn't altered in transit.

Where SPF checks which server sent the email, DKIM checks whether the email itself is genuine and unmodified.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC ties the other two together. It tells receiving servers what to do when an email fails SPF or DKIM checks: let it through anyway, send it to spam, or reject it outright. Without a DMARC policy, most mail servers will quietly accept failing messages by default — which means SPF and DKIM alone don't fully protect you.

Why this matters even if you never send marketing email

This isn't about email marketing deliverability — though it affects that too. It's about who can convincingly impersonate your business. Without these three records configured correctly, a scammer can send an invoice, a password reset, or a "payment details have changed" email that looks like it came directly from your domain, to your actual customers or vendors. That's a direct path to fraud, and it damages trust in your brand even though your systems were never technically "hacked."

How to actually add these records

All three are added as TXT records in your domain's DNS settings (through your domain registrar or DNS provider — GoDaddy, Cloudflare, Namecheap, etc.):

• SPF: add a TXT record for @ with a value like v=spf1 include:_spf.google.com -all (replace the include with your actual email provider's SPF mechanism — Google Workspace and Microsoft 365 both publish theirs).
• DKIM: generated and enabled through your email provider's admin console (Google Workspace: Admin Console → Apps → Gmail → Authenticate Email). It gives you a TXT record to add to DNS.
• DMARC: add a TXT record for _dmarc with a value like v=DMARC1; p=quarantine; rua=mailto:you@yourdomain.com. Start with p=quarantine, monitor for a week or two, then move to p=reject once you're confident nothing legitimate is being blocked.

You can verify all three are working using free tools like MXToolbox after adding the records (DNS changes can take anywhere from minutes to 48 hours to propagate).