DNS records for your domain
Every record we ask for, what each one does, how to type it at your DNS provider, and what Found, different or Not found yet means.
Connecting your own domain means adding records at whoever runs its DNS. There are ten in all, in three groups: one to prove the domain is yours, five to move your mail, and four optional ones worth having.
Every record, with its exact value and a Copy button beside it, is on the setup screen and afterwards under Your domain → DNS records. Copy the values from there rather than typing them from here — two of them are unique to your domain and cannot be written down in an article.
Two values of ours you will paste
The records point at us, so they contain two of our host names. The screen shows the real ones; below they are written as placeholders:
| Placeholder | What it is | Where it is used |
|---|---|---|
<mail host> |
The mail server your MX record names | The MX record |
<records domain> |
The domain our DKIM, key-directory and policy records live under | The SPF include and the four CNAMEs |
<report address> |
The mailbox that receives DMARC and transport-security reports | The DMARC and TLS-RPT records |
All three are shown in full, ready to copy, on the records screen in the app.
The one rule that catches everybody: the name field
Nearly every DNS provider wants only the part before your domain in the name (or "host") field, and adds the domain itself for you. A few want the whole name. The app shows you the whole name; shorten it to match your provider.
For yourname.com, that means:
| The whole name | What most providers want |
|---|---|
_privateki.yourname.com |
_privateki |
yourname.com (the domain itself) |
@ |
pki1._domainkey.yourname.com |
pki1._domainkey |
_dmarc.yourname.com |
_dmarc |
_smtp._tls.yourname.com |
_smtp._tls |
If your provider does want full names, you will see the domain repeated after you save — _privateki.yourname.com.yourname.com is the classic symptom of putting the whole name in a field that wanted the prefix. Fix it by shortening the name field.
Leave the TTL at whatever the provider offers by default. Automatic, 300, 3600 — none of it matters here.
1. Prove the domain is yours
| Name | Type | Value |
|---|---|---|
_privateki.yourname.com |
TXT | privateki-verify= followed by a token unique to your domain |
Proves to us that you control the domain. Nothing else happens until it is there.
Once the domain is connected you may remove it, and leaving it in place does no harm. If you later remove and re-add the domain you will be given a fresh token, so delete the old record rather than keeping both.
2. Move your mail — five records
The moment the MX record is live, mail for your domain arrives here. Add all five in the same sitting: the other four are what make your mail pass other people's spam checks.
| Name | Type | Value | What it does |
|---|---|---|---|
yourname.com |
MX | 10 <mail host> |
Tells the world to deliver mail for this domain to us. |
yourname.com |
TXT | v=spf1 include:<records domain> -all |
Says our server may send mail from this domain. |
pki1._domainkey.yourname.com |
CNAME | pki1._domainkey.<records domain> |
Lets receivers check our signature on your mail. Points at a key we keep. |
pki2._domainkey.yourname.com |
CNAME | pki2._domainkey.<records domain> |
The second key, so we can rotate without asking you to change anything. |
_dmarc.yourname.com |
TXT | v=DMARC1; p=quarantine; rua=mailto:<report address> |
Tells receivers what to do with mail that fails the checks above, and where to report. |
Three things about this group are worth knowing before you start:
- A domain may have only one SPF record. If one already exists, replace it rather than adding a second. Keep another
include:in it only if something else still sends mail as this domain. - Remove an old MX record. Two different MX hosts would split your mail between two systems.
- The two DKIM records are CNAMEs, not TXT records. You are not pasting a key — you are pointing at ours. This is the single most common mistake; see below.
Some providers — Namecheap in particular — let a TXT record sit at the same name as a CNAME and will answer TXT queries from it. A receiving mail server asks for TXT at pki1._domainkey.yourname.com, gets your text instead of following the CNAME to our key, and stamps every message you send dkim=neutral (bad format).
The CNAME on its own looks perfectly fine in a DNS lookup, which is what makes this hard to spot. We look for it: if a CNAME is right but a TXT record is also answering at that name, the record reads Found, different and the screen shows you the text to delete. Delete it. Keep only the CNAME.
3. Finishing touches — four optional records
Optional, and worth the two minutes.
| Name | Type | Value | What it does |
|---|---|---|---|
openpgpkey.yourname.com |
CNAME | openpgpkey.<records domain> |
Lets other encrypted mail apps find your public key by your address. |
mta-sts.yourname.com |
CNAME | mta-sts.<records domain> |
Where senders read your transport-security policy. |
_mta-sts.yourname.com |
TXT | v=STSv1; id= followed by an id unique to your domain |
Announces that policy. |
_smtp._tls.yourname.com |
TXT | v=TLSRPTv1; rua=mailto:<report address> |
Where senders report transport-security failures. |
The first one is the key directory: with it, somebody who has only ever seen [email protected] can send you an encrypted message on the first try. It needs the address to be on your key and published — that half is in Addresses on your domain.
The other three are the transport-security policy. The policy we publish for a customer domain is in testing mode, which means a sender that cannot reach us over an encrypted connection reports it rather than refusing to deliver. The id in the TXT record is stable: it changes only if the policy itself would, so you will not be asked to update it.
For every CNAME here, set Proxy status to DNS only — the grey cloud, not the orange one. A proxied record answers with Cloudflare's own addresses, and the key directory and policy host then cannot be reached. The app says the same thing on the records screen.
At your provider
- Open the dashboard, pick your domain, then DNS › Records › Add record.
- Pick the type. Name: the part before your domain — Cloudflare adds the domain itself. Content: the value, with or without quotes.
- For a CNAME, set Proxy status to DNS only (grey cloud). TTL Auto. Save.
- Domain List › Manage next to your domain › Advanced DNS.
- Add New Record: pick the type, Host is the part before your domain (
@for the domain itself), Value is the value. - TTL Automatic. Tick the green check to save.
- For the two DKIM names, add the CNAME only — see the warning above.
- My Products › your domain › DNS › Manage DNS.
- Add New Record: pick the type, Name is the part before your domain (
@for the domain itself), Value is the value. - TTL default. Save.
- Open the DNS settings for your domain — usually under DNS, Zone or Advanced DNS.
- Add a record of the type shown. Most providers want only the part before your domain in the name field; a few want the full name.
- Leave the TTL at its default. Save, then come back to the app.
If your DNS is not where you expected: the registrar (where you pay for the name) and the DNS host (where the records live) can be different companies. We follow the name servers, which is where the records actually are — and the app names the provider it found.
What the states mean
Each record on the DNS records screen carries one of four labels.
| Label | What we saw |
|---|---|
| Found | We read the record and it is what we asked for. |
| Found, different | Something is there, and it is not what we asked for. The screen shows it under Found instead: so you can compare. |
| Not found yet | Nothing is there. A record that was found before has to answer empty twice in a row before it is called this. |
| Not checked yet | No check has run for this record yet. |
And one state that is about us rather than about you: if our resolver cannot reach your DNS at all, the page says "The last check could not reach your DNS. We keep trying; nothing is wrong with your records." That is never read as a missing record, and nothing is acted on while it lasts.
New records take time to appear — anything from seconds to a few hours, depending on the provider and the TTL of whatever was there before. Check now re-reads immediately; otherwise we check about every 30 seconds while the page is open.
When a record reads "Found, different"
This is the useful state: something answered, so you can fix it rather than wonder. What each record means by it:
| Record | Likely cause |
|---|---|
| Ownership TXT | An older privateki-verify= token is still there. Replace it with the one on the screen. |
| MX | Either the MX points elsewhere, or ours is there alongside another host. Remove the old one — two MX hosts split your mail. |
| SPF | A v=spf1 record exists without our include. Replace it with ours; a domain may have only one SPF record. |
| DKIM (either) | The CNAME points at the wrong target — or the CNAME is right and a TXT record is shadowing it. Check for a stray TXT at that name first; it is the usual cause. |
| DMARC | A v=DMARC1 record is there with a policy of none. We ask for quarantine; reject also passes. |
openpgpkey / mta-sts CNAME |
Points somewhere else — or, at Cloudflare, is proxied rather than DNS only, which hides the CNAME from anybody reading it. |
_mta-sts / _smtp._tls TXT |
A record of the right kind with a different value — usually one left over from another provider. |
Two notes on what counts as correct, so a passing record does not look wrong to you:
- MX reads Found only when ours is the only MX host. Ours plus a lower-priority backup reads Found, different — mail still reaches us, but the backup is worth removing.
- SPF passes on either our
include:or ana:term naming our mail host. Both are fine; theinclude:form is what the screen shows.
How long before a record shows up?
Usually minutes. It depends on your provider and on the TTL of any record that was there before — a record you replaced can be cached by resolvers for as long as its old TTL. If something is still not seen after a few hours, check the name field first; a doubled domain name is by far the most common reason.
Can I add the records before the domain is proven?
Yes. The order on the screen is for convenience, not a requirement. Nothing happens with the mail records until the ownership record is seen, and the MX record starts delivering mail here as soon as both are in place.
Do I have to keep the ownership record for ever?
No. Once the domain is connected you may delete it, and leaving it costs nothing.
Why are the DKIM records CNAMEs instead of a key?
Because the signing keys are ours, not yours. Two selectors exist so one can be rotated without anybody being asked to change a record. Nothing of yours is in them, and there is no per-customer DKIM key in this version.
What happens if I delete a mail record later?
The domain page calls it out, and mail for the domain may stop arriving until it is back. Nothing is deleted at our end, and nothing in your mailbox is affected.
Will my website stop working?
No. None of these records touches a web address — the MX record is mail only, the two optional CNAMEs are on names of their own (openpgpkey and mta-sts), and nothing here points your domain or www anywhere.