How do you add email DNS records in Azure DNS?

Azure DNS is a good home for a domain's records if the rest of your infrastructure lives in Azure, but it thinks in record sets, not single records. Every TXT value at the root, including SPF and verification tokens, belongs to one TXT record set named @. Knowing that, and how Azure handles long TXT values, avoids most email setup problems.

This guide covers MX, SPF, DKIM and DMARC in Azure DNS through the Azure portal, the Azure CLI and Azure PowerShell, using Microsoft Learn for every step. For background on the records, read SPF vs DKIM vs DMARC.

Is your domain actually delegated to Azure DNS?

Azure DNS hosts zones; it doesn't make them live. Records you add in an Azure public DNS zone only answer on the internet once your registrar points the domain at Azure's name servers. A Private DNS zone only answers inside your virtual networks, so email records there are invisible to senders.

Microsoft's delegation tutorial says: "Azure DNS assigns name servers from a pool each time a zone is created," and "Use all four name servers, regardless of the name of your domain." Its example uses names such as ns1-37.azure-dns.com.

1. In the Azure portal, open the DNS zone and note the four name servers on its Overview page.
2. At your registrar, confirm the domain's NS records list exactly those four.
3. Check from outside with our MX Lookup or nslookup -type=SOA example.com.

If the domain still uses another DNS host, add your records there instead. Our guides for Route 53 and Cloudflare cover two common alternatives.

How do record sets work in Azure DNS?

A record set is every record with the same name and type. Microsoft Learn's zones and records overview sets out the rules that matter for email:

At the time of writing (October 2026), Azure DNS supports A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV and TXT records, plus DS and TLSA when the zone is signed with DNSSEC.

Where do you add DNS records in the Azure portal?

From Microsoft's portal quickstart and record set guide:

1. In the Azure portal, open your DNS zone.
2. Select Record sets, then + Add. The Add a record set pane opens.
3. Enter the Name (@ for the apex, or a prefix), choose the Type, leave Alias record set at No, and set TTL and TTL unit. The quickstart uses 1 hour.
4. Enter the value fields for the type.
5. Select Add.

To add a value to a record set that already exists, such as a second TXT value at @, don't create a new set. On the Record sets page, select the edit icon next to the set, add the value and select Apply. To remove one value, clear its field and select Apply; Microsoft notes that removing the last record doesn't delete the set itself.

How do you add or edit an SPF record in Azure DNS?

SPF is a TXT value in the @ TXT record set. Your domain may publish only one SPF record: RFC 7208, section 3.2 says it "MUST NOT have multiple records" that an SPF check selects. Other TXT values, such as MS=ms12345678 or google-site-verification=..., sit next to it in the same set without causing a problem.

Portal:

1. On Record sets, look for a TXT set named @.
2. If it exists, select its edit icon. If one value starts v=spf1, edit that value; otherwise add a new value with your SPF record. Select Apply.
3. If no @ TXT set exists, select + Add, enter @, choose TXT, paste the SPF record and select Add.

