NEWTONS/TECH

§ 01  /  BLOG

← ALL ENTRIES

// DNS

What Are SPF, DKIM, and DMARC? A Plain-English Guide for Small Businesses

Three DNS records decide whether your business email lands in the inbox or the spam folder. Here is what SPF, DKIM, and DMARC actually do, and why you probably need all three.

If you have ever wondered why a perfectly normal email from your business ended up in a customer’s spam folder, there is a good chance the answer is three DNS records you have never heard of.

They are called SPF, DKIM, and DMARC. Together they are the reason Gmail and Outlook trust that an email claiming to be from yourbusiness.com was actually sent by your business. Without them, a modern inbox treats you with suspicion by default. With them, your mail lands where it is supposed to.

They are also free to set up, and a lot of small business domains are missing one or more of them.

Here is what each one does, in the order you should think about them.

SPF: who is allowed to send mail for you

SPF stands for Sender Policy Framework. It is a short list you publish at your domain that says, in effect, “these are the servers allowed to send email on behalf of yourbusiness.com.”

When a receiving mail server gets an email claiming to be from you, it looks up that list. If the sending server is on it, SPF passes. If it is not, SPF fails, and the email is more likely to be flagged or rejected.

The list is specific to whatever you actually use to send mail. Google Workspace. Microsoft 365. A mailing list tool like Mailchimp or ConvertKit. Your CRM. If any of these send mail as you, they need to be in your SPF record. If you add a new sending service and forget to update SPF, suddenly half your outbound mail looks fake to the world.

A clean SPF record is a one-line TXT record in your DNS. It is easy to get wrong in small ways that silently break things, which is a theme you will notice with all three of these.

DKIM: proof the message has not been tampered with

DKIM stands for DomainKeys Identified Mail. Where SPF is a list of who can send, DKIM is a cryptographic signature on the message itself.

When a server sends mail as you, it signs the message with a private key. The matching public key lives in your DNS, where any receiving server can look it up. The receiving server uses that public key to verify that the message was really signed by your domain, and that nothing has been changed in transit.

You do not need to understand the math. You need to know that DKIM is what lets Gmail look at a message and say, “yes, this was genuinely signed by yourbusiness.com, and nobody has rewritten the body or the subject line since it was sent.”

Every major mail provider generates DKIM keys for you. The job is to publish the public key in your DNS, as a TXT record, at the right name. Once it is there, your outbound mail gets signed automatically.

DMARC: the policy that ties it together

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance, which is an uncomfortable acronym for what is actually the simplest of the three.

DMARC is a policy. It tells receiving mail servers what to do when an email fails SPF or DKIM checks. Your options are:

  • none (just watch and report, do nothing)
  • quarantine (send to spam)
  • reject (bounce it entirely)

DMARC also asks receivers to send you reports on mail that passed or failed. Those reports are how you find out that some old marketing tool has been sending as you for two years and failing authentication every time.

The usual path is to start with a none policy, watch the reports for a few weeks to make sure everything legitimate is authenticating properly, then move to quarantine, then to reject. That ramp is what keeps you from accidentally killing your own mail while you tighten things up.

Why all three matter, especially now

Gmail and Yahoo announced stricter sender requirements in 2024. If you send meaningful volume of mail, they now expect SPF, DKIM, and DMARC to be set up properly, or your mail will be throttled or rejected. Microsoft has been tightening similarly.

Even if you only send a handful of personal messages a day, the trend is one-way. The inbox is getting stricter, not looser. A domain without these records is treated with more suspicion every year.

The other reason to care is impersonation. If your domain does not publish SPF and DMARC, a scammer can send email that looks exactly like it came from you, to your customers, asking for invoices to be paid to a new bank account. This is not theoretical. It is the most common B2B fraud there is. DMARC with a reject policy is what stops it.

What goes wrong in practice

A few patterns we see over and over:

One record, set up five years ago, never touched since. The business has added three new sending tools since then, none of them are in SPF, and mail from those tools is quietly landing in spam.

SPF set up, DKIM missing. This is the most common state. SPF on its own is not enough for modern deliverability.

DMARC published with no monitoring. The policy is in place, the reports are going to an address nobody reads, and a real problem has been invisible for months.

Multiple SPF records. Only one is allowed. If two tools each publish their own, the record fails entirely and all mail becomes suspect.

None of these are hard to fix once you know to look. The hard part is knowing to look at all.

What we do

Every domain we manage for clients gets SPF, DKIM, and DMARC set up correctly, with DMARC reports sent somewhere a real person can read them. We also watch for changes, so that when you add a new sending tool, the records get updated before your mail starts failing.

This is part of our domain and DNS management, because it is the kind of thing that breaks quietly, in ways you will not notice until three weeks of replies from customers have gone missing.

If you are not sure what shape your email records are in, the contact form is the fastest way to find out. We will look up your domain, tell you what is there and what is missing, and be honest about whether it is worth doing anything about.

The boring DNS stuff is a recurring theme around here. If you want the broader picture, we also wrote about SSL, backups, and DNS in general.

Read more about our Websites service.

// MORE IN DNS