SPF, DKIM and DMARC: What Each One Does and the Order to Set Them Up

Someone has told you that you need SPF, DKIM and DMARC. Maybe it was Google, or a red warning in your email platform, or whoever you called when your mail stopped arriving.

So you looked it up and found the specifications. They are accurate and they are useless to you. They explain what each record contains, and they never tell you what happens to your business when you set them up in the wrong order.

Let me give you the version that matters.

What are SPF, DKIM and DMARC actually doing?

Picture a private event with a doorman. You are the host, but you are not standing at the door, so you leave three things with him.

The first is a guest list, naming everyone who may come in using your name. The second is a way to check an invitation is genuine, because real ones carry a seal that cannot be copied. The third is an instruction: here is what to do when someone turns up who is not on the list, or whose seal is broken.

That is the whole system. SPF is the guest list. DKIM is the seal. DMARC is the instruction you leave for when the first two fail.

Three records, three different questions. Most guides teach them as one topic, which is why people set all three up in an afternoon and spend the next week wondering why their invoices stopped arriving.

SPF: who is allowed to send as you?

SPF is a line in your DNS naming every server permitted to send mail using your domain. Your email platform is on that list. So is your CRM, your invoicing tool, your helpdesk, your booking system, and the marketing tool someone signed up for last year and never mentioned.

That last one is where SPF quietly goes wrong.

How many systems send email as your domain right now? Most owners answer four and are wrong. The real number is usually six or seven, and the two you forgot are the ones that will break.

So write the list down before you touch the record. Then check it against what your DNS actually publishes today.

There is a hard limit worth knowing before it bites you. SPF allows ten DNS lookups, and each service you add can consume one or more of them. Go past ten and the record does not degrade politely. It fails outright, and providers treat that failure as permanent.

Run several sending tools and you will hit this ceiling. Check where you stand before you assume the record is healthy.

DKIM: was this message altered on the way?

DKIM signs your mail with a private key, and your DNS publishes the matching public key. The receiving provider checks one against the other. If the signature verifies, the message arrived exactly as you sent it.

If it does not verify, one of two things happened. Something changed the message in transit, or the mail never came from you at all.

SPF and DKIM answer genuinely different questions, and this is the part most summaries blur. SPF asks whether the sending server was permitted. DKIM asks whether the message itself is intact. A message can pass one and fail the other, and that disagreement is exactly what DMARC exists to settle.

So which of your tools is signing its mail today? If you only checked the main platform, you do not know yet.

Turn DKIM on in every platform that sends for you, not just the main one. A tool sending unsigned mail under your domain drags your reputation down while you watch your primary platform and see nothing wrong.

DMARC: what happens when the first two disagree?

Here is where this stops being technical and becomes a business decision.

DMARC does two things. It tells receiving providers what to do with mail that fails SPF and DKIM, and it sends you reports on what is being sent using your domain.

The policy has three settings. p=none means take no action and simply report. p=quarantine means put the message in spam. p=reject means refuse it outright, so it never reaches the recipient at all.

Read that last one again. It does not mean flag, and it does not mean mark. The message is destroyed and your recipient never learns it existed.

Why does DMARC break people's mail?

Because they reach for p=reject first, and it is easy to see why. It looks like the strong choice. It is what the security articles recommend.

It is also an instruction to the entire internet to destroy any mail that fails your checks. You issue it at the exact moment you are least certain your checks are right.

Remember those six sending tools you could only name four of? Two of them are now being rejected everywhere. Your invoices, your booking confirmations and your password resets are disappearing silently, and no bounce arrives in your inbox to tell you.

The DMARC policy is not a security score. It is a switch that decides whether your mail gets delivered. Treat it like one.

What is the right order to set them up in?

Work through this sequence and do not skip ahead. Each step depends on the one before it being correct.

One, inventory every sender. List every tool that sends email as your domain. It takes an hour, almost everyone skips it, and you cannot authenticate senders you have never listed.

Two, publish SPF and check the lookup count. Name every sender from step one and confirm you are under ten lookups.

Three, turn on DKIM in every platform. Not just the largest one. Work from the same list.

Four, publish DMARC at `p=none`. This changes nothing about delivery, and that is the point. It switches on the reporting you need before you can safely change anything else.

Five, read the reports for two weeks. They will show you senders you forgot, because they always do. Fix each one.

Six, move to `p=quarantine` once the reports come back clean, and watch for another two weeks.

Seven, move to `p=reject`, and only after quarantine has run clean.

Six weeks, roughly. Is that slower than you wanted? It is, and the alternative is finding out which system was misconfigured by watching your customers stop hearing from you.

Does authentication fix deliverability?

No. Authentication proves you are who you claim to be, and it does not make you welcome.

A properly verified sender with poor engagement still lands in spam. Reputation is built from what your subscribers do with your mail, not from what your DNS says about you.

It works like a passport at the door. It gets you inside. It does not make anyone pleased to see you.

The eight sending practices that decide whether mail lands, covering volume consistency, list hygiene and warm-up among others, sit on top of authentication. They start mattering more once the records are right. Get the records correct so the question stops being asked, then do the work that decides whether anyone wants the mail.

Start here

Open your DNS today and write down what is already published. Most people find an SPF record from three years ago, DKIM missing on half their tools, and no DMARC at all.

That inventory is step one. It decides whether the rest of this goes smoothly or takes your mail offline for a day.