How to Update DNS Records in Azure DNS

Azure DNS is Microsoft's DNS hosting service, integrated into the Azure cloud platform. It is commonly used by organizations that run infrastructure on Azure and want to manage DNS alongside their other cloud resources. Azure DNS manages DNS through DNS zones, and records can be created via the Azure Portal, Azure CLI, PowerShell, or ARM/Bicep templates. This guide walks you through adding and editing SPF, DMARC, MTA-STS, and DKIM DNS records for your domain in Azure DNS. Each section covers both the Azure Portal interface and Azure CLI commands, with correct field values and platform-specific details.

Azure DNS is a DNS hosting service, not a domain registrar. Your domain is registered with a separate registrar, and your nameservers must point to Azure's nameserver infrastructure for records to resolve. Each Azure DNS zone is assigned four nameservers that you configure at your registrar.

Accessing Your DNS Zone

Azure Portal

1. Sign in to the Azure Portal at portal.azure.com.
2. Navigate to DNS zones using the search bar or by selecting it from All services > Networking.
3. Select the DNS zone for your domain from the list.
4. You are now in the DNS zone overview, where you can view, add, edit, and delete record sets.

Azure DNS displays records as "record sets" — each record set groups all records of the same type and name. To add a new record set, click + Record set at the top of the page. To edit an existing record set, click on it to open the editing panel.

Azure CLI

If you prefer the command line, you can manage DNS records using the Azure CLI (az). Ensure you have the Azure CLI installed and authenticated with az login. All CLI commands use the format:

az network dns record-set <type> add-record \
  --resource-group <resource-group> \
  --zone-name <yourdomain.com> \
  --record-set-name <name> \
  --<value-parameter> <value>

Note: Azure DNS zones must have their nameservers configured at your domain registrar. The four nameservers assigned to your zone are displayed at the top of the DNS zone overview in the Azure Portal. If your registrar still points to different nameservers, records in Azure DNS will not resolve publicly.

TXT Records

SPF Record

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses and services are authorized to send email for your domain. Your SPF record is published as a TXT record at the root of your domain.

Azure Portal:

1. In your DNS zone, click + Record set.
2. In the Name field, enter @. Azure DNS uses @ to represent the zone apex (root of your domain).
3. Select TXT from the Type dropdown.
4. Set the TTL to 3600 and the TTL unit to Seconds.
5. In the Value field, enter your SPF record: v=spf1 include:_spf.mxio.io ~all
6. Click OK to save the record set.

Azure CLI:

az network dns record-set txt add-record \
  --resource-group myResourceGroup \
  --zone-name yourdomain.com \
  --record-set-name "@" \
  --value "v=spf1 include:_spf.mxio.io ~all"

If you already have an SPF record, do not create a second TXT record set with the same name. Azure DNS groups TXT records at the same name into a single record set, which means adding a second SPF value results in two TXT values at the root — and only one should contain an SPF policy. Edit the existing TXT record set to update the SPF value rather than adding a new one.

Azure-specific note: When a TXT record value exceeds 255 characters, Azure DNS requires you to split it into multiple strings within the same value. In the Azure Portal, each line in the value field is treated as a separate 255-character string. Azure concatenates them during DNS resolution. For the Azure CLI, use multiple --value parameters or split the string with spaces.

DMARC Record

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers how to handle email that fails SPF and DKIM checks. It also enables aggregate reporting so you can see who is sending email as your domain.

Azure Portal:

1. Click + Record set.
2. In the Name field, enter _dmarc. Azure DNS will scope this under your zone, resulting in _dmarc.yourdomain.com.
3. Select TXT from the Type dropdown.
4. Set the TTL to 3600.
5. In the Value field, enter your DMARC policy: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
6. Click OK.

Azure CLI:

az network dns record-set txt add-record \
  --resource-group myResourceGroup \
  --zone-name yourdomain.com \
  --record-set-name "_dmarc" \
  --value "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

Replace dmarc@yourdomain.com with the address where you want to receive DMARC aggregate reports. Start with p=none to collect data before enforcing. See the DMARC Deployment Guide for the full progression from none to quarantine to reject.

Note: mxio will support DMARC policy management in a future release.

CNAME Records

MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security) tells sending servers that your domain supports TLS encryption for inbound email and that they should refuse to deliver over an unencrypted connection. The MTA-STS policy is published via HTTPS, and a CNAME record points to the policy host.

Azure Portal:

1. Click + Record set.
2. In the Name field, enter _mta-sts. Azure DNS will scope this under your zone.
3. Select CNAME from the Type dropdown.
4. Set the TTL to 3600.
5. In the Alias field, enter the CNAME target provided by your MTA-STS hosting service. The Portal accepts the value with or without a trailing dot.
6. Click OK.

Azure CLI:

