Microsoft 365 / Email DNS records: check MX, SPF, DKIM, and DMARC
For Microsoft 365 email, DNS (Domain Name System) records route incoming mail and support authentication of outgoing mail. A mail-exchanger (MX) record identifies the receiving server; Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) provide different authentication checks and policy information. Verify domain ownership and inventory Microsoft 365 and external sending services before changing these records.
Roles of the four records
| Record or technology | Main roles | Common mistakes |
|---|---|---|
| MX | Specifies which server receives mail sent to the domain | Changing MX redirects new incoming mail; prepare destination mailboxes before the cutover. |
| SPF | Declare the range of servers that can send on behalf of the domain in DNS. | Do not create multiple different SPF TXT (text) records on the same domain. |
| DKIM | Add a signature to outgoing emails and verify it with the public key in DNS. | After adding the DNS record, also check the activation of the signature for the domain. |
| DMARC | Evaluate the alignment between the displayed From domain and SPF/DKIM authentication results, and convey the processing policy. | If you apply a strict rejection policy without investigating the sender, even legitimate emails can be affected. |
Microsoft’s email authentication deployment guide instructs setting up SPF, DKIM, and DMARC for custom domains. DMARC does not always pass just because either SPF or DKIM succeeds; it also checks the alignment with the displayed sending domain.
SPF declares which sending sources are authorized. With DKIM, the sender uses a private key to sign parts of the message, and the recipient uses a public key published through DNS to verify the signature. DMARC checks alignment with the visible From domain and publishes the requested failure policy and reporting destination. These authentication capabilities are included in the built-in protection for cloud mailboxes; other Defender features can have additional licensing requirements.
SPF checks the domain used in MAIL FROM, the envelope sender address used between mail servers. This can differ from the From address shown to the reader. A DKIM signing domain can also belong to the service provider. A customer relationship management (CRM) service might therefore pass SPF and DKIM with its provider’s domain but still fail DMARC for the company domain shown in From. The key requirement is that at least one aligned SPF or aligned DKIM result passes.
Alignment can be relaxed (the same organizational domain, allowing subdomains) or strict (an exact domain-name match). The optional aspf and adkim tags control SPF and DKIM alignment separately; both default to relaxed (r). Check these modes when a sending service uses a subdomain.
Investigate the sending path before configuration
- Emails sent by employees from Exchange Online
- Emails sent by external systems such as website inquiry forms, CRM, marketing services, and multifunction devices
- Sending services that use subdomains separately
- The path through a mail security gateway or relay server
If the sending source is omitted, legitimate emails may be rejected after strengthening SPF, DKIM, and DMARC. Remove sending sources that are not used, and authenticate required services according to the official guidance of the respective provider.
Order of verification in Microsoft 365
- In the Microsoft 365 admin center, open the target domain in [Settings] → [Domains] and check the DNS configuration status. Use the MX values shown in the domain wizard for that domain.
- Check the current SPF TXT records with your DNS hosting provider. If sending sources outside Microsoft 365 need to be included, integrate them into the existing values.
- In the mail authentication settings of the Microsoft Defender portal, check the DKIM status of the custom domain and the required DNS records. After adding the suggested values to the DNS, verify that signing is activated.
- Introduce DMARC gradually. Analyze actual senders and authentication failures through reports, then decide on policy strengthening. If you only add the policy statement without reading the reports, it is difficult to detect issues.
- Send a test email to an external address outside the organization and check the SPF, DKIM, and DMARC results and alignment in the receiving headers. Even if the DNS status is normal, you need to test the actual sending path.
Conditions under which the SPF example can be used as is
For a custom domain whose public DNS you manage, the following TXT value is a basic example when Microsoft 365 is the only sending service. This example applies to Microsoft’s worldwide commercial service; special government or China-operated clouds can require different include domains. Use the service-specific values in your admin center and documentation. If a website or marketing service also sends directly using the same domain, do not replace your current policy with this example alone. Compare the domain wizard and each sender’s official configuration guidance.
v=spf1 include:spf.protection.outlook.com -allinclude refers to the Microsoft 365 sending scope and -all declares external senders that do not match this to be treated as SPF failures. Creating two SPF TXT records with the same name to separately include Microsoft 365 and external services is an incorrect configuration. Design the necessary senders as a single SPF policy and remove unnecessary senders. TXT records for ownership verification other than SPF have a different purpose and are not subject to removal. Select based on the sending scenarios in Microsoft SPF setup guide.
When combining services, also check SPF’s limit of 10 DNS lookups during evaluation. Nested include mechanisms count too: fewer than 10 providers or include entries does not guarantee that the evaluation stays within the limit.
Values to select when setting up DKIM and DMARC
In the Defender portal, open the custom domain under Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Generate keys if required, then enter the names and targets of the two CNAME (canonical name) records shown in the domain details at your DNS provider. A CNAME record points one DNS name to another; in this setup it connects the DKIM lookup to Microsoft’s key records. Copy the selector names and targets supplied for your tenant instead of constructing them from an old blog. Microsoft introduced a new target format for new custom domains in May 2025, while existing domains can retain the older format.
After DNS propagation, activate the DKIM signature toggle for the domain and check if it is signing. If the CNAME is missing, recheck the input name, the actual DNS provider, and the detection time. Do not assume the signature is enabled just because both records are saved. You can check the procedure for proceeding according to the current status in DKIM official setup procedure .
The initial DMARC policy can be set as a report-focused configuration that can analyze legitimate senders. Below is an example using example.com as a sample domain. Publish the TXT record at _dmarc for your own domain, and replace dmarc@example.com in the rua=mailto: value with a real report mailbox controlled by your organization. The sample address is not a destination to use unchanged.
v=DMARC1; p=none; rua=mailto:dmarc@example.comp=none is a starting policy that does not request quarantine or rejection for DMARC failures themselves, and it does not disable other spam or security filters. rua is the address to receive aggregate reports. You need to be ready to actually receive and analyze at that address, and if using an external reporting service address, you must also check additional DNS approval conditions. After verifying the alignment of legitimate senders and the delivery path, you strengthen the policy to quarantine and reject steps. Detailed conditions follow the DMARC implementation guidelines.
Verify DNS records and authentication on newly sent mail
Send new emails to a test address for each sending path, such as employee mail, web inquiry forms, CRM, etc. On the receiving side, open the original message and internet headers to check SPF, DKIM, and DMARC results in the receiving system’s Authentication-Results, and also compare the DKIM signing domain with the displayed From. You need the results of newly sent messages after changes rather than "old mails were normal."
If DNS is normal but a specific CRM fails, check the sending domain and signing settings for that path first. If the signed body changes or the sending server differs during the delivery process, results may vary. Authentication passing does not guarantee inbox delivery, and reputation, spam, and content policies also have an impact.
The record values vary depending on the domain and the time of configuration. The purpose of this article is not to memorize the values, but to compare the values provided by the management center, the actual values in DNS, and the authentication results on the receiving side. If there are issues with receiving or sending emails, identify the scope of impact based on the DNS records before the changes. If legitimate emails are affected, compare the previous policy and sender configuration to restore only the problematic changes and test again. Do not delete all SPF, DKIM, and DMARC records or maintain a strict DMARC policy without knowing the cause. In the report, distinguish between failures of legitimate senders and suspicious forged sends, and determine follow-up actions accordingly.
