SPF, DKIM and DMARC: how to set them up, step by step

In short

SPF lists the servers allowed to send email for your domain, DKIM signs every message, and DMARC tells receiving servers what to do with mail that fails those checks and where to send reports. All three are DNS records you publish with your domain's DNS provider. Without them your emails end up in spam and anyone can spoof your domain; Gmail and Yahoo have required them from bulk senders since 2024.

When a small business tells me their store's emails land in spam, or that someone is sending fake invoices “from” their domain, one of these three records is almost always missing or mistyped. They are three lines of text in your DNS. This guide explains what each one does, how to check yours in a minute and in what order to turn them on so you don't lose legitimate email along the way.

By Jose SorianoLast updated: October 24, 20265 min read

What each one does

SPF (Sender Policy Framework): the list of servers allowed to send email for your domain. It is a TXT record at the root of the domain that starts with v=spf1.
DKIM (DomainKeys Identified Mail): a cryptographic signature your email provider adds to every message. The receiving server checks the signature against a public key you publish in DNS, so it knows the message has not been altered and that your domain signed it.
DMARC: ties the other two together. It tells the receiving server what to do with an email that claims to come from your domain and does not pass aligned SPF or DKIM (let it through, send it to spam or reject it), and where to send you reports.

The key word is alignment: for DMARC it is not enough for a message to pass SPF or DKIM; the domain that passes the check has to match the one the recipient sees in the From address. An email sent by a newsletter platform with its own domain can pass SPF and still fail DMARC.

How to check yours

From a terminal (on Windows, nslookup does the same job):

dig +short TXT your-domain.com            # SPF: the line starting with v=spf1
dig +short TXT _dmarc.your-domain.com     # DMARC
dig +short TXT selector._domainkey.your-domain.com   # DKIM: your provider gives you the selector

nslookup -type=TXT _dmarc.your-domain.com

The free scan checks all three at once, along with the rest of the website, and tells you what is missing. To see whether a specific email passes, send one to a Gmail account and open Show original: you will see SPF: PASS, DKIM: PASS and DMARC: PASS, or whatever fails.

Step 1: SPF, a single record

List everything that sends email with your domain: your mailbox (Google Workspace, Microsoft 365, your hosting's email), the store or website (order notifications, forms), your newsletter tool and your invoicing software. Each one tells you what to add. An example with Google Workspace and Brevo:

v=spf1 include:_spf.google.com include:spf.brevo.com ~all

One SPF record per domain. If there are two v=spf1 lines, the whole SPF fails. It is the mistake I see most often, usually after switching providers and adding the new one without removing the old one.
At most 10 DNS lookups. Every include, a, mx and redirect counts, and the providers' includes trigger more lookups of their own. Above 10, the result is a permanent error. Remove the providers you no longer use before adding another.
~all or -all at the end. ~all marks anything not on the list as suspicious; -all asks for it to be rejected. With DMARC in place, ~all is the usual choice. Never +all: it authorizes anyone.

Step 2: DKIM, in every provider

You don't write DKIM by hand: you turn it on in the dashboard of each service that sends email, which gives you one or more records (TXT or CNAME) with a name like selector._domainkey. You publish them in your DNS and go back to the dashboard to click “verify”. Do it in every service that sends with your domain, not just your main mailbox: the newsletter tool and the website too.

Step 3: DMARC, from monitoring to rejecting

Start with a record that only monitors and asks for reports:

_dmarc.your-domain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@your-domain.com"

p=none for two to four weeks. It changes nothing about delivery, but the big providers send you a daily XML report of who sent email with your domain and whether it passed SPF and DKIM. There are free services that turn them into readable tables.
Fix what shows up. Every legitimate service that appears failing needs its SPF or its DKIM. Anything you don't recognize is often someone spoofing your domain: exactly what DMARC is going to cut off.
p=quarantine. Whatever fails goes to the spam folder. If you want a trial period, add t=y: it asks receivers to apply the policy one level below while you review. It replaces the old pct= tag, which the current version of DMARC (RFC 9989) has retired.
p=reject. Whatever fails is rejected. That is the goal for a domain that sends email once you have it under control.

Here is how it goes with my own domain: webintacta.com sends through an authenticated transactional service (SPF and DKIM aligned) and has DMARC at p=quarantine, after a stage at p=none reading the reports; the next step is p=reject. There is no shortcut: jumping straight to reject without reading the reports is the fastest way to stop receiving replies to your quotes.

Domains that don't send email

If you have domains you don't use to send email (the one that redirects to your main domain, the one from an old campaign), protect them too, because they are favorites for spoofing. Two records are enough:

your-other-domain.net          TXT  "v=spf1 -all"
_dmarc.your-other-domain.net   TXT  "v=DMARC1; p=reject"

Why it is no longer optional

Since February 2024, Gmail requires SPF or DKIM from everyone who sends it email, and anyone who sends more than 5,000 messages a day to Gmail accounts must also have SPF, DKIM and DMARC aligned; Yahoo applies equivalent requirements, and Microsoft (Outlook.com, Hotmail) announced its own for bulk senders in 2025. A small business doesn't reach those volumes, but spam filters reward senders who comply and penalize those who don't: you notice the difference in the inbox.

On top of that, without DMARC anyone can send an email with your domain as the sender. It is the basis of the fake invoice scam (“we have changed bank accounts”) that hits so many small businesses. And if your domain ends up on a spam blacklist, what to do is in domain blacklisted.

Sources

RFC 7208: SPF (10 DNS lookup limit, section 4.6.4)
RFC 6376: DKIM
RFC 9989: DMARC (replaces RFC 7489; t and np tags)
Google: email sender guidelines
Yahoo: sender requirements

Frequently asked questions

What is the difference between SPF, DKIM and DMARC?

SPF authorizes servers to send with your domain, DKIM signs each message to prove it is yours and has not been altered, and DMARC says what to do with emails that don't pass those checks aligned with your domain and where to send reports. You need all three.

Can I have two SPF records?

No. With two records starting with v=spf1, the whole SPF fails. Merge all the includes into a single line and remove the providers you no longer use.

Does p=none protect anything?

It doesn't block anything: it only gives you reports. It is the first step, to find out who sends with your domain before moving to p=quarantine and then to p=reject.

My website's emails go to spam. Is this why?

It is the most common cause. Check that the store sends through authenticated SMTP (not PHP's mail()), that the service is in your SPF and has DKIM turned on with your domain, and that a DMARC record exists. If it still fails, check whether the IP or the domain is on a blacklist.

Where do I set up these records?

In your domain's DNS zone, in the dashboard of whoever manages your DNS (your registrar, your hosting provider or Cloudflare). Not in WordPress or PrestaShop.