How to Set Up SPF, DKIM, and DMARC for a Small Business

If your business sends email from a custom domain and you’ve never touched SPF, DKIM, or DMARC, three things are happening that you might not realize. Some of your legitimate email is going to spam. Spammers are spoofing your domain to phish your customers. And starting in 2024, both Google and Yahoo began rejecting bulk email from any domain that hadn’t published these records — a policy that has only tightened since.

The good news: setting all three up is a one-time job, takes about 30 minutes, and uses tools you already have if you run Microsoft 365 or Google Workspace.

Here’s the practical version.

What Each Record Does

These are three DNS TXT records that publish information about your email. None of them prevents your email from being sent. They tell receiving servers how to evaluate it.

SPF (Sender Policy Framework)

SPF lists the IP addresses and servers allowed to send email from your domain. When mail arrives claiming to be from [email protected], the receiver checks the SPF record at yourbusiness.com to see if the sending server is on the approved list.

SPF protects the envelope sender (the address servers use to bounce mail), not the address users see. It’s the easiest record to set up and the easiest to break.

DKIM (DomainKeys Identified Mail)

DKIM cryptographically signs every outgoing message. Your email provider holds a private key; you publish the matching public key in DNS. Receiving servers verify the signature, which proves the message came from your domain and wasn’t modified in transit.

DKIM protects the message body and key headers, including the From: address. It’s slightly more complex to set up because the key is generated by your provider, but you don’t have to manage it after the initial setup.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together and tells receivers what to do when both fail. Without DMARC, a failed SPF or DKIM check is a hint to the receiver. With DMARC, you instruct the receiver to reject, quarantine, or report unauthenticated mail claiming to be from your domain.

DMARC also gives you reports — emails sent back to a mailbox you specify, listing every server that’s tried to send mail as you. This is how you discover that your customer relationship manager, your accountant’s billing tool, and a marketing service you forgot about are all sending mail on your domain.

Step 1 — Find Out What’s Already Sending Email

Before you publish anything, list every service that sends email “from” your domain:

Your primary email host (Microsoft 365, Google Workspace, Zoho)
Marketing platforms (MailChimp, Mailerlite, Constant Contact, Sendgrid)
Transactional email senders (Stripe, Shopify, your CRM, your ticketing system, your invoicing tool)
On-premise mail servers, if you still have one
Anything that emails customers from a [email protected] address

Miss one and your SPF will reject its mail. Take 15 minutes to check your billing and integrations before you start.

Step 2 — Publish an SPF Record

SPF is a single TXT record at the apex of your domain (the root, e.g. yourbusiness.com).

The syntax looks like this:

v=spf1 include:_spf.google.com include:spf.mailerlite.com -all

Breaking it down:

v=spf1 — version
include:_spf.google.com — defer to Google’s published list (used for Google Workspace)
include:spf.mailerlite.com — defer to Mailerlite’s list
-all — hard fail any sender not listed

Include the right include: for your provider. Common ones:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
Zoho Mail: include:zoho.com
Mailchimp: include:servers.mcsv.net
SendGrid: include:sendgrid.net

Add an include: for every legitimate sender. End with -all (hard fail) once you’re sure the list is complete; use ~all (soft fail) during initial rollout if you’re worried about missing something.

The 10-lookup limit: SPF allows a maximum of 10 DNS lookups per record. Each include: typically counts as one to three. Running over 10 makes the record permanently fail. Tools like dmarcian.com or mxtoolbox.com will show you the lookup count.

Publish exactly one SPF record at the apex. Two records means neither is valid.

Step 3 — Set Up DKIM

DKIM setup happens in your email provider’s admin console. You don’t author the key — the provider generates one and gives you a CNAME or TXT record to publish.

Google Workspace

Admin Console → Apps → Google Workspace → Gmail → Authenticate email
Click Generate new record, choose 2048-bit key, leave selector as default
Google gives you a TXT record with name google._domainkey.yourbusiness.com and a long value starting with v=DKIM1; k=rsa; p=...
Publish the TXT record at your DNS provider
Wait 5-15 minutes for propagation, then click Start authentication in the admin console

Microsoft 365

Microsoft 365 Defender → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM
Select your domain, click Create DKIM keys
Microsoft gives you two CNAME records (selector1 and selector2)
Publish both at your DNS provider
Return to the DKIM page and toggle “Sign messages for this domain with DKIM signatures” to On

Other Senders

Marketing and transactional providers typically have their own DKIM setup. MailChimp, SendGrid, Mailerlite, and similar tools have a settings page that gives you CNAME records to publish on your domain. Set them up before you switch DMARC to enforcement.

Step 4 — Publish DMARC in Monitor Mode

This is the step most people skip and regret. Start in monitor mode. Don’t go straight to reject.

Publish a TXT record at _dmarc.yourbusiness.com:

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

p=none — monitor only, don’t change delivery
rua=mailto:... — where to send aggregate reports
pct=100 — apply to 100% of mail

Use a real mailbox for rua=. Reports arrive daily from major providers and look like XML attachments. They’re hard to read raw — sign up for a free tier of dmarcian.com, postmark.com, or valimail.com to parse them. Within a week you’ll have a clear picture of every server sending as you.

Move to Quarantine, Then Reject

After 2-4 weeks of monitor mode and after you’ve fixed any legitimate senders that are failing:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25

Quarantine sends failing mail to spam. Start at pct=25 and ramp up to 100 over a couple of weeks. Watch the reports for fallout.

Once quarantine is at 100% with no legitimate failures:

v=DMARC1; p=reject; rua=mailto:[email protected]

Reject is the goal. It tells receivers to bounce unauthenticated mail outright. Spoofers stop being able to impersonate your domain entirely.

Common Mistakes

Two SPF records — only one is valid. If you set up a second when adding a new sender, both fail. Edit the existing record.
Stale include: — leftover entries from services you no longer use. Clean these out; they count toward the 10-lookup limit.
Going to p=reject immediately — common in tutorials, but it can dump weeks of legitimate mail. Always start at p=none.
Forgetting subdomains — DMARC at the apex doesn’t automatically protect marketing.yourbusiness.com. Either publish a separate DMARC record for the subdomain, or use the sp= tag in your apex record to set subdomain policy.
Using a personal mailbox for rua= — DMARC reports flood in. Use a dedicated address or a third-party aggregator.

What This Buys You

Significantly fewer of your emails landing in customers’ spam folders
Spammers can no longer spoof your domain to phish your customers, vendors, or employees
Compliance with the 2024+ Google and Yahoo bulk-sender requirements
Visibility, via reports, into every service sending mail as you

If your business runs on a custom domain and these records aren’t set up, you’re losing inbox placement and accepting unbounded reputational risk for the cost of about 30 minutes of admin work. There’s no good reason to skip it.