Skip to content
Cloudflare Docs

DNS record types

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.

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

A and AAAA records ↗ map a domain name to one or multiple IPv4 or IPv6 address(es).

These records include the following fields:

  • Name: A subdomain or the zone apex (@), which must:

    • Be 63 characters or less
    • Start with a letter and end with a letter or digit
    • Only contain letters, digits, or hyphens (underscores allowed but discouraged)

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

  • 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.

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.

For field definitions, refer to the API documentation (visible once you select the record type under the request body specification).

Request
curl "https://api.cloudflare.com/client/v4/zones/<ZONE_ID>/dns_records" \
--header "X-Auth-Email: <EMAIL>" \
--header "X-Auth-Key: <API_KEY>" \
--header "Content-Type: application/json" \
--data '{
  "type": "A",
  "name": "www.example.com",
  "content": "192.0.2.1",
  "ttl": 3600,
  "proxied": false
}'
Response
{
  "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": {
      "auto_added": false,
      "managed_by_apps": false,
      "managed_by_argo_tunnel": false,
      "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

CNAME records ↗ map a domain name to another (canonical) domain name. They can be used to resolve other record types present on the target domain name.

These records include the following fields:

  • Name: A subdomain or the zone apex (@), which must:
    • Be 63 characters or less
    • Start with a letter and end with a letter or digit
    • Only contain letters, digits, or hyphens (underscores are allowed but discouraged)
  • 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.

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) if this hostname is meant to proxy traffic.

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.

Example API call

When creating CNAME records using the API:

For field definitions, refer to the API documentation (visible once you select the record type under the request body specification).

Request
curl "https://api.cloudflare.com/client/v4/zones/<ZONE_ID>/dns_records" \
--header "X-Auth-Email: <EMAIL>" \
--header "X-Auth-Key: <API_KEY>" \
--header "Content-Type: application/json" \
--data '{
  "type": "CNAME",
  "name": "www.example.com",
  "content": "www.another-example.com",
  "ttl": 3600,
  "proxied": false
}'
Response
{
  "result": {
    "id": "<ID>",
    "zone_id": "<ZONE_ID>",
    "zone_name": "example.com",
    "name": "www.example.com",
    "type": "A",
    "content": "www.another-example.com",
    "proxiable": true,
    "proxied": false,
    "ttl": 1,
    "locked": false,
    "meta": {
      "auto_added": false,
      "managed_by_apps": false,
      "managed_by_argo_tunnel": false,
      "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.

For field definitions, refer to the API documentation (visible once you select the record type under the request body specification).

DKIM

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

SPF

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

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.

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.

For field definitions, refer to the API documentation (visible once you select the record type under the request body specification).

CAA

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

For field definitions, refer to the API documentation (visible once you select the record type under the request body specification).

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

For field definitions, refer to the API documentation (visible once you select the record type under the request body specification).

Request
curl "https://api.cloudflare.com/client/v4/zones/<ZONE_ID>/dns_records" \
--header "X-Auth-Email: <EMAIL>" \
--header "X-Auth-Key: <API_KEY>" \
--header "Content-Type: application/json" \
--data '{
  "type": "SRV",
  "name": "_xmpp._tcp.example.com",
  "data": {
    "priority": 10,
    "weight": 5,
    "port": 5223,
    "target": "server.example.com"
  }
}'
Response
{
  "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, Cloudflare automatically generates HTTPS records on the fly, to advertise to clients how they should connect to your server.

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

For field definitions, refer to the API documentation (visible once you select the record type under the request body specification).

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.

For field definitions, refer to the API documentation (visible once you select the record type under the request body specification).

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.

If you have an Enterprise account, you also have the option to change the SOA record values that Cloudflare will use. You can do that for existing zones by going to DNS > Records > DNS record options, or you can configure your own DNS zone defaults and define the SOA record values that Cloudflare will use for all new zones added to your account.

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

SOA record fields

  • MNAME: The primary nameserver for the zone. Secondary nameservers receive zone updates from the nameserver specified in this field.

  • RNAME: The email address of the administrator responsible for the zone.

    The @ symbol is replaced by the first dot. If an email address contains a dot before @, this should be represented as \..

    EmailRNAME
    john@example.comjohn.example.com
    john.doe@example.comjohn\.doe.example.com

  • Serial: The serial number for the zone. Secondary nameservers initiate zone transfers if this number increases.

  • Refresh: Time (in seconds) after which a secondary nameserver should query the primary for the SOA record, to detect zone changes. Only relevant if DNS NOTIFY (RFC 1996 ↗) is not configured.

    DefaultMinimumMaximum
    1000060086400

  • Retry: Time (in seconds) after which a secondary nameserver should retry getting the serial number from the primary nameserver after a failed attempt. Any specified values must not be greater than Refresh.

    DefaultMinimumMaximum
    24006003600

  • Expire: Time (in seconds) after which a secondary nameserver should stop answering queries for a zone if the primary does not respond. Any specified values must not be smaller than Refresh.

    DefaultMinimumMaximum
    604800864002419200

  • Record TTL: The time to live of the SOA record.

    DefaultMinimumMaximum
    360018003600

  • Minimum TTL: The TTL for caching negative responses. Refer to RFC 2308 ↗ for details.

    DefaultMinimumMaximum
    18006086400

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.

For field definitions, refer to the API documentation (visible once you select the record type under the request body specification).

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.

For field definitions, refer to the API documentation (visible once you select the record type under the request body specification).

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.

Cloudflare DashboardDiscordCommunityLearning CenterSupport Portal
Cookie Settings