az network dns record-set cname set-record \
  --resource-group myResourceGroup \
  --zone-name yourdomain.com \
  --record-set-name "_mta-sts" \
  --cname "mta-sts.your-hosting-provider.com."

Trailing dot convention: Azure DNS follows RFC 1035 FQDN notation. In the Portal, the trailing dot is optional — Azure treats values as FQDNs automatically. In the CLI, ARM templates, Bicep, and Terraform, include the trailing dot on CNAME targets and NS values (e.g., ns1.example.com.) to be explicit. Omitting it usually works, but including it prevents any ambiguity in automation pipelines.

You also need a TXT record at _smtp._tls to publish the MTA-STS policy version identifier. Follow the same TXT record process described above, using _smtp._tls as the Name and the policy string as the Value.

Note: mxio will support MTA-STS hosting in a future release.

NS Delegation

DKIM Key Hosting

DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify that an email was sent by an authorized server and that the message body was not altered in transit. DKIM keys are published as DNS records under the _domainkey subdomain.

For centralized DKIM key management, you can delegate the _domainkey subdomain to a dedicated DNS host via NS records.

Azure Portal:

1. Click + Record set.
2. In the Name field, enter _domainkey. Azure DNS will scope this under your zone, resulting in _domainkey.yourdomain.com.
3. Select NS from the Type dropdown.
4. Set the TTL to 3600.
5. In the Name server field, enter the first nameserver provided by your DKIM hosting service.
6. Click OK.
7. To add additional nameservers, click on the existing _domainkey NS record set and add more nameserver entries (typically 2-4 NS records are required for redundancy).

Azure CLI:

az network dns record-set ns add-record \
  --resource-group myResourceGroup \
  --zone-name yourdomain.com \
  --record-set-name "_domainkey" \
  --nsdname "ns1.your-dkim-host.com."

az network dns record-set ns add-record \
  --resource-group myResourceGroup \
  --zone-name yourdomain.com \
  --record-set-name "_domainkey" \
  --nsdname "ns2.your-dkim-host.com."

Azure DNS fully supports NS delegation for subdomains.

Note: mxio will support DKIM key hosting via NS delegation in a future release.

Verifying Your Changes

After adding or editing DNS records in Azure DNS, verify that your changes are live and correct.

1. Use the mxio SPF Checker to validate your SPF record. Enter your domain and confirm that the record resolves correctly, the lookup count is within the 10-lookup limit, and all your sending services are included.
2. Use the mxio DMARC Checker to verify your DMARC record is published and syntactically correct.
3. Use the mxio Domain Health tool for a full overview of your domain's email authentication status, including SPF, DKIM, DMARC, and MX configuration.
4. If you created NS delegation records for DKIM, use the Delegation Health tool to verify that the NS records are resolving correctly and the delegated zone is responding.

Azure DNS uses a global Anycast network, and changes typically propagate within seconds to a few minutes. If your changes are not appearing, verify that your domain's nameservers at your registrar match the four nameservers assigned to your Azure DNS zone (displayed at the top of the zone overview).

You can also verify records directly using the Azure CLI:

az network dns record-set txt show \
  --resource-group myResourceGroup \
  --zone-name yourdomain.com \
  --name "@"

Troubleshooting

Nameserver delegation not configured

If records in Azure DNS are not resolving publicly, the most common cause is that your domain registrar still points to different nameservers. Go to your registrar and update the nameservers to match the four NS records assigned to your Azure DNS zone. You can find these at the top of the DNS zone overview in the Azure Portal.

Duplicate SPF records

Your domain must have exactly one SPF value in the root TXT record set. Azure DNS groups all TXT values at the same name into one record set. If your root TXT record set contains two values starting with v=spf1, remove one and merge the include mechanisms. Use the SPF Checker to verify.

Record set name format

Azure DNS uses @ for the zone apex. For subdomains, enter only the subdomain portion — Azure DNS scopes it under the zone automatically. For example, to create a record at _dmarc.yourdomain.com, enter _dmarc as the record set name.

Infrastructure-as-code conflicts

If your Azure DNS zone is managed by ARM templates, Bicep, Terraform, or Pulumi, manual changes in the Azure Portal may be overwritten on the next deployment. Ensure any manual DNS changes are reflected in your infrastructure-as-code configuration to prevent them from being reverted.

Resource group and permissions

Azure DNS zones are Azure resources that live in a resource group and are governed by Azure RBAC (Role-Based Access Control). If you cannot create or edit records, verify that your Azure account has the DNS Zone Contributor role (or a custom role with equivalent permissions) on the resource group containing the DNS zone.

TXT record value length

Azure DNS supports TXT records up to 4,096 characters total, split into 255-character strings. If your SPF record exceeds 255 characters, Azure handles the splitting automatically in the Portal. In the CLI, you can provide the full value as a single string and Azure will handle the split at the protocol level.