If your invoices land in spam, or a client says they got an email "from you" that you never sent, the fix usually comes down to three DNS records: SPF, DKIM and DMARC. Here is what each one does, in plain terms, and how to tell whether yours are set up.
The two problems these records solve
Deliverability. Mail servers at Google, Microsoft and the rest decide, message by message, what goes to the inbox and what goes to spam, and one of the first things they check is whether the sender can prove the message came from the domain on the From line. If yourbusiness.com makes no such claim, or the proof fails, your invoice or appointment reminder is competing with the spam pile.
Impersonation. Email was designed so anyone can type any address into the From field. Without these records, a scammer can send a message "from" billing@yourbusiness.com asking your clients to pay a new bank account, and nothing flags it. These records are the email half of the security basics every small business should have.
SPF: who is allowed to send for your domain
SPF is one line of text in your domain's DNS listing the servers allowed to send email as your domain; receivers check whether the server that delivered a message is on the list. For a business on Google Workspace with an invoicing tool, it looks like this:
v=spf1 include:_spf.google.com include:mail.invoicingtool.example ~all
Each include: points to a service you use; ~all says "treat anything else as suspicious."
Two rules matter most. First, a domain gets exactly one SPF record. Add a second, usually by pasting a new tool's value as a new record instead of editing the existing one, and both become invalid. Second, the record must include every service that sends as you: email provider, invoicing software, newsletter or CRM platform, appointment system, and the contact-form plugin on your website. Forget one and that service's mail quietly fails. One ceiling to know: SPF allows at most ten DNS lookups per check, and each include: counts.
DKIM: a signature that proves the message was not altered
DKIM adds a digital signature to each outgoing message. The sending service signs it with a private key, you publish the matching public key in DNS, and receivers use it to confirm the message came through that service unchanged. Unlike SPF, it survives forwarding.
Setup is mostly copy and paste: in your email provider's admin panel, turn DKIM on, paste the host name and long string it gives you into DNS as a TXT record (some use a CNAME), then go back and click verify. Each sending service has its own key, so you repeat this for the newsletter tool, the invoicing tool and so on.
DMARC: the policy, and the reports
SPF and DKIM each answer a question; neither says what to do with the answer. DMARC is the policy. It is a TXT record at _dmarc.yourbusiness.com that tells receivers what to do when a message claiming to be from your domain fails the checks, and where to send reports. It also requires alignment: the domain on the visible From line must match the domain SPF or DKIM validated, so a scammer cannot pass the checks with their own domain while displaying yours.
p=none means monitor only: deliver as usual, but send reports. p=quarantine sends failures to spam. p=reject refuses them. A starting record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc@yourbusiness.com
Start at none, because the reports will show you senders you forgot about. They arrive as XML files; a free report viewer turns them into a readable list of who sends as your domain and whether they pass. Once everything legitimate passes, move to quarantine, then reject. Do not stay on none forever: it protects nobody. Receivers still deliver the impersonation; you just get told afterwards. Most small businesses can reach reject within a couple of months. Google's guide to setting up DMARC for a domain covers the rollout in more detail.
Where these records live
All three are DNS records, and DNS is managed wherever your domain's nameservers point: usually the registrar where the domain was bought, or Cloudflare if someone moved it there. It is not necessarily where your email is hosted. This is why you need to know who controls your DNS. If the login belongs to a former web designer or an agency you stopped working with, you cannot make these changes, and neither can anyone you hire. If the honest answer is "I'm not sure," finding out comes before anything technical.
Common mistakes
- Two SPF records. The most common failure I see. Merge them into one.
- A forgotten sending service. Regular email arrives fine, but invoices or booking confirmations land in spam. That tool is not in SPF and has no DKIM key.
- DMARC without alignment. A newsletter tool passes SPF for its own domain, but your From address is yourbusiness.com, so DMARC fails. Most tools let you verify a custom sending domain; use it.
- Changing email providers and leaving the old records. The old
include:stays in SPF, and anyone who gets into that abandoned account can still send authenticated mail as you. Remove what you no longer use. - A website form that sends "from" the visitor's address. Many form plugins put the visitor's Gmail address in the From field; your server cannot send for gmail.com, so the message fails and you never see the lead. Send from forms@yourbusiness.com and put the visitor in Reply-To.
How to check your setup
Free lookup tools (search for an SPF or DMARC checker) read your records and flag the obvious problems: a missing record, two SPF records, too many lookups, a policy stuck on none. Then do the real test. Send a message from each sending service, not just your main mailbox, to a Gmail or Outlook account you control. Open it, choose "Show original" or "View message source," and find the line beginning Authentication-Results:. You want spf=pass, dkim=pass and dmarc=pass; anything else tells you which record needs attention for that service.
What this does not fix
Authentication proves who sent a message, not whether it is welcome. Subject lines in capitals, link shorteners, one giant image with no text, or a newsletter to a purchased list will still earn complaints that no DNS record repairs. And if someone has your password, their mail is authenticated too: DMARC passes it because it came from your real account. For that, the answers are two-factor authentication and a password you do not reuse, part of the cybersecurity work I do for small businesses.
The checklist
| Record | What it proves | Where to set it | Typical time |
|---|---|---|---|
| SPF | The delivering server is on your approved list | DNS host, one TXT record at yourbusiness.com | About an hour to list every service |
| DKIM | The message was signed by that service and not altered | Each sending service, key pasted into DNS | Fifteen minutes per service; up to two days to verify |
| DMARC | What receivers do with failures, plus reports to you | DNS host, one TXT record at _dmarc.yourbusiness.com | Ten minutes; four to eight weeks before reject |
When to do it yourself, and when to call someone
With one email provider, one or two other tools, and the DNS login in hand, you can do all of this yourself in an afternoon. Every major provider publishes instructions for its own DKIM key. Publish DMARC at none, read the reports for a few weeks, and tighten it when the senders match what you expect.
Call someone when you do not know who controls your DNS, when five or more services send as your domain, when the reports show traffic you cannot explain, or when a client has already been asked to pay a fake invoice. My site and security review is $250, credited toward any work that follows, and it covers these records along with the website. If you would rather ask first, get in touch and I will tell you whether it is a ten-minute fix or something more.
Javier NapolesJavier Napoles is the founder of Argus Digital Works in Stamford, Connecticut. He designs, builds, secures and maintains websites for small businesses in Fairfield County and remotely, and holds CompTIA Security+. About Javier