Local Business

Email that actually lands: SPF, DKIM, and DMARC explained for owners

Why your invoices land in spam and how scammers send email that looks like it came from you. A plain-language guide to the three DNS records that protect your name and your deliverability.

August 7, 2026 8 min read emailsmall businessdeliverabilitysecurityDNS

You send an invoice and the customer says it never arrived. It was in their spam folder. Or worse, a customer forwards you an email “from your company” asking them to change the bank details for a payment, and you never sent it. Both problems come from the same place: without the right setup, anyone on the internet can put your domain name in the “From” line of an email, and the systems that receive mail have no reliable way to tell your real messages from the fakes.

Three small records fix most of this. They live in your domain’s DNS settings, they are free, and once configured they work quietly in the background. They are called SPF, DKIM, and DMARC. You do not need to understand the cryptography behind them. You do need to know what each one does and whether yours are set up, because the cost of getting this wrong is landing in spam and letting strangers send mail in your name.

The problem in one sentence

Email was designed in an era of trust, so by default the “From” address is as easy to fake as the return address you scribble on an envelope. SPF, DKIM, and DMARC are the modern add-ons that let a receiving server ask three questions: is this coming from a server allowed to send for this domain, has the message been tampered with in transit, and what should I do if the answers are no.

SPF: who is allowed to send

SPF, short for Sender Policy Framework, is a public list of the servers permitted to send email using your domain. When Microsoft, Google, or any mail provider receives a message claiming to be from you, it checks whether the sending server is on your list.

If you use Microsoft 365 for email, your SPF record names Microsoft’s servers. If you also send newsletters through a marketing tool and invoices through your accounting software, those senders need to be on the list too. This is the single most common cause of legitimate mail going to spam: a business adds a new tool that sends on its behalf, forgets to add it to SPF, and that mail starts getting flagged.

SPF stops much of the crude spoofing where a scammer sends from their own server pretending to be you. It does not, on its own, cover every case, which is why it works as a team with the other two.

DKIM: proof the message was not altered

DKIM, or DomainKeys Identified Mail, adds an invisible cryptographic signature to every message you send. The receiving server checks that signature against a key published in your DNS. If they match, two things are confirmed: the message really came from your domain, and nothing in it was changed between sending and delivery.

Think of DKIM as a tamper-evident seal. SPF says the mail came from an approved post office. DKIM says the envelope was not steamed open and rewritten along the way. Most mail providers turn DKIM on for you, but it is worth confirming rather than assuming, because a domain moved between providers can end up with DKIM quietly switched off.

DMARC: the instruction that ties it together

DMARC is the policy that tells receiving servers what to do when a message fails the SPF and DKIM checks. Without it, each provider guesses, and the guess is often “let it through anyway.” With DMARC, you give a clear instruction: quarantine failing mail to spam, or reject it outright.

DMARC does one more valuable thing. It can send you regular reports listing who is sending email using your domain. That is how many owners first discover that a service they forgot about, or an outright impersonator, has been sending in their name for months.

The usual approach is to start gently. You set DMARC to “monitor only” so it reports on what is happening without blocking anything, you read the reports for a few weeks to confirm your real senders are passing, and then you tighten the policy to quarantine or reject. Turning on strict rejection before you have confirmed your legitimate mail passes is how businesses accidentally block their own invoices.

How to check what you have today

You do not need special access to see whether these records exist, because they are public. A few free online tools let you type in your domain and see your current SPF, DKIM, and DMARC records, or the absence of them. Search for a “DMARC checker” or “SPF checker” and enter your domain name.

Broadly, you are looking for three outcomes:

  • An SPF record exists and lists every service that sends mail for you. If a sending tool is missing, its mail is at risk.
  • DKIM is enabled and passing. Your mail provider’s admin area will confirm this.
  • A DMARC record exists. If there is none, you have no policy and no reporting, which is the most common gap of the three.

If any are missing or incomplete, that is your list of things to fix.

How to fix it without breaking your mail

The changes themselves are small edits to DNS records, usually made wherever you registered your domain or wherever your DNS is hosted. The care is in the sequence, not the difficulty.

Get SPF complete first, so every legitimate sender is listed. Confirm DKIM is on. Add DMARC in monitor-only mode and actually read the reports for a few weeks. Only then move DMARC to quarantine, and later to reject once you are confident. Rushing straight to reject is the one mistake that turns a security improvement into a delivery outage.

If your team runs on Microsoft 365, this ties directly into how the rest of your accounts and devices are managed. Getting email authentication right is part of the same baseline as managed devices and accounts, which we cover on our device management page.

Why this is worth an afternoon

Two things are at stake. The first is deliverability: correctly authenticated mail is far more likely to reach the inbox instead of the spam folder, which matters every time you send a quote, an invoice, or a reply a customer is waiting on. The second is your name. Domain-based impersonation is a common route into invoice fraud, where a convincing fake email persuades a customer or supplier to send money to the wrong account. A strict DMARC policy makes your domain much harder to abuse that way.

If you are not sure where your email stands, this is exactly the kind of thing a short review turns up. Our business technology checkup looks at email authentication alongside the other quiet gaps most small businesses carry without knowing.

Want a straight answer on where your domain sits today? Send us two paragraphs about your setup — your domain, your email provider, and any tools that send mail for you — through our contact page, and we will reply in writing within one business day.

— Newsletter

Get the writing by email.

An occasional note from the team — case studies, new free tools, engineering essays. Never daily.

Three fields, no tracking. Privacy policy.