SPF, DKIM and DMARC explained for small business owners

What SPF, DKIM and DMARC actually do, how they work together to stop people faking your email address, and a safe step-by-step way to set them up.

By Lordevo · · 6 min read

If your business uses its own domain for email, such as hello@yourbusiness.com, three DNS records decide how much the rest of the internet trusts mail that claims to come from you: SPF, DKIM and DMARC.

Without them, anyone can send an email that shows your address in the "From" line, and the receiving server has little to go on when deciding whether it is real. With them set up correctly, receiving servers can check that a message really came from you, and you can tell them what to do with messages that fail.

This guide explains each record in plain English, how they fit together, and a careful order for setting them up without breaking your own email.

Why this matters now

Email authentication used to be "nice to have". Large mailbox providers now expect it.

Since February 2024, Google has required anyone sending close to 5,000 or more messages a day to personal Gmail accounts to have SPF, DKIM and DMARC in place, and asks all senders to have at least SPF or DKIM. Yahoo introduced similar requirements at the same time. Since May 2025, Outlook.com has applied comparable rules to domains sending more than 5,000 messages a day to its consumer addresses, and mail that fails can be junked or rejected.

Most small businesses send far less than that. But the same checks feed into how every provider filters mail, and they're your main defence against criminals pretending to be you in invoices and password-reset scams. Setting them up is worthwhile at any size.

SPF: who is allowed to send for your domain

SPF (Sender Policy Framework) is a TXT record in your domain's DNS that lists the servers allowed to send email for your domain. A simple SPF record looks like this:

v=spf1 include:_spf.google.com ~all

Reading it left to right:

  • v=spf1 says this is an SPF record.
  • include:_spf.google.com allows Google Workspace's mail servers. Each email service you use (your mailbox provider, newsletter tool, invoicing software, website contact form) publishes its own include value in its help pages.
  • ~all says that anything not listed should be treated as suspicious (a "soft fail"). -all is stricter and says it should fail outright.

A few rules catch people out:

  • Have only one SPF record per domain. Two separate v=spf1 records make SPF fail entirely. If you add a new service, edit the existing record instead of creating another.
  • Mind the 10-lookup limit. SPF allows a maximum of 10 DNS lookups when it is checked, and each include can use several. Piling up services can quietly push you over the limit, which also causes SPF to fail.
  • SPF checks the "envelope" sender, not the address people see. That hidden return address is often owned by your email service, not you. This is one reason SPF alone doesn't stop spoofing, and why DMARC exists.

DKIM: a signature that proves a message wasn't forged

DKIM (DomainKeys Identified Mail) adds a digital signature to each message your mail service sends. The signature is created with a private key that only your mail service holds. The matching public key is published in your DNS, so any receiving server can verify the signature.

DKIM records live at a name like selector._domainkey.yourbusiness.com. The "selector" is a label your provider chooses, such as google or s1, which lets you have several keys for different services at the same time.

You normally don't write DKIM records by hand. Your mail provider generates the key and shows you the exact record to add. Each service that sends mail as your domain should be set up to sign with DKIM, which usually means adding one or two records per service.

If the signature checks out, the receiver knows two things: the message was sent by someone who holds the key for that domain, and the signed parts weren't changed on the way.

DMARC: tying it together and setting a policy

SPF and DKIM each prove something, but neither checks that the domain in the visible "From" address is the one that passed. DMARC (Domain-based Message Authentication, Reporting and Conformance) closes that gap.

A message passes DMARC when SPF or DKIM passes and the domain that passed matches (or "aligns" with) the domain in the From address. DMARC also lets you publish a policy telling receivers what to do with mail that fails, and where to send reports.

A DMARC record is a TXT record at _dmarc.yourbusiness.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.com
  • p= is the policy: none (just monitor), quarantine (treat failures as suspicious, usually the spam folder) or reject (refuse failures).
  • rua= is the address that receives aggregate reports: daily summaries from mailbox providers listing which servers sent mail as your domain and whether it passed.

The reports arrive as XML files, which aren't pleasant to read directly. Many DMARC reporting services will parse them into readable charts for you. Use a separate mailbox or alias for them, because they can pile up.

A safe order for setting everything up

The risk with email authentication isn't the records themselves. It's forgetting a service that legitimately sends mail for you, then telling the world to reject that mail. This order avoids that:

  1. List every service that sends email as your domain. Your mailbox provider, newsletter platform, CRM, helpdesk, booking system, online shop and the contact form on your website. Ask whoever manages each one.
  2. Set up DKIM for each service using the records each provider gives you.
  3. Create or fix your single SPF record so that it includes every service on your list, ending in ~all.
  4. Publish DMARC with p=none and a reporting address. This changes nothing about delivery; it starts the reports flowing.
  5. Read the reports for a few weeks. Look for legitimate services that fail. Fix their SPF or DKIM setup until your real mail consistently passes.
  6. Move to p=quarantine, then later to p=reject once you're confident.

There's no fixed timetable for these steps. Move on when the reports show that all your real mail is passing.

Domains that never send email

If you own extra domains that don't send email at all, such as old brand names or typo domains, you can protect them too. Publish an SPF record of v=spf1 -all (nothing is allowed to send) and a DMARC record with p=reject. That tells receivers to refuse any mail claiming to come from them.

How to check your records

You can look up your own records with any DNS lookup tool by searching for the TXT records on your domain and on _dmarc.yourdomain. Your mail provider's admin console often shows whether DKIM is active. You can also open a message you sent to a personal Gmail or Outlook account and view the original headers, which show SPF, DKIM and DMARC results for that message.

Our free Safe Scan on Lordevo Security also looks up your SPF and DMARC records and checks a set of common DKIM selectors as part of its passive checks, so you can see quickly whether anything is missing. It can't see selectors it doesn't know about, so if it reports no DKIM, confirm in your mail provider's settings before assuming it isn't there.

Email records protect your domain's name in people's inboxes. Your website needs similar basic protection in its HTTP responses: see Security headers every small business website needs.

The short version

SPF lists who may send for your domain. DKIM signs each message so it can't be forged or altered unnoticed. DMARC checks that the visible From address matches what passed, tells receivers what to do with failures and sends you reports. Set up DKIM and a single SPF record first, start DMARC at p=none, read the reports, and tighten the policy only when your real mail consistently passes.