About resource records

Resource records provide DNS-based information about the hardware and software components that point to and support your domain (hosts, name servers, web servers, email servers).

Learn about how to fix conflicting records errors. 

Each resource record consists of a set of fields:

  • Name — A label indicating the name or owner of the record. This can be the root domain (indicated by @) or a subdomain (such as “www”).
  • Type — The record's type. For example, the A (address) record.
  • TTL — (Time-To-Live) How often a copy of the record stored in cache (local storage) must be updated (fetched from original storage) or discarded. Shorter TTLs mean records are fetched more often (access is slower, data is more current). Longer TTLs mean records are fetched from less often (access is faster, data is less current). The default value is 1 hour.
    Note: When you make changes to a resource record, It could take up to the length of the TTL time for the change to propagate. When you add a new resource record, it will be visible to Internet users in 5 minutes.
  • Data — The record's data, which varies depending on the record's type. For example, a host's IP address for A records. Note that this is the data that is returned during a DNS search.

Note: Google Domains supports the IN Internet class by default; therefore, the Class field is not included.

Resource Record Types

In addition to the DNS resource records described here, Google Domains also supports synthetic records that extend the functionality of resource records. For more information, see Synthetic records.


A (IPv4 address) records map the domain name of a host to the IP address of that host (name-to-address mapping).

@ A 1h

Note: A records and AAAA records perform the same function. A records map to IP version 4 (IPv4) addresses. AAAA records map to IP version 6 (IPv6) addresses.


AAAA (IPv6 address) records map the domain name of a host to the IP address of that host (name-to-address mapping).

www AAAA 1h 2002:db80:1:2:3:4:567:89ab

Note: A records and AAAA records perform the same function. A records map to IP version 4 (IPv4) addresses. AAAA records map to IP version 6 (IPv6) addresses.


A Certification Authority Authorization (CAA) record indicates if you, the domain owner, permit a certificate authority to issue certificates for your domain using a DNS resource record.

Example: Anna wants “Let's Encrypt” certificate authority to be able to issue certificates for her domain, example.com, and its subdomains. She does not want other authorities to be able to issue certificates. She creates this CAA record:

example.com. IN CAA 0 issue "letsencrypt.org"
We recommend you do not explicitly disallow all certificate issuances. For example, Google products like Blogger and Google My Business can provision SSL for domain names registered with Google Domains. However, in order for Google to do this provisioning, you must not have CAA records set to Disallowed.

CNAME (canonical name) records map an alias domain name to a canonical (true) domain name. You can map multiple alias names to the same canonical domain (allowing you to set up A or AAAA record IP addresses in a single location).

