SPF, DKIM and DMARC: what they do and how to set them up

The short version

• SPF lists the servers allowed to send email for your domain. DKIM adds a digital signature that proves a message came from you. DMARC tells inboxes what to do when a message fails both, and sends you reports.
• All three are TXT records (short lines of text) in your domain’s DNS. Your email provider gives you the values; you paste them in where your DNS is managed.
• Gmail and Yahoo have required SPF or DKIM from every sender since February 2024. Bulk senders need all three. Since May 5, 2025, so do domains sending more than 5,000 emails a day to Outlook.com (Microsoft’s support page says 5,000 or more).
• The three classic mistakes: two SPF records, more than 10 lookups in SPF, and starting DMARC at p=reject.

What each record does

SPF: who may send

SPF (Sender Policy Framework) is one TXT record at the root of your domain. It names the mail services allowed to send as you. Google Workspace’s record looks like this:

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

The ending matters. ~all is a “softfail”: mail from an unlisted server is probably not yours, and the standard says inboxes should not reject it on that alone. -all is a “fail”: an unlisted server is not allowed, period. Google recommends ~all. Microsoft recommends -all for Microsoft 365, because it also expects you to set up DKIM and DMARC.

DKIM: a signature on every message

DKIM (DomainKeys Identified Mail) signs each message with a private key your email provider keeps. Inboxes check the signature against a public key you publish in DNS, under a “selector” name such as google._domainkey.example.com. If the message was changed on the way, the check fails.

Your provider generates the key. You only copy the record it shows you. Pick a 2048-bit key if you are offered one: the DKIM standard (RFC 8301) and Google both recommend it, and Gmail requires at least 1024 bits.

DMARC: the policy and the reports

DMARC is a TXT record at _dmarc.example.com. It checks that the domain in the visible From line matches the domain SPF or DKIM approved (this is called alignment), then tells the inbox your policy. A safe first record:

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

• p=none: monitor only. You state no preference for failing mail.
• p=quarantine: you consider failing mail suspicious. Microsoft 365, on its recommended setting, sends it to Junk.
• p=reject: failing mail is a clear sign someone is using your domain without permission. It can be refused outright.
• rua: where daily summary reports go. Google says it is optional but recommends always including it, sent to a separate mailbox, group or report service, because there can be many reports.

Google Workspace and Microsoft 365 values

These come from each company’s own setup pages. Your DKIM key itself is unique, so copy it from your admin console.

Using Zoho Mail? Its SPF value is v=spf1 include:zohomail.com -all, with a ~all version for domains that also send through other servers.

Set them up in order

1. List everything that sends as your domain. Your mailbox, newsletter tool, website contact form, booking or invoicing apps. Each one needs to be covered by SPF or DKIM. Website forms are a common gap; see why website form emails go missing.
2. Find where your DNS is managed. It is usually your domain registrar, unless you pointed the domain to Cloudflare, your host or a builder. Records added anywhere else do nothing.
3. Add one SPF record. Create a TXT record with Host or Name @ and your provider’s value. If a second service needs SPF, add its include to the same record (see the mistakes below).
4. Turn on DKIM. In Google Workspace or Microsoft 365, open the DKIM setting, copy the record it gives you, add it in DNS, then come back and start signing. Do the same in your newsletter tool if it offers DKIM for your domain.
5. Wait, then add DMARC at p=none. Google advises waiting 48 hours after SPF and DKIM. Add a TXT record with Host _dmarc and a value like the example above, with your own report address.
6. Check your results. Send a test message and confirm SPF, DKIM and DMARC all show “pass”. Our email deliverability hub has a 10-minute self-check.
7. Tighten over time. Once reports show only your own services sending and passing, move to p=quarantine, then p=reject. Microsoft suggests leaving your main (parent) domain for last if you also use subdomains.

Where to add the records

The steps at five common DNS providers, from their help pages. The record type is TXT for SPF, DMARC and Google’s DKIM; Microsoft 365’s DKIM records are CNAMEs.

Cloudflare’s help also points to its Email security Wizard as the recommended way to create these records. How long it takes: Namecheap says new records usually work in about 30 minutes (on its BasicDNS, PremiumDNS or FreeDNS). GoDaddy says most changes take effect within an hour but can take up to 48 hours.

The classic mistakes

Two SPF records

A domain may have only one SPF record. Two records make SPF return a permanent error (“permerror”), so SPF does not pass. It often happens when a new tool’s guide says “add this SPF record” and you add it next to the old one.

The fix: merge them into one line, with each service’s include before the ending, for example:

v=spf1 include:_spf.google.com include:[newsletter tool's value] ~all

More than 10 lookups

The SPF standard (RFC 7208) allows at most 10 terms that make DNS look something up: include, a, mx, ptr, exists and redirect. Plain IP addresses (ip4, ip6) and all do not count. Go over and SPF fails with a permanent error.

Google’s help phrases this as “up to 10 include: tags”. The standard is stricter: the limit counts all lookup terms together, including the ones hidden inside each include. If you use many sending tools, remove the ones you no longer use first.

Starting DMARC at p=reject

Both Google and Microsoft say to start at p=none. If you jump to reject before every sender passes, your own invoices, forms or newsletters can be refused. Watch the reports for a while, then step up.

DMARC has a new standard: RFC 9989

As of October 2026, the current DMARC standard is RFC 9989, published in May 2026 by the IETF. It replaces RFC 7489, the original 2015 document. Reports moved to two companion documents, RFC 9990 and RFC 9991.

The change most people will notice is pct, the tag that applied your policy to only a percentage of mail. RFC 9989 removed it. The registry now lists pct as historic and adds a new t tag for “DMARC policy test mode”.

Here is the conflict: Google’s and Microsoft’s DMARC setup pages still cite RFC 7489 and suggest using pct, and Google’s BIMI (inbox logo) setup still requires pct=100. For most small businesses this changes little. You do not need pct to move from none to quarantine to reject in steps, which is what both companies advise. If you set up BIMI, follow Google’s current BIMI page.

Next: the Gmail, Yahoo, Outlook and iCloud sender rules, a spam fix checklist, or when to hire help. For email at your own domain in general, see websites and email and the email hosting glossary entry.

Sources: Standards: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 8301 (DKIM keys), RFC 9989 (DMARC), RFC 9989 status. Google: set up SPF, set up DKIM, set up DMARC, set up BIMI, Gmail sender guidelines. Microsoft: SPF, DKIM, DMARC, Outlook.com sender policies. Yahoo: sender best practices. Zoho: SPF configuration. DNS providers: Cloudflare (and record types), Namecheap, GoDaddy, Squarespace, Porkbun.