Azure CLI (from Microsoft's CLI guide):

az network dns record-set txt add-record --resource-group myresourcegroup --zone-name example.com --record-set-name "@" --value "v=spf1 include:spf.protection.outlook.com -all"

add-record creates the set if it doesn't exist, with a default TTL of 3600 seconds. The CLI guide says that to modify a TXT or MX record "you should first add a new record and then delete the existing record," using remove-record for the old value.

Azure PowerShell (from Microsoft's PowerShell guide) adds a value to an existing set with Get-AzDnsRecordSet, Add-AzDnsRecordConfig and Set-AzDnsRecordSet:

Get-AzDnsRecordSet -Name "@" -ZoneName "example.com" -ResourceGroupName "MyResourceGroup" -RecordType TXT | Add-AzDnsRecordConfig -Value "v=spf1 include:spf.protection.outlook.com -all" | Set-AzDnsRecordSet

Our SPF provider pages list each service's include, and the SPF Record Generator merges several senders into one record.

How do you add a DKIM record in Azure DNS?

DKIM as CNAME records (Microsoft 365 and many senders)

Each selector is its own CNAME record set.

1. Select + Add, enter selector1._domainkey as the Name and choose CNAME.
2. Paste the provider's target into the alias field, for example selector1-example-com._domainkey.example.n-v1.dkim.mail.microsoft, copied from the Defender portal.
3. Select Add, then repeat for selector2._domainkey.

The CLI equivalent is az network dns record-set cname set-record --resource-group myresourcegroup --zone-name example.com --record-set-name selector1._domainkey --cname <target>.

DKIM as a TXT record (Google Workspace and others)

1. Select + Add, enter the selector host, for example google._domainkey, and choose TXT.
2. Paste the whole key, starting v=DKIM1;, as one value.
3. Select Add.

How does Azure DNS handle long DKIM keys?

You don't split them yourself in the portal, CLI or PowerShell. Microsoft Learn says: "When you use the Azure portal, PowerShell, or CLI interfaces, you should specify a single string per record. This string is automatically divided into 255-character segments if necessary." Only the REST API needs each string supplied separately.

That segmenting is standard: receivers join the strings back together, as RFC 7208, section 3.3 and RFC 6376, section 3.6.2.2 both require. The limit to watch is the 4,096-character total per TXT record set. A 2048-bit key fits easily. If your provider shows the key split into quoted chunks, join it into one continuous string first, since Microsoft asks for a single string per record, then check the published value. Our guide to DKIM keys too long for a TXT record covers the general case.

Then turn signing on in your provider's console: see DKIM setup for Microsoft 365 and Google Workspace and DKIM records by provider.

How do you add a DMARC record in Azure DNS?

DMARC is a TXT record set named _dmarc.

1. Select + Add, enter _dmarc as the Name and choose TXT.
2. Enter your policy, for example v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com.
3. Select Add.

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

Keep one DMARC value in the _dmarc set. The DMARC Record Generator builds the record, and our none-to-reject guide covers tightening the policy.

How do you add or change MX records in Azure DNS?

All root MX records are one record set named @, each with a preference (priority) and an exchange (mail server).

Portal: open or create the @ MX record set, enter each mail server with its preference number, and select Add (new set) or Apply (existing set).

Azure CLI:

az network dns record-set mx add-record --resource-group myresourcegroup --zone-name example.com --record-set-name "@" --exchange example-com.mail.protection.outlook.com --preference 0

Azure PowerShell (new set):

New-AzDnsRecordSet -Name "@" -RecordType MX -ZoneName "example.com" -ResourceGroupName "MyResourceGroup" -Ttl 3600 -DnsRecords (New-AzDnsRecordConfig -Exchange "example-com.mail.protection.outlook.com" -Preference 0)

When switching providers, add the new exchange first, then remove the old one with az network dns record-set mx remove-record or Remove-AzDnsRecordConfig. Our guide to changing MX records without losing email covers the timing, and TTL and propagation explains why to lower the TTL beforehand.

What does a complete Azure DNS email setup look like?

An example zone for example.com on Microsoft 365. Your values will differ.

How do you protect email records in Azure DNS?

Email records are easy to break with an unrelated infrastructure change. Microsoft's zone protection guide offers two controls:

1. Role-based access. Grant the built-in DNS Zone Contributor role only to people who manage DNS, scoped to the zone's resource group.
2. Resource locks. Locks come in two types, CanNotDelete and ReadOnly, and apply to a public zone or an individual record set. To protect the @ MX set, use a ReadOnly lock: Microsoft notes that a CanNotDelete lock on a record set still lets someone remove every record from it. Record-set locks can currently only be set with Azure PowerShell. A ReadOnly lock on the zone stops new record sets being created and existing ones being changed.

How do you check the records after saving?

1. MX: our MX Lookup shows only your intended servers.
2. SPF: the SPF Checker finds exactly one v=spf1 value.
3. DKIM: the DKIM Checker returns a full key for each selector.
4. DMARC: the DMARC Checker parses your policy.
5. Headers: a test message to an outside mailbox shows spf=pass, dkim=pass and dmarc=pass; see how to read email headers.

Next steps

1. Run the Email Health Check after any change to the zone.
2. Lock the @ MX and TXT record sets so an infrastructure deployment can't remove them.
3. Moving mail between providers? Follow the change email hosting provider checklist.
4. The free Domain Watch checks your public MX, SPF and DMARC weekly and emails you when they change.

If you route mail through a filtering service such as iBlockSpam, the @ MX record set holds its servers instead. More walk-throughs are in setup guides.