In this example, www is the alias domain and example.com is the canonical domain (it's mapped to an IP address using the A record)..

www CNAME 1h example.com.
example.com. A 1h

In this example, www and FTP are alias domains and server1.example.com. is the canonical domain (it's mapped to an IP address using the A record).

www CNAME 1h server1.example.com.
ftp CNAME 1h server1.example.com.
server1.example.com. A 1h

CNAME records cannot be set for the root domain. Also, the target of a CNAME record can only be a domain name; paths are not allowed. If you want to redirect your root domain, or if your desired target is a URL that includes a path, try one of these options:


MX (mail exchange) records map a domain name to a mail server receiving email for that domain. MX records identify which mail servers others use to send email to a domain.

Multiple MX records can be set up for a domain, each with a priority number, where lower numbers have higher priority. In the example below, if mail can't be delivered using the host with the higher priority (10), the host with the lower priority (20) will be used.

@ MX 1h 10 mailhost1.example.com.
@ MX 1h 20 mailhost2.example.com.

If the priority numbers are the same (10 and 10), the MX records can be used to balance the load between hosts; either host will be chosen arbitrarily.

@ MX 1h 10 mailhost1.example.com.
@ MX 1h 10 mailhost2.example.com.

Note: Google Domains does not provide a separate field for the priority number. To specify a priority number, enter the value in the data field followed by the mail host (10 mailhost1.example.com.).


NS (name server) records map a domain or subdomain name to a name server. Name servers hold authoritative information about the domain’s namespace and translate domain names into their corresponding IP addresses (by referencing the resource records stored with the name server).

In Google Domains, you will create NS records for subdomains only. The NS records for your root domain are managed for you. For more information see About NS (name server) resource records.

ns1 NS 1h ns-cloud1.googledomains.com.
ns2 NS 1h ns-cloud2.googledomains.com.

PTR (pointer) records map the IP address of a host to the canonical (true) domain name for a host (address-to-name mapping). Known as reverse DNS lookup, the IP address is written in reverse and appended with the Address and Routing Parameter Area (arpa) top-level domain.

PTR records are used as a security device and anti-spam measure; mail and other types of servers can do reverse DNS lookups to verify the identities of hosts.

Usually, you will not manage PTR through Google Domains, because they need to be set by the owner of your IP address block (generally your ISP). Different IP block owners have different procedures for you to request these records. Please contact your provider for more information.

Google Domains supports PTR records that reside in the DNS zone corresponding to the your domain, for the purposes of having your ISP create CNAME records that delegate to us the responsibility for reverse lookups of those specific addresses.

If your provider delegates a PTR record to you, your provider will create a CNAME record that points to a PTR record that you manage through Google Domains. For example, suppose your server's A record looks like this:
www     A     1h

To delegate the PTR record to you, your provider must set the following CNAME. Note that the order of the 4 numbers comprising the IP address have been reversed:    CNAME     1h     ptr_www.example.com.

In Google Domains, you would set the following PTR record:
ptr_www     PTR     1h     www.example.com.

Once these records are set, requests to reverse-lookup the IP address will first go to your provider's record for, which redirects to your record for ptr_www.example.com., which tells the requester that corresponds to www.example.com.

As a similar example for IPv6 addresses, if your server's AAAA record looks like this:
www     AAAA     1h     202:db80:1:2:3:4:567:89ab

then its fully-specified IPv6 address is 0202:db80:0001:0002:0003:0004:0567:89ab. To obtain the CNAME record that your provider must set, reverse this address (digit-wise, ignoring the colons), putting dots between every digit and appending .ip6.arpa. (including the trailing dot):
b.a.     CNAME     1h     ptr_www.example.com.

Note: If you want your ISP to delegate a block of addresses, Google Domains does not support that directly. You will need to use Cloud DNS to create and store these records. You do not need to move ALL your DNS to Cloud DNS, just the PTR records.

For more information on Google Cloud DNS, see:


SOA (start of authority) records are used by the Google DNS Servers to store information about your domain to help manage traffic between the name servers. They typically include the name server, name server administrator account, name server serial number, zone file refresh rate and update retry wait period, and zone file expiry.

SOA records are managed by the name servers and cannot be viewed or edited in Google domains.


SPF (sender policy framework) is an open standard technical method. SPF specifies the mail servers that can send email from a domain.

When a mail server sends out an email, the receiving server looks at the SPF of the domain. If the email was sent by a mail server listed in the SPF, then the receiving server will accept the email.

To some extent, SPF prevents email spam caused by forged sender addresses: emails from a domain will not be accepted unless the sending server is included in the domain’s SPF list.

SPF uses TXT (text) records to map a domain name to one or more mail servers. The TXT record will include the SPF tag v=spf1 and other SPF qualifiers, mechanisms, and modifiers (see www.openspf.org).

@ SPF   “v=spf1 +a:mailhost3.example.com +a:mailhost4.example.com –all”   
mail3   A 1h
mail4   A 1h

SRV (service) records map a specific service or server to a domain name. The SRV record makes it possible to locate a service without having to know which host the service is running on.

In this example, the service record _http._tcp.example.com. includes the service http, the protocol the service runs over tcp, and the domain name example.com.. The record is mapped to the www.example.com. domain, which in turn, is mapped to a web server (the host with IP address The record has a priority of 10 (lower is preferred), a weight of 5 (to balance load among records with the same priority) and a port number 8080 specifying on which port the service can be found.

_http._tcp.example.com. SRV 1h 10 5 8080 www.example.com.
www A 1h

Note: Google Domains does not provide a separate field for the priority/weight/port numbers. Enter these values in the data field (each separated by a space) followed by the name of the service (10 5 8080 www.example.com.).


TXT (text) records contain arbitrary information, in the form of human-readable text or machine-readable data, that can be added to a resource record.

A TXT 1h ”This is my domain.”
Was this helpful?
How can we improve it?

Need more help?

Sign in for additional support options to quickly solve your issue