DNS record types

import { Details, Render, APIRequest, GlossaryTooltip, Example, } from "~/components";

This page provides information about some of the different types of DNS records that you can manage on Cloudflare. For guidance on how to add, edit, or delete DNS records, refer to Manage DNS records.

:::note Each DNS record has a maximum wire format size of 4,096 bytes. Wire format refers to how a record is encoded when transmitted over the DNS protocol (RFC 1035).

If you have multiple records with the same name and type, their combined content length must not exceed 8,192 characters. :::

IP address resolution

At least one IP address resolution record is required for each domain on Cloudflare. These records are the only ones you can proxy through Cloudflare.

A and AAAA

These records include the following fields:

• IPv4/IPv6 address: Your origin server address (cannot be a Cloudflare IP)

:::note

Cloudflare uses the canonical notation to store DNS records. This means that an AAAA record with content fe80::0:0:1 is stored and returned as fe80::1, for example.

Alternative notations of IPv4 addresses (1.1 for 1.0.0.1, for example) are not supported for A records.

:::

• TTL: Time to live, which controls how long DNS resolvers should cache a response before revalidating it.
  • If the Proxy Status is Proxied, this value defaults to Auto, which is 300 seconds.
  • If the Proxy Status is DNS Only, you can customize the value.
• Proxy status: For more details, refer to Proxied DNS records.
• Private network routing: Some Enterprise customers also have access to private network routing. For A and AAAA records, this feature allows you to proxy HTTP/HTTPS traffic from public hostnames to origins in your private network.

Example API call

When creating A or AAAA records using the API:

• The content of the records is an IP address (IPv4 for A or IPv6 for AAAA).
• The proxied field affects the record's proxy status.

<APIRequest path="/zones/{zone_id}/dns_records" method="POST" json={{ type: "A", name: "www.example.com", content: "192.0.2.1", ttl: 3600, proxied: false, }} code={{ mark: [5, 7], }} />

{
	"result": {
		"id": "<ID>",
		"zone_id": "<ZONE_ID>",
		"zone_name": "example.com",
		"name": "www.example.com",
		"type": "A",
		"content": "192.0.2.1",
		"proxiable": true,
		"proxied": false,
		"ttl": 1,
		"locked": false,
		"meta": {
			"source": "primary"
		},
		"comment": null,
		"tags": [],
		"created_on": "2023-01-17T20:37:05.368097Z",
		"modified_on": "2023-01-17T20:37:05.368097Z"
	},
	"success": true,
	"errors": [],
	"messages": []
}

CNAME

These records include the following fields:

- Target: The hostname where traffic should be directed (example.com). - TTL: Time to live, which controls how long DNS resolvers should cache a response before revalidating it.

• If the Proxy Status is Proxied, this value defaults to Auto, which is 300 seconds. - If the Proxy Status is DNS Only, you can customize the value. - Proxy status: For more details, refer to Proxied DNS records.

Proxied CNAME records

Observe the following aspects, especially before changing a CNAME record from proxied to DNS-only or vice versa:

• If a hostname is meant to proxy traffic, you can use CNAME records to point to other CNAME records (www.example2.com --> www.example1.com --> www.example.com), but the final record must point to a hostname with a valid IP address (and therefore a valid A or AAAA record). Also, queries for other record types on the same name are not supported.

• Cloudflare uses a process called CNAME flattening to deliver better performance. This process supports a few features and can interact with different setups that depend on CNAME records. Refer to the CNAME flattening section to learn more about this.

• If you encounter a CNAME record that you cannot proxy — usually associated with another CDN provider — a proxied version of that record will cause connectivity errors. Cloudflare is purposely preventing that record from being proxied to protect you from a misconfiguration. Refer to proxying limitations for details.

:::note Specific CNAME record values with traffic proxied through Cloudflare will enable O2O routing for the Shopify SaaS provider. Refer to the Shopify provider guide for more information. :::

Example API call

When creating CNAME records using the API:

• The content of the records is a fully qualified domain name.
• The proxied field affects the record's proxy status.

<APIRequest path="/zones/{zone_id}/dns_records" method="POST" json={{ type: "CNAME", name: "www.example.com", content: "www.another-example.com", ttl: 3600, proxied: false, }} code={{ mark: [5, 7], }} />

{
	"result": {
		"id": "<ID>",
		"zone_id": "<ZONE_ID>",
		"zone_name": "example.com",
		"name": "www.example.com",
		"type": "CNAME",
		"content": "www.another-example.com",
		"proxiable": true,
		"proxied": false,
		"ttl": 1,
		"locked": false,
		"meta": {
			"source": "primary"
		},
		"comment": null,
		"tags": [],
		"created_on": "2023-01-17T20:37:05.368097Z",
		"modified_on": "2023-01-17T20:37:05.368097Z"
	},
	"success": true,
	"errors": [],
	"messages": []
}

Email authentication

These records are recommended regardless of whether your domain sends email messages. Creating secure email records can help protect your domain against email spoofing.

If your domain is not used to send email messages, learn more about creating recommended restrictive records.

MX

A mail exchange (MX) record is required to deliver email to a mail server.

• MX record syntax
• Create an MX record

DKIM

A DomainKeys Identified Mail (DKIM) record ensures email authenticity by cryptographically signing emails:

• DKIM record syntax
• Create a DKIM record

SPF

A Sender Policy Framework (SPF) record lists authorized IP addresses and domains that can send email on behalf of your domain.

• SPF record syntax
• Create an SPF record

DMARC

