SPF DKIM DMARC Setup: A Business Email Guide

By Next Level Web Solutions · · 7 min read · Hosting, domains and email

SPF, DKIM and DMARC are three DNS records that prove your business emails are genuinely from you, and a correct SPF DKIM DMARC setup is the most reliable technical fix when legitimate email keeps landing in spam. SPF lists who may send for your domain, DKIM signs each message, and DMARC tells receiving mail servers what to do when a message fails those checks.

This guide explains each record in plain language and gives you a safe order to set them up, so you do not accidentally block your own email.

SPF DKIM DMARC setup: why legitimate email lands in spam

Email was designed in an era when anyone could claim to be anyone. Spammers and scammers still exploit this by sending messages that pretend to come from your domain. To defend users, big mailbox providers such as Gmail and Outlook check whether a message can be proven to come from where it says it does.

If your domain has no authentication records, your messages look the same as a forgery. Business email going to spam is common in exactly these situations:

  • You moved to a new email provider but never updated your records.
  • A newsletter tool, invoicing system or website contact form sends email "from" your domain without being authorised.
  • You send from a free address through a service that does not match the domain.
  • Your records exist but conflict with each other.

Authentication is not the only factor. Content, sending volume, complaints and your domain's reputation all matter too. But missing records are the easiest part to fix. Since February 2024, Google and Yahoo have required senders of bulk email (Google's threshold is about 5,000 messages a day to Gmail) to have SPF, DKIM and Domain-based Message Authentication, Reporting and Conformance (DMARC) in place, and to support one-click unsubscribe on marketing mail.

Before you touch anything, make sure you know where your domain name system (DNS) is managed. Our guide to DNS records explained for business owners covers that, and the basics of mailbox setup are in our business email setup guide.

SPF: who may send for your domain

SPF stands for Sender Policy Framework. It is a single DNS text (TXT) record that lists the services allowed to send email on behalf of your domain. A receiving server looks at the sending server and checks it against your list.

A simple example for a domain that only uses Google Workspace looks like this:

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

Reading it left to right: it is an SPF record, it includes Google's approved servers, and anything else is treated as a soft fail. Your provider will give you the exact include value to use, so copy it from their instructions rather than from an example.

To build your own record:

  1. List every service that sends email using your domain: your mailbox provider, your newsletter tool, your invoicing or booking system, your website's contact form.
  2. Add the include value each one tells you to use.
  3. Publish one record on the root of your domain.

SPF has a limit of ten DNS lookups, so a record stuffed with too many includes can quietly break. Keep the list to services you really use.

DKIM: signing your messages

DKIM stands for DomainKeys Identified Mail. Your email service attaches a digital signature to each outgoing message. The matching public key is published in your DNS, usually as a TXT or canonical name (CNAME) record with a name such as `selector._domainkey`. The receiving server uses it to confirm the message was not altered and really came from an authorised sender.

You do not create the key yourself. In Google Workspace you generate it in the admin console, and Microsoft 365 gives you the records to publish. Newsletter and invoicing tools each provide their own DKIM records too, and you add all of them. After publishing, go back to the provider and switch signing on, because in some systems the record alone does nothing.

DMARC: policy and reports

DMARC ties SPF and DKIM together. It tells receiving servers what to do with a message that fails authentication, and it sends reports so you can see who is sending as your domain.

A starter record, published as a TXT record at `_dmarc.yourdomain.co.za`, looks like this:

`v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.co.za`

  • `p=none` means monitor only. Nothing is blocked.
  • `p=quarantine` asks servers to treat failures as suspicious, typically by sending them to spam.
  • `p=reject` asks servers to refuse failing messages outright.
  • `rua` is the address that receives aggregate reports.

The reports are XML files that are unpleasant to read by hand. Many business owners use a free or low-cost DMARC report reader to turn them into a plain list of senders.

Safe rollout order starting with p=none

The danger with DMARC is moving to a strict policy before every legitimate sender is accounted for. A safe order is:

  1. Take stock. Write down every service that sends email as your domain.
  2. Publish SPF with all of those services included.
  3. Enable DKIM for the main mailbox provider, then for each additional sender.
  4. Publish DMARC with p=none and a reporting address.
  5. Watch reports for a few weeks. Look for senders you forgot, such as an old customer relationship management (CRM) or a website plugin.
  6. Fix each legitimate sender until it passes SPF or DKIM in a way that aligns with your domain.
  7. Move to p=quarantine, ideally at a partial percentage first if your provider supports it, and watch for problems.
  8. Consider p=reject once you are confident everything legitimate passes.

Many small businesses stop happily at quarantine. Reject offers stronger protection against spoofing, but only matters if you are comfortable the setup is complete. If you are unsure, ask someone who manages email for a living.

Testing your setup

After each change:

  • Send a test email from every system that sends as your domain to a Gmail and an Outlook address.
  • In Gmail, open the message, choose "Show original" and look for PASS next to SPF, DKIM and DMARC.
  • Use a reputable free online record checker to confirm your records are published correctly.
  • Allow time for DNS changes to propagate before you decide something failed.

Keep a note of what you changed and when, so you can reverse a single step if something unexpected happens.

Common mistakes such as two SPF records

These are the problems we see most often described by site owners:

  • Two SPF records. A domain must publish only one. If you add a second for a new service, receivers may treat both as invalid. Merge them into one record that lists everything.
  • Using `-all` too early. A hard fail setting can reject genuine mail from a service you forgot. Start with soft fail.
  • Forgetting website forms. Contact forms that send "from" your own domain through the web server often fail authentication. Route them through your proper mail provider.
  • Pasting a record with extra spaces or quotes. Some DNS panels add quotation marks for you. Do not duplicate them.
  • Changing DNS in the wrong place. If nameservers point elsewhere, the records you edit have no effect.
  • Moving to p=reject without reading reports. This is how a quote request never reaches a customer.

If you would prefer to hand this over, we set up email authentication as part of our hosting and domains work. See our services or contact us and we will review your current records.

Frequently asked questions

Why do my emails go to spam?

Missing or broken SPF, DKIM and DMARC records are a common cause, alongside message content and your sending reputation. Fix authentication first, then look at content and volume.

Can I have two SPF records?

No. Publish one SPF record that lists all your senders. Having two can cause receivers to ignore both.

Will DMARC stop all fake emails pretending to be me?

A strict DMARC policy greatly reduces direct spoofing of your exact domain, but it cannot stop look-alike domains or every kind of phishing. Treat it as one layer of protection.

Do I need DMARC if I only send a few emails?

It is still worth publishing a basic p=none record. It costs nothing and gives you visibility. Strictly, DMARC is mandatory only for bulk senders under Google's and Yahoo's rules, but a basic record is a sensible default for any domain.

  • How to Register a .co.za Domain Name
    How to register a .co.za domain in South Africa: pick a name, search through an accredited registrar, give owner details and keep control of your domain. (7 min read)
  • How to Create a Business Email Address
    How to create a business email address on your own domain: Google Workspace or Microsoft 365, MX records, verifying the domain and securing every mailbox. (8 min read)
  • Web Hosting South Africa: Local vs Overseas
    Local or overseas web hosting for a South African business? Compare latency, support hours, rand billing, CDNs and when each option makes sense for you. (7 min read)

Want this done for your business?

Book a free call →