MX, A and PTR records for Outlook and Microsoft 365

To receive mail at Microsoft 365, publish one MX record pointing at the host Microsoft generated for your tenant, and one CNAME for Autodiscover. To *send* mail that Microsoft and everyone else accepts, you also need the sending host's forward and reverse DNS to agree — and that part is not in the Microsoft 365 setup wizard.

The MX record for Microsoft 365

Microsoft gives you a hostname derived from your domain with the dots replaced by dashes:

Take the exact value from the Microsoft 365 admin centre under your domain's DNS records rather than constructing it by hand; tenants in some regions differ. Then:

• Use one MX record. Microsoft 365 is a single front door with its own redundancy behind that one name. Adding a second MX at a higher priority number does not add resilience — it adds a backup path that spammers will target because secondary MXes usually filter less.
• Delete the old provider's MX records the moment you cut over. Leaving them means a share of your mail is quietly delivered to a mailbox nobody reads.
• Lower the TTL to 300 seconds a day before the cutover, then raise it back to 3600 afterwards.

Verify:

dig +short MX yourdomain.com
dig +short MX yourdomain.com @8.8.8.8

The second form skips your own resolver's cache. If the two disagree, you are looking at propagation, not a mistake.

Lower numbers win in MX priority, and equal numbers mean round-robin. A common error is reading priority backwards and sending all mail to a backup.

Common MX problems

• A CNAME at the apex. Many DNS hosts let you create one; it breaks MX resolution and sometimes the whole zone. Use the flattening or ALIAS record type your host provides, or point the apex at an A record.
• A trailing-dot mismatch. Some control panels want mail.protection.outlook.com. with the dot, others append your domain if you omit it, producing ...outlook.com.yourdomain.com. Always re-read the saved record.
• MX pointing at a CNAME. MX targets must be hostnames with A/AAAA records. Pointing an MX at a CNAME is non-conformant and some senders will refuse it.
• Domain not verified in the tenant. Mail arrives at Microsoft and is rejected with 550 5.4.1 Recipient address rejected: Access denied because the tenant does not own the domain yet.

The A record: why your sending host needs one

An A record maps a hostname to an IPv4 address (AAAA for IPv6). For receiving mail, its job is to resolve your MX target. For *sending*, it has a different and more important job: the hostname your mail server announces in its SMTP HELO/EHLO must resolve forward to the IP it is connecting from.

dig +short A mail.yourdomain.com

If you send only through Microsoft 365, Microsoft owns this and you can stop here. If you run your own MTA or a self-hosted relay, this is yours to get right.

A record vs CNAME: use an A record for anything another record points at (MX targets, the HELO hostname, a hostname with its own PTR) and a CNAME only for aliases that follow someone else's infrastructure, such as autodiscover. CNAMEs cost an extra lookup and cannot coexist with other record types at the same name.

Reverse DNS (PTR): the one you cannot set yourself

A PTR record maps an IP address back to a hostname, and it lives in the in-addr.arpa zone controlled by whoever owns the IP — your hosting provider, cloud vendor or ISP. You request it; you do not publish it.

dig -x 203.0.113.9 +short

What receivers want is forward-confirmed reverse DNS: the IP resolves to a hostname, and that hostname resolves back to the same IP. They also compare it with your SMTP banner. A mismatch between the banner hostname and the PTR is a well-known spam heuristic, and some receivers reject outright with 550 5.7.1 Reverse DNS does not match SMTP banner.

To fix it:

1. Decide the canonical name of the sending host, e.g. mail.yourdomain.com.
2. Publish an A record for it pointing at the sending IP.
3. Ask the IP owner to set the PTR for that IP to the same name.
4. Set your MTA's HELO name to the same string. In Postfix that is myhostname; in Exim, primary_hostname.
5. Re-check dig -x and the banner with openssl s_client -starttls smtp -connect mail.yourdomain.com:25.

Generic PTRs like ec2-203-0-113-9.compute-1.amazonaws.com or anything containing dynamic, dsl or pool are treated as consumer-grade space and filtered accordingly. If your provider will not set a custom PTR, you are on the wrong provider for sending mail.

What Microsoft now expects from senders

Microsoft tightened requirements for high-volume senders to consumer Outlook, Hotmail and Live addresses in 2025: SPF, DKIM and DMARC must all be in place, with at least p=none, and sender hygiene — working unsubscribe, low complaint rates, no spam-trap hits — is enforced rather than advisory. Failing senders are routed to junk and eventually rejected. This mirrors the requirements Google and Yahoo introduced in February 2024. If you send to Outlook.com addresses at any scale, treat all three records as mandatory, not best practice.

What not to do

• Do not use an IP address as an MX value. MX targets are hostnames.
• Do not keep a "backup MX" on a cheap VPS. It will accept mail for addresses that do not exist and generate backscatter.
• Do not point multiple domains' HELO at one IP with one PTR and expect all of them to match. The PTR is per-IP; pick one canonical name and use it in every banner.
• Do not chase propagation with repeated edits. Query an authoritative nameserver directly: dig MX yourdomain.com @ns1.yourdnshost.com.
• Do not assume a passing MX lookup means mail flows. Send a real test message and read the Received chain.

MailPilot checks the SPF, DKIM and DMARC records on your sending domain and warms Microsoft 365 and Outlook mailboxes over OAuth, measuring where messages actually land at Microsoft rather than assuming a clean DNS report means a clean inbox.