How to set up SPF, DKIM and DMARC (in plain language)

If you send cold email without these three records, a large share of it will be filtered no matter how good the message is. They are DNS entries you add once per sending domain, and together they let a receiving server verify that mail claiming to be from you really is.

What each one does

SPF — who is allowed to send

A list of the servers permitted to send mail for your domain. A receiving server looks up the list and checks whether the mail arrived from one of them.

Type:  TXT
Name:  @            (your root domain)
Value: v=spf1 include:_spf.google.com ~all

The include: part depends on who sends your mail — _spf.google.com for Google Workspace, spf.protection.outlook.com for Microsoft 365. If several services send for you, they go in one record, not several: a domain may only have one SPF record.

~all means "anything else is suspicious" (softfail); -all means "reject anything else" (hardfail). Start with ~all until you are sure every legitimate sender is listed.

DKIM — a signature proving nothing was altered

Your mail server signs each message with a private key; the matching public key sits in DNS. If the signature validates, the receiver knows the message is genuinely yours and was not modified in transit.

You do not write a DKIM record by hand. Your provider generates it — in Google Workspace it is under Apps → Google Workspace → Gmail → Authenticate email. It gives you a selector and a long key to paste in as a TXT record:

Type:  TXT
Name:  google._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSq...   (the long key)

Generating the key is not enough — you have to click Start authentication in the provider afterwards, which is where people usually stall.

DMARC — what to do when a check fails

DMARC ties the other two together and tells receivers what you want done with mail that fails them. It also gives you reports.

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The policy p is the important part:

• p=none — monitor only. Nothing is rejected; you just get reports. Start here.
• p=quarantine — failing mail goes to spam.
• p=reject — failing mail is refused outright. The strongest setting.

Go to p=none first, read the reports for a couple of weeks until you are sure all your legitimate mail passes, then move up. Jumping straight to p=reject with a misconfigured SPF record will silently kill your own invoices and notifications.

Checking your work

DNS changes take anywhere from minutes to a few hours. From a terminal:

dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT google._domainkey.yourdomain.com

Or send a message to a mailbox you control and look at the original: Gmail shows SPF: PASS, DKIM: PASS and DMARC: PASS in the message details.

The mistakes that come up most

• Two SPF records. Only one is allowed; a second invalidates both. Merge the includes.
• Too many DNS lookups. SPF allows ten; chaining several include: entries quietly exceeds it and the record stops evaluating.
• DKIM generated but never switched on in the provider console.
• Jumping to p=reject before checking reports.
• Forgetting a sender. Your CRM, invoicing tool and help desk all send as you and all need to be in SPF.

How RichLead handles this

RichLead re-checks SPF, DKIM and DMARC for each of your sending domains on a schedule and flags it when something changes — an SPF record edited past the lookup limit, a DMARC policy reverted to p=none, a DKIM selector rotated away. These are the changes that quietly undo months of warm-up, and they are easy to miss because nothing visibly breaks.

The Deliverability page shows the current status per domain and what to fix.