> ## Documentation Index
> Fetch the complete documentation index at: https://developers.entri.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect DNS Records

> Defining dnsRecords, supported types, and dynamic variables ({DOMAIN}, {SUBDOMAIN}, ...).

## `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](/connect/multi-domain) 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](#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](#optional-records).)                                                                                                     |
| advancedDmarcOptions | object             | Only for DMARC (`TXT`) records | See the full schema in [DMARC Handling: Advanced Options](/advanced-dmarc-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](/advanced-dmarc-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.

<Note>
  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.
</Note>

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:

```json theme={"system"}
{
  "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](/connect/events#onsuccess-callback-event) includes a `failedOptionalRecords` array, and webhooks track the optional records separately through the [`optional_records_propagation_status` field](/connect/events#status-fields) 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        |

<Note>
  *Please note, all the variables are* **case-sensitive** *and must be inputted
  in all upper-case.*
</Note>

## 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](/handling-dkim-spf-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. |
