Log inTry the sandbox free

DNS

Microsoft 365 DNS record generator

Get the handful of DNS records Microsoft 365 documents as fixed for every tenant, and a plain list of the ones only your own admin center can give you.

Free, no accountIn your browser

None of the records below change with this - it only lets the page name your own domain instead of speaking generically.

Try

Result

1 fixed record ready - MX still comes from the admin center

Add these at your domain's DNS panel, then copy MX, Autodiscover, DKIM and the verification TXT from the Microsoft 365 admin center.

  • Warning

    Merge this into an existing SPF record rather than add a second one

    Microsoft's own page is explicit that if this domain already publishes an SPF TXT record, this include has to be merged into it as another term - a domain is only allowed one SPF record, and a second one makes every SPF check on the domain fail, not just this one.

    Add "include:spf.protection.outlook.com" into your existing SPF record and keep a single "-all" at the end, instead of publishing the line below as a second record.

  • Info

    None of the records below need your domain

    The SPF value, the Teams SRV record and the two Intune CNAMEs are the same for every Microsoft 365 tenant, so typing your domain only makes this page name it instead of speaking generically.

  • Info

    Four records exist only in your own admin center - including the MX

    Microsoft's setup page treats all four as values to copy from the admin center rather than formulas anyone can publish, so nothing here guesses at them. The MX record is the one every setup actually needs and its target is tenant-specific - its priority goes to the highest value your panel allows (typically 0), and Exchange Online only supports a TTL under six hours, 21,600 seconds. The Autodiscover CNAME's target is on the same admin-center page. The two DKIM CNAMEs sit at the fixed hosts "selector1._domainkey" and "selector2._domainkey", but each target is issued to this tenant once DKIM signing is turned on. The domain-verification TXT proves ownership of this domain in particular.

    Add this domain in the Microsoft 365 admin center, then copy the MX record (with its priority and TTL), the Autodiscover CNAME, the verification TXT, and - once DKIM signing is on - the two selector CNAME targets, exactly as it displays them.

  • Passed

    SPF is fixed for every Microsoft 365 tenant

    This exact value is what Microsoft documents for every tenant sending mail through Exchange Online, with nothing in it to substitute.

SPF record to publish

v=spf1 include:spf.protection.outlook.com -all

At @ (TXT)

Publish this at the domain itself, TTL 3600. If an SPF record already exists here, merge this include into it rather than publishing a second one - see the finding above.

DNS records for your domain

HostTypeValuePriority
@TXTv=spf1 include:spf.protection.outlook.com -all-

MX, Autodiscover, the two DKIM CNAMEs and the verification TXT are tenant-specific and left out of this table on purpose - copy them from the Microsoft 365 admin center instead.

  • Microsoft documents the MX target, the Autodiscover CNAME target, the two DKIM CNAME targets and the domain-verification TXT value as "copy the value shown in the admin center" rather than a published formula, so none of the four are generated here - this is the one record every setup actually needs, and it is named rather than guessed at.

What this is

This Microsoft 365 DNS records generator writes out the handful of values Microsoft documents as fixed for every tenant - the SPF include, the Teams federation SRV record and the two Intune CNAMEs - and names, rather than guesses at, the four records that exist only inside your own admin center, starting with the MX record every setup needs.

Most of what a Microsoft 365 setup asks you to add to DNS is unique to your own tenant: the MX target, the Autodiscover CNAME, the two DKIM selectors and the domain-verification token are all generated by Microsoft only after this specific domain is added inside the admin center, which is why none of them has a formula any tool could run instead.

A smaller set is genuinely fixed and identical for every Microsoft 365 tenant: the SPF include, the Teams federation SRV record for tenants using Teams or Skype for Business, and the two CNAMEs Intune or enterprise device enrollment needs. Those are what this generator actually writes.

For how a fixed record like this SPF include differs from the tenant-specific ones above it, and what else a domain needs beyond MX, see our blog guide "The DNS records a domain needs, and what each one actually does."

How to read the result

A pass finding below means a fixed record was added to the set; an info finding names one of the four values that live only inside the admin center, with roughly where to find it there.

The Teams SRV record is shown twice on purpose: once as the single combined value a simple Host-and-value panel expects, and once broken into Service, Protocol, Priority, Weight, Port and Target for a panel that asks for each separately. Use whichever matches the boxes actually in front of you.

Common mistakes

What goes wrong most often, and how to tell.

  • Guessing the MX target from the domain nameMicrosoft 365 does not derive an MX target the way some providers do; it is issued per tenant inside the admin center once the domain is added there, so a pattern that happened to work for one domain is not a safe guess for the next.
  • Treating the Teams SRV record as optional busyworkSkipping the SRV record does not stop Teams working inside this tenant - it stops people at other organisations finding this domain for federation, which usually surfaces later as messages to an outside company going nowhere, silently.
  • Publishing a second SPF record once another provider is addedA domain is only allowed one SPF TXT record. Microsoft's own page says to merge its include into the existing one as another term, not publish a second record, which breaks SPF checking for every sender at once.