A Domain-based Message Authentication Reporting and Conformance (DMARC) record helps generate aggregate reports about your email traffic and provide clear instructions for how email receivers should treat non-conforming emails.

• DMARC record syntax
• Create a DMARC record

Specialized records

TXT

A text (TXT) record lets you enter text into the DNS system.

As the content of TXT records consist of one or more text strings delimited by double quotes ("), you might find a validation error if you add inconsistent quotation marks (for example, "this or "these" ones"). For new records, if you save your TXT content without any quotes, Cloudflare will automatically add double quotes. For details, refer to What is a DNS TXT record.

At Cloudflare, TXT records are most commonly used to demonstrate domain ownership prior to issuing SSL/TLS certificates for your domain or a Cloudflare for SaaS domain.

You could also use TXT to create email authentication records, but we recommend that you use our Email security Wizard instead.

CAA

A Certificate Authority Authorization (CAA) record specifies which Certificate Authorities (CAs) are allowed to issue certificates for a domain.

SRV

A service record (SRV) specifies a host and port for specific services like voice over IP (VOIP), instant messaging, and more.

Example API call

<APIRequest path="/zones/{zone_id}/dns_records" method="POST" json={{ type: "SRV", name: "_xmpp._tcp.example.com", data: { priority: 10, weight: 5, port: 5223, target: "server.example.com", }, }} />

{
	"result": {
		"id": "<ID>",
		"zone_id": "<ZONE_ID>",
		"zone_name": "example.com",
		"name": "_xmpp._tcp.example.com",
		"type": "SRV",
		"content": "5 5223 server.example.com",
		"priority": 10,
		"proxiable": false,
		"proxied": false,
		"ttl": 1,
		"locked": false,
		"data": {
			"port": 5223,
			"priority": 10,
			"target": "server.example.com",
			"weight": 5
		},
		"meta": {
			"auto_added": false,
			"managed_by_apps": false,
			"managed_by_argo_tunnel": false,
			"source": "primary"
		},
		"comment": null,
		"tags": [],
		"created_on": "2022-11-08T15:57:39.585977Z",
		"modified_on": "2022-11-08T15:57:39.585977Z"
	},
	"success": true,
	"errors": [],
	"messages": []
}

SVCB and HTTPS

Service Binding (SVCB) and HTTPS Service (HTTPS) records allow you to provide a client with information about how it should connect to a server upfront, without the need of an initial plaintext HTTP connection.

If your domain has HTTP/2 or HTTP/3 enabled, proxied DNS records, and is also using Universal SSL, Cloudflare automatically generates HTTPS records on the fly, to advertise to clients how they should connect to your server.

Proxied vs DNS-only names

For proxied (orange cloud) names, Cloudflare synthesizes HTTPS records automatically when Universal SSL is enabled. Manually-added HTTPS records on proxied names are not served — Cloudflare uses the auto-generated records instead.

If you have disabled Universal SSL (for example, because you use Advanced Certificates exclusively), Cloudflare will not generate HTTPS records for proxied names. Cloudflare only advertises an HTTPS record for names it knows have an active certificate — advertising HTTPS for a name without one would cause connections to fail.

If Universal SSL is turned off, Cloudflare does not generate HTTPS records for proxied names even if you have a custom or Advanced Certificate active. To restore HTTPS record generation, turn Universal SSL back on — your custom or Advanced Certificate will still take priority over it for connections, as described in certificate and hostname priority. If you need to keep Universal SSL turned off, contact Cloudflare Support.

For DNS-only (grey cloud) names, you can manually add HTTPS records and Cloudflare will serve them. However, all records with the same name must be DNS-only for the manual HTTPS record to be served.

For more details and context, refer to the announcement blog post and RFC 9460.

PTR

A pointer (PTR) record specifies the allowed hosts for a given IP address.

Within Cloudflare, PTR records are used for reverse DNS lookups and should preferably be added to reverse zones.

SOA

A start of authority (SOA) record stores information about your domain such as admin email address, when the domain was last updated, and more. Refer to What is a DNS SOA record for an example.

If you are using Cloudflare for your authoritative DNS, you do not need to create an SOA record. Cloudflare creates this record automatically when you start using Cloudflare's authoritative nameservers.

With Enterprise accounts, you also have the option to change the SOA record values that Cloudflare will use:

• As a DNS zone default: Define the SOA record values that Cloudflare will use for all new zones added to your account. Refer to Configure DNS zone defaults for step-by-step guidance.
• For existing zones: Override the defaults or Cloudflare-generated values under DNS record options on the DNS Records page.

Refer to the following list for information about each SOA record field:

:::note When you query the SOA record itself, the TTL in the response is the smaller of the Record TTL and the Minimum TTL values. For example, if Record TTL is 3600 and Minimum TTL is 1800, the SOA record is returned with a TTL of 1800. :::

NS

A nameserver (NS) record indicates which server should be used for authoritative DNS.

You only need to add NS records to your DNS records table in Cloudflare when you are using subdomain setup or delegating subdomains outside of Cloudflare.

:::note Your assigned Cloudflare nameservers, custom nameservers, and their corresponding nameserver TTLs are controlled via dedicated sections on the DNS Records page. For details, refer to Nameservers. :::

Limits

DS and DNSKEY

DS and DNSKEY records help implement DNSSEC, which cryptographically signs DNS records to prevent domain spoofing.

Most Cloudflare domains do not need to add these records and should instead follow our DNSSEC setup guide.

Other

Cloudflare also supports other record types that are less common, such as URI, NAPTR, and certificate-related record types (SSHFP, TLSA, SMIMEA, and CERT). Refer to our blog post for more information.