How to find domainGUID and initialDomain for DKIM setup with custom domains in Office 365?
Michael Ko
Co-founder & CEO, Suped
Published 30 Jul 2025
Updated 19 Aug 2025
7 min read
Setting up DKIM for your custom domain in Office 365 can feel like solving a puzzle, especially when you encounter terms like domainGUID and initialDomain. These values are crucial for correctly configuring DNS records, ensuring your emails are properly authenticated. Without them, your outbound messages might face deliverability issues, ending up in spam folders or being rejected.
This article will walk you through exactly what domainGUID and initialDomain mean in the context of Office 365 DKIM setup. I'll show you how to find these values and how to use them to create the essential CNAME records for your custom domain, helping you ensure strong email authentication and avoid email blocklists.
DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect email spoofing. It allows the recipient system to check that an email claiming to come from a specific domain was authorized by the domain's owner. This is done by adding a digital signature to the email header. For Office 365 users, enabling DKIM is a critical step for improving email deliverability and protecting your brand's reputation.
When you first set up your Microsoft 365 tenant, Office 365 automatically configures DKIM for your default onmicrosoft.com domain. This ensures that emails sent from your initial Microsoft-provided domain are signed and authenticated right out of the box. However, the situation changes once you introduce a custom domain, such as yourcompany.com, which is typically used for primary email communication.
For these custom domains, you need to manually configure DKIM by adding specific CNAME records to your domain's DNS. These CNAME records link back to Microsoft's DKIM signing infrastructure. The challenge often lies in correctly identifying the unique domainGUID and initialDomain values required to build these CNAME records. This manual setup is essential for proper email authentication for your custom domains.
Locating your domainGUID
The domainGUID (Globally Unique Identifier) is a unique string that Microsoft assigns to your custom domain within its system. This identifier is part of the CNAME record structure needed for DKIM. You won't find it explicitly labeled as domainGUID in your Microsoft 365 admin portal, but it's embedded within other configurations, particularly your MX (Mail Exchange) record.
The easiest way to find your domainGUID is by examining your custom domain's MX record. For domains configured with Office 365, the MX record typically follows a pattern like domainGUID.mail.protection.outlook.com. The segment before .mail.protection.outlook.com is your domainGUID. For example, if your MX record is yourcompany-com.mail.protection.outlook.com, then yourcompany-com is your domainGUID.
You can also retrieve your domainGUID using PowerShell. Connect to Exchange Online PowerShell and run the command Get-MsolDomain. The ObjectId value returned for your domain is essentially your domainGUID. This method offers a precise way to confirm the identifier.
It is important to know that the domainGUID is the same identifier found in your customized MX record. It acts as a unique tag for your custom domain within Microsoft's systems, critical for establishing trust and proper routing. For more information on configuring DKIM for Office 365, you can refer to the official Microsoft documentation on email authentication.
The domainGUID is the same identifier found in your customized MX record. It acts as a unique tag for your custom domain within Microsoft's systems, critical for establishing trust and proper routing.
Identifying your initialDomain
The initialDomain refers to the original domain that Microsoft Office 365 assigned to you when you first signed up for the service. This domain always ends with .onmicrosoft.com (e.g., yourtenant.onmicrosoft.com). It is a foundational part of your Microsoft 365 environment, even if you primarily use custom domains for your email. This value is also crucial for building the DKIM CNAME records.
You can find your initialDomain by navigating to the Microsoft 365 admin center and looking under Settings > Domains. You will see a domain listed that ends with .onmicrosoft.com. The part before .onmicrosoft.com is your initialDomain. For instance, if your default domain is contoso.onmicrosoft.com, then contoso is your initialDomain.
Understanding the initialDomain is important because it forms the canonical target for your DKIM CNAME records. Even though your emails will appear to come from your custom domain, the underlying Microsoft infrastructure uses this initialDomain for DKIM signing. It's a consistent part of your tenant's identity within the Microsoft ecosystem.
Example initialDomaindns
# Example of a Microsoft 365 initial domain
contoso.onmicrosoft.com
Configuring DKIM CNAME records
Once you have both your domainGUID and initialDomain, you are ready to create the two necessary CNAME records in your DNS. These records are vital for enabling DKIM signing for your custom domain. The CNAME records typically follow a specific pattern, pointing two selectors (usually selector1 and selector2) to Microsoft's DKIM infrastructure. Each CNAME record will combine your selector, domainGUID, and initialDomain.
The general format for the hostnames is selector1._domainkey.yourcustomdomain.com and selector2._domainkey.yourcustomdomain.com. The value (or "points to address") for these records will be selector1-domainGUID._domainkey.initialDomain.onmicrosoft.com and selector2-domainGUID._domainkey.initialDomain.onmicrosoft.com respectively. It is crucial to ensure these DNS records are added exactly as specified, as even small errors can prevent DKIM from functioning. A good resource for understanding these records further is Practical 365's guide on keeping emails out of spam folders. After adding these CNAME records to your DNS, allow time for DNS propagation. Once propagated, you can enable DKIM signing in the Microsoft 365 Defender portal. You can also troubleshoot any Office 365 DKIM and SPF email authentication failures or check for common DKIM alignment errors.
Ensure you add these DNS records exactly as specified. Even a small typo can prevent DKIM from functioning correctly and impact your email deliverability. Always double-check your entries before saving changes.
Views from the trenches
Best practices
Always verify your DNS records after publishing them to ensure correct propagation and avoid common DKIM issues.
Implement a DMARC policy to gain visibility into your email authentication status and identify any potential spoofing attempts.
Regularly monitor your email deliverability metrics to catch any sudden drops in inbox placement that might indicate authentication problems.
Common pitfalls
Forgetting to enable DKIM in the Microsoft 365 Defender portal after adding the CNAME records to your DNS.
Typographical errors when entering the domainGUID or initialDomain values into the CNAME records, leading to failed authentication.
Not allowing sufficient time for DNS changes to propagate globally before testing your DKIM setup, leading to false negatives.
Expert tips
Use PowerShell to retrieve the exact domainGUID and initialDomain values to minimize human error during manual configuration.
Before making changes in a production environment, test your DKIM setup with a smaller, non-critical custom domain if possible.
Be aware that some DNS providers might append your domain name automatically, so only enter the hostname part without the full domain.
Marketer view
The domainGUID is typically found by extracting the first part of your domain's MX record in your DNS settings. It's often the string before mail.protection.outlook.com.
2023-08-15 - Email Geeks
Expert view
The initialDomain refers to the original onmicrosoft.com domain that was provisioned with your Microsoft 365 tenant. This is usually yourtenantname.onmicrosoft.com.
2024-01-20 - Email Geeks
Finalizing your DKIM setup
Successfully finding your domainGUID and initialDomain values, then correctly applying them to your DKIM CNAME records, is a fundamental step in ensuring your emails are properly authenticated when sent from Office 365 with a custom domain. This process, while seemingly intricate, is crucial for maintaining sender reputation and achieving optimal email deliverability.
By following these steps, you reinforce your domain's trustworthiness and reduce the likelihood of your legitimate emails being flagged as spam or rejected. Proper DKIM configuration, alongside SPF and DMARC, forms the backbone of robust email security, protecting your communications and enhancing your overall sending reputation.
Microsoft's systems, critical for establishing trust and proper routing. For more information on configuring DKIM for Office 365, you can refer to the official Microsoft documentation on email authentication.
