DNS hosting and email authentication: getting SPF, DKIM and DMARC records right

SPF, DKIM and DMARC are often discussed as though they were features of your email platform. They are not. All three are published in the Domain Name System (DNS), and the majority of authentication problems we see are not policy mistakes at all. They are DNS mistakes: a record in the wrong place, a typo in a hostname, a truncated key, or a change made at the wrong provider.

This guide explains where each record lives, the difference between record types, and the practical errors that quietly break authentication. It assumes you know what SPF, DKIM and DMARC do. If you need a refresher, start with What is SPF? and What is DKIM?

Where your DNS actually lives

Your domain has a set of authoritative nameservers. Whichever provider those nameservers point to is where your DNS records are edited. This is often not the company you bought the domain from, and it is often not your email provider.

Common patterns we see:

• Domain registered with one registrar, but nameservers delegated to Cloudflare, so records must be edited in Cloudflare.
• Domain using the registrar's own DNS, so records are edited in the registrar's control panel.
• Nameservers pointing at a web host, so DNS is managed alongside the website.

Before you publish anything, confirm where your authoritative DNS is. Editing records in the wrong control panel is one of the most common reasons a change appears to have no effect. If you edit records at your registrar but your nameservers point to Cloudflare, nothing you change will ever take effect.

The three records and where each one goes

SPF: a TXT record on the root domain

SPF is a single TXT record published at the root of your domain (for example, example.co.uk). It begins with v=spf1 and ends with a policy such as -all or ~all.

Two rules matter here. First, you may only have one SPF record per domain. Two separate v=spf1 TXT records is a hard error and SPF will fail. Second, the record is subject to a limit of ten DNS lookups. Exceed it and SPF returns a permanent error. The full specification is set out in RFC 7208. If you are near the limit, see our guidance on checking your record in how to check an SPF record.

DKIM: usually a CNAME, sometimes a TXT record

DKIM is published at a selector-specific hostname, in the form selector._domainkey.example.co.uk. The selector is chosen by your sending platform.

How you publish it depends on the provider. Microsoft 365 and many managed platforms ask you to create CNAME records that point back to their infrastructure, so they can rotate keys without you touching DNS again. Others, such as some marketing tools, give you a long TXT record containing the public key directly.

The most frequent DKIM mistake is publishing the wrong record type. If your provider gives you a CNAME target, create a CNAME. If it gives you a TXT value, create a TXT. Mixing them up produces a record that resolves but never validates.

DMARC: a TXT record on a fixed subdomain

DMARC lives in a TXT record at the fixed hostname _dmarc.example.co.uk. It begins with v=DMARC1 and carries your policy and reporting addresses. The tags are covered in full in DMARC record syntax explained.

Unlike SPF, DMARC does not sit at the root. A DMARC record placed on the root domain instead of the _dmarc host will simply be ignored.

The DNS mistakes that break authentication

The console adds the domain for you (or does not)

Some DNS control panels expect the hostname only. If you enter _dmarc.example.co.uk the panel appends the domain again, producing _dmarc.example.co.uk.example.co.uk. Others expect the full name. Check how a working record already displays in your panel, and match that convention. This single issue causes a large share of records that look correct in the editor but cannot be found by resolvers.

Quotation marks and smart quotes

Long TXT values are sometimes wrapped in quotation marks. Most panels handle this cleanly, but pasting from a document can introduce curly "smart quotes" instead of straight ones, which corrupt the record. Paste into a plain text editor first if you are unsure.

Truncated DKIM keys

DKIM public keys are long. Some interfaces split them, and a copy-paste that drops the final characters leaves a key that resolves but fails every signature check. Always verify the published key matches the source exactly.

Splitting a TXT record incorrectly

A single DNS TXT string is limited to 255 characters. Longer values, such as some DKIM keys, must be split into multiple quoted strings within one record. Most panels do this automatically. If yours does not and you split manually, the strings must be concatenated with no added spaces or characters.

Duplicate and leftover records

Old SPF includes from a decommissioned platform, a second stray v=spf1 record, or an outdated DKIM selector left in place after a migration all cause failures. Treat DNS clean-up as part of every email change, not an afterthought.

TTL: why your change has not taken effect yet

Every DNS record has a Time To Live (TTL), which tells resolvers how long to cache it. If your TTL is set to 3600 seconds, a change can take up to an hour to propagate; some records are cached longer.

Two practical points follow. Before making a planned change, lower the TTL a day in advance so the update propagates quickly. And when you test a change, remember that you may still be seeing a cached copy. Waiting is often the answer, not making further edits.

How to check your work

Do not rely on the DNS panel showing the record. Query it independently. On any machine you can run a command line lookup, for example dig TXT _dmarc.example.co.uk or nslookup -type=TXT _dmarc.example.co.uk, to see what resolvers actually return. This is the only reliable confirmation that your record is live and correct.

The NCSC email security guidance sets out the expected configuration for SPF, DKIM and DMARC and is a useful reference point for what "correct" looks like.

A sensible order of operations

When setting up authentication from scratch, publish in this order:

• Confirm where your authoritative DNS lives.
• Publish SPF (one TXT record, within the lookup limit).
• Publish DKIM using the record type your platform specifies, and confirm the key matches exactly.
• Publish DMARC at p=none with a reporting address, so you can see what is happening before you enforce.
• Verify every record with an independent lookup, not just the DNS panel.

DNS is unforgiving in that a record is either exactly right or it does not work, and it rarely tells you which. Most authentication failures trace back to one of the mistakes above rather than to anything wrong with your policy. If you would like an independent read on how your records are actually resolving, our free health check queries them the way a real receiver does and reports what it finds.