Connect DNS Records

`dnsRecords` object

DNS records can be provided in two different ways: as a single array of records, or as an object that maps different sets of records to specific cases (root domain, subdomain, or individual domains).

Simple array

A single array of DNS records. This is the easiest way to send Entri the set of records you want to configure, applied to every domain with no domain or subdomain distinction.

{
  ...,
  dnsRecords: [
    {
      type: "CNAME",
      host: "shop",
      value: "myapp.com",
      ttl: 300,
    },
    {
      type: "TXT",
      host: "@",
      value: "123-example-txt-record",
      ttl: 300,
    }
  ]
}

Object form

If you need different sets of records depending on whether the user connects a root domain or a subdomain, or you are configuring several domains in one flow, dnsRecords can be an object instead of an array. See Multi-Domain & Conditional Records for the full reference.

Record object specification

Property	Type	Required?	Example
host	string	Yes	www
ttl	integer	Yes	300 (This is the minimum accepted value. Some providers don’t accept this value and will default to the minimum value allowed by the provider.)
type	string (see below)	Yes	CNAME (Check the Supported record types section below)
value	string	Yes	m.example.com
fallbackValue	string	No	v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDg9/gR+3J0mmugLjhpYOfQK9ytkEKnXM0kVdpu0UoykSPK7ChD+nRxFJbN2cxtvu8GrCNQwPTKbC0jimaSi0V2j3JndnRrECuYCqeZYcRmw2lYs18QnmJRfCpweKoaGtv9zERCkeHwLcTaLkrSHrRDf58WgERg8x/4ipBPIyZufwIDAQAB
priority	integer	Only for MX records	10
optional	boolean	No	`true` (defaults to `false`. When `true`, a failure on this record does not fail the flow. See Optional records.)
advancedDmarcOptions	object	Only for DMARC (`TXT`) records	See the full schema in DMARC Handling: Advanced Options. Lets you override, remove, or conditionally add DMARC tags, and inherit DMARC from the root domain.

`advancedDmarcOptions` (DMARC records only)

For DMARC TXT records you can attach an advancedDmarcOptions object to a record to take precise control over how Entri merges, overrides, or preserves individual DMARC tags.

Property	Type	Description
`inheritRootDmarc`	boolean	When `true` on a subdomain DMARC record, inherits the DMARC policy from the root domain.
`overrideTags`	object	Map of tag → value. Overrides the listed tags in the existing DMARC record, or adds them if missing.
`removeTags`	array	List of DMARC tag names to remove from the existing record (e.g. `["pct"]`).
`addTagsIfNotExist`	object	Map of tag → value. Adds each tag only if it is not already present on the existing DMARC record.

See DMARC Handling: Advanced Options for full examples and use cases.

Optional records

By default, every record in dnsRecords is required: if one of them cannot be configured, the whole flow fails. Setting optional: true on a record marks it as non-blocking. If an optional record cannot be configured, Entri continues with the remaining records and the flow still completes successfully. Records without the flag, or with optional: false, keep the current behavior, so existing configurations are not affected.

This feature is not supported by the GoDaddy, Squarespace, IONOS, and Cloudflare providers. On these providers, all records behave as required regardless of the optional flag.

A common use case is an SPF record that improves email deliverability but should not block the MX and DKIM records from being set up:

{
  "dnsRecords": [
    {
      "type": "MX",
      "host": "@",
      "value": "mx.example-mail.com",
      "priority": 10,
      "ttl": 300
    },
    {
      "type": "TXT",
      "host": "@",
      "value": "v=spf1 include:_spf.example-mail.com ~all",
      "ttl": 300,
      "optional": true
    }
  ]
}

When an optional record fails, the user still reaches the Congratulations screen. The failed records are reported back to you in two places: the onSuccess browser event includes a failedOptionalRecords array, and webhooks track the optional records separately through the optional_records_propagation_status field without affecting propagation_status.

Dynamic configuration variables

You can insert dynamic variables into the dnsRecords section of your configuration object using syntax. For example, if the user sets up blog.example.com, the following variables will be available:

Variable name	Example value
`{DOMAIN}`	example.com
`{SUBDOMAIN}`	blog
`{SLD}`	example
`{TLD}`	com
`{emailProviderSPF}`	Google

Please note, all the variables are case-sensitive and must be inputted in all upper-case.

Supported Record Types

Type	Description
A	Holds the IP address of a domain.
AAAA	The AAAA record is conceptually similar to the A record, but it allows you to specify the IPv6 address of the server, rather than the IPv4.
CNAME	Forwards one domain or subdomain to another domain. Does not provide an IP address.
CAA	Used to provide additional confirmation for the Certification Authority (CA) when validating an SSL certificate.
MX	Directs email to an email server.
TXT	Stores text strings. For special uses of the TXT record, see Handling DKIM, SPF, and DMARC records.
NS	Indicates which DNS server is authoritative for that domain, it is the server that stores all DNS records for a domain, including A records, MX records, or CNAME records.

Get Started

Activate Suite

Domain Management

SSL Provisioning

For DNS Providers

DNS Concepts

Entri MCP

Reference

Legal & Security

Resources

Connect DNS Records

`dnsRecords` object

Simple array

Object form

Record object specification

`advancedDmarcOptions` (DMARC records only)

Optional records

Dynamic configuration variables

Supported Record Types

​dnsRecords object

​Simple array

​Object form

​Record object specification

​advancedDmarcOptions (DMARC records only)

​Optional records

​Dynamic configuration variables

​Supported Record Types

`dnsRecords` object

Simple array

Object form

Record object specification

`advancedDmarcOptions` (DMARC records only)

Optional records

Dynamic configuration variables

Supported Record Types