Questions

What people ask about this tool.

  • Microsoft 365 issues the MX target per tenant inside the admin center once the domain is added there, rather than deriving it from the domain name, so there is no published formula a generator could run - copying it from the admin center is the only correct source.

  • The SRV record exists for federation, letting people at other organisations find this domain through Teams or Skype for Business; a tenant that only ever talks to itself through Teams can leave it out with nothing breaking internally.

  • Windows devices look up those two CNAMEs during automatic enrollment and registration; without them in DNS, a device cannot find the right Microsoft endpoint, and enrollment fails even though every setting inside Intune itself is correct.

  • Put "_sipfederationtls._tcp" in the host field and "100 1 5061 sipfed.online.lync.com" in the value field, in that order of priority, weight, port and target - some panels also want a trailing dot after "sipfed.online.lync.com" if the record is otherwise rejected.

Sources

Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.

Use it from the API

The same check, as one request.

Request
curl -X POST https://resellerhq.com/api/tools/microsoft-365-dns-generator \
  -H "Content-Type: application/json" \
  -d '{"domain":"","services":[]}'
Response
{
  "tool": "microsoft-365-dns-generator",
  "input": {
    "domain": "",
    "services": []
  },
  "result": {
    "verdict": {
      "tone": "warning",
      "headline": "1 fixed record ready - MX still comes from the admin center",
      "summary": "Add these at your domain's DNS panel, then copy MX, Autodiscover, DKIM and the verification TXT from the Microsoft 365 admin center."
    },
    "findings": [
      {
        "id": "merge-spf-dont-duplicate",
        "severity": "warn",
        "title": "Merge this into an existing SPF record rather than add a second one",
        "detail": "Microsoft's own page is explicit that if this domain already publishes an SPF TXT record, this include has to be merged into it as another term - a domain is only allowed one SPF record, and a second one makes every SPF check on the domain fail, not just this one.",
        "fix": "Add \"include:spf.protection.outlook.com\" into your existing SPF record and keep a single \"-all\" at the end, instead of publishing the line below as a second record."
      },
      {
        "id": "domain-not-needed",
        "severity": "info",
        "title": "None of the records below need your domain",
        "detail": "The SPF value, the Teams SRV record and the two Intune CNAMEs are the same for every Microsoft 365 tenant, so typing your domain only makes this page name it instead of speaking generically."
      },
      {
        "id": "four-records-only-the-admin-center-has",
        "severity": "info",
        "title": "Four records exist only in your own admin center - including the MX",
        "detail": "Microsoft's setup page treats all four as values to copy from the admin center rather than formulas anyone can publish, so nothing here guesses at them. The MX record is the one every setup actually needs and its target is tenant-specific - its priority goes to the highest value your panel allows (typically 0), and Exchange Online only supports a TTL under six hours, 21,600 seconds. The Autodiscover CNAME's target is on the same admin-center page. The two DKIM CNAMEs sit at the fixed hosts \"selector1._domainkey\" and \"selector2._domainkey\", but each target is issued to this tenant once DKIM signing is turned on. The domain-verification TXT proves ownership of this domain in particular.",
        "fix": "Add this domain in the Microsoft 365 admin center, then copy the MX record (with its priority and TTL), the Autodiscover CNAME, the verification TXT, and - once DKIM signing is on - the two selector CNAME targets, exactly as it displays them."
      },
      {
        "id": "spf-ready",
        "severity": "pass",
        "title": "SPF is fixed for every Microsoft 365 tenant",
        "detail": "This exact value is what Microsoft documents for every tenant sending mail through Exchange Online, with nothing in it to substitute."
      }
    ],
    "parts": [
      {
        "kind": "record",
        "title": "SPF record to publish",
        "value": "v=spf1 include:spf.protection.outlook.com -all",
        "note": "Publish this at the domain itself, TTL 3600. If an SPF record already exists here, merge this include into it rather than publishing a second one - see the finding above.",
        "at": {
          "name": "@",
          "type": "TXT"
        }
      },
      {
        "kind": "table",
        "title": "DNS records for your domain",
        "columns": [
          "Host",
          "Type",
          "Value",
          "Priority"
        ],
        "mono": [
          2
        ],
        "rows": [
          [
            "@",
            "TXT",
            "v=spf1 include:spf.protection.outlook.com -all",
            "-"
          ]
        ],
        "note": "MX, Autodiscover, the two DKIM CNAMEs and the verification TXT are tenant-specific and left out of this table on purpose - copy them from the Microsoft 365 admin center instead."
      }
    ],
    "limits": [
      "Microsoft documents the MX target, the Autodiscover CNAME target, the two DKIM CNAME targets and the domain-verification TXT value as \"copy the value shown in the admin center\" rather than a published formula, so none of the four are generated here - this is the one record every setup actually needs, and it is named rather than guessed at."
    ]
  }
}

Resell the domains these records point at, at your own price, under your own brand.

Get started

Company names and logos are trademarks of their owners, shown only to identify each service.