trustyourinbox
← All articles

Editing DNS records in Azure DNS

trustyourinbox detected your domain's DNS is on Azure DNS. We don't have an Azure DNS adapter yet, so the records we recommend need to be published by you in the Azure portal (or via az CLI, ARM templates, or Terraform). Azure DNS does the auto-segmentation for long TXT values for you, which makes DKIM keys easier to publish here than on Route 53.

RBAC role you need

Your Microsoft Entra ID account or service principal needs DNS Zone Contributor (Microsoft.Network/dnsZones/*) on the resource group or the specific zone. The narrower Readerrole only lets you view records — you can't add or edit. If your org limits access, ask the resource-group owner for Contributor on just the relevant zone.

Step 1 — Open the DNS zone

  1. Sign in to the Azure portal.
  2. In the top-bar search, type DNS zones and click the DNS zones service. (Or navigate via All services → Networking → DNS zones.)
  3. Click your zone name in the list.

Step 2 — Add the record set

  1. At the top of the zone's overview page, click + Record set.
  2. Fill the fields per the fix type below. Azure DNS rule: use @ for apex (consistent with most providers, unlike Cloud DNS which uses blank).

DMARC

  • Name: _dmarc
  • Type: TXT
  • Alias record set: No
  • TTL: 5 + TTL unit: Minutes (or 1 + Hours for less frequent rollback)
  • Value: paste the record exactly as trustyourinbox suggested, e.g. v=DMARC1; p=quarantine; pct=100; rua=mailto:<your-rua>@rua.trustyourinbox.com

SPF

  • Name: @
  • Type: TXT (Azure DNS does NOT support the obsolete SPF record type — TXT is the only option, which is correct per RFC 7208)
  • Alias record set: No
  • Value: v=spf1 …mechanisms… ~all
  • Critical: only ONE v=spf1 record per apex. If a TXT record set already exists at @ with a v=spf1 entry, click that existing record set → Edit → modify the value — don't create a second.

DKIM (Azure auto-segments — easiest of the major providers)

  • Name: the selector + ._domainkey (e.g., google._domainkey, k1._domainkey)
  • Type: TXT
  • Value: paste the entire public-key string from your ESP into the Value box without splitting. Azure DNS automatically segments it into 255-character strings on save (per the Azure DNS docs: "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.")
  • This is the easiest provider for DKIM — no manual "part1" "part2" splitting required, unlike Route 53.

MTA-STS DNS pointer

  • Name: _mta-sts
  • Type: TXT
  • Value: v=STSv1; id=<numeric-id>
  • The actual policy file is hosted separately at mta-sts.<your-domain>/.well-known/mta-sts.txt over HTTPS — usually an Azure App Service or Static Web App, not Azure DNS. trustyourinbox can host the policy file for you (separate setup).

Multiple TXT entries on the same name

Azure DNS supports up to 400 TXT records in a single record set (well beyond the practical limit) and 4,096 total characters across all records combined. To add more entries to an existing TXT record set, click the existing record set in the table → + Add button at the top of the edit blade. Each entry becomes a separate record within the set.

Step 3 — Save

Click OK at the bottom of the Add Record Set blade. Azure DNS propagates to its global anycast network within seconds. Receivers honor the TTL on the record they last cached.

Step 4 — Verify the record published

From a terminal:

  • DMARC — dig +short TXT _dmarc.yourdomain.com
  • SPF — dig +short TXT yourdomain.com | grep spf1
  • DKIM — dig +short TXT <selector>._domainkey.yourdomain.com
  • MTA-STS pointer — dig +short TXT _mta-sts.yourdomain.com

For DKIM specifically, digshows the multi-string form Azure DNS produced after auto-segmentation. The strings are concatenated by receivers per RFC 1035 §3.3.14 — the customer's mailbox provider sees the full key, not the split.

Step 5 — Tell trustyourinbox to recheck

Each per-domain protocol tab has a Recheck button. Click it after the Azure DNS edit propagates; we run a fresh DoH lookup against Cloudflare 1.1.1.1 and Google 8.8.8.8 in parallel and update the dashboard immediately.

Common Azure DNS pitfalls

  1. Forgetting @ for apex. Leaving Name blank or putting your full domain creates a record at the wrong host. Use @.
  2. Looking for an "SPF" record type.Azure DNS only offers TXT. That's correct — RFC 7208 deprecated the SPF type. Use TXT.
  3. Adding a second SPF record set. RFC 7208 §3.2 violation. Always edit the existing apex TXT record set.
  4. Manually splitting DKIM into "part1" "part2" format. Azure DNS does the segmentation for you on save. Pasting pre-quoted multi-string format means each quoted string becomes one record — wrong.
  5. Using the wrong subscription.If your zone is in a different Azure subscription than the one currently selected in the top-right, you won't see it in the DNS zones list. Use the subscription filter at the top of the list.
  6. Insufficient RBAC. If + Record set is greyed out or save fails with 403, your account doesn't have DNS Zone Contributor on this zone. Ask the resource group owner.

If you get stuck

Open the per-domain page in trustyourinbox, click Recheck, and if the dashboard still shows the issue, paste the dig +short TXT <hostname>output into a support email. We'll narrow down the difference between what we expected and what Azure DNS published.

Stop guessing. Start monitoring.

Free for 1 domain. Set up in 5 minutes. We handle the report parsing, you read plain-English summaries.

Run a free audit