SPF, DKIM, and DMARC: Best Practices for Microsoft 365 and Google Workspace Email Security

Illustration of email security

Implementing SPF, DKIM, and DMARC within Microsoft 365 and Google Workspace is critical to defending against email-based cyber threats. This guide will walk you through the “spf dkim and dmarc best practices for microsoft 365 and google workspace”, helping you to establish a robust email defense without unnecessary complexity.

Key Takeaways

  • SPF, DKIM, and DMARC are critical protocols for securing email in Microsoft 365 and Google Workspace, helping to authenticate sending sources, maintain email integrity, and dictate actions for failed authentication, thus protecting domains from phishing and spoofing attacks.

  • Configuring SPF, DKIM, and DMARC for Microsoft 365 involves creating specific DNS records for authorized IP addresses, enabling DKIM signing through the Defender portal or PowerShell, and setting DMARC policies to verify domain alignment while using reporting to monitor email traffic and authentication issues.

  • For Google Workspace, setting up SPF requires adjusting DNS TXT records to include Gmail servers, whereas enabling DKIM authentication entails generating and publishing a unique domain key followed by crafting a DMARC policy in DNS that specifies handling and reporting of emails that fail SPF or DKIM checks.

Understanding SPF, DKIM, and DMARC in Email Security

Illustration of email security

At the heart of email security lie three fundamental protocols – SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting & Conformance). Together, these form the foundation of a secure email framework, effectively thwarting email spoofing and phishing attacks. By authenticating the source and preserving the integrity of emails, they not only protect a domain from misuse but also enhance its reputation and foster trust with recipients.

SPF and DKIM play pivotal roles in mitigating phishing and spoofing risks. SPF prevents unauthorized use of a domain in sending emails by stipulating allowed mail servers. DKIM, on the other hand, adds a digital signature for receiver verification. The cherry on top is DMARC, which leverages the functions of SPF and DKIM. It provides instructions to receiving servers on handling emails failing these checks, further fortifying against email-based threats.

Essential Setup for Microsoft 365: SPF, DKIM, and DMARC

Setting up SPF, DKIM, and DMARC is crucial for an effective email security strategy in Microsoft 365. These protocols establish the first layer of domain email authentication by verifying authorized mail servers and provide additional layers of email authentication. They also dictate how email failures should be handled, ensuring comprehensive protection against spoofing.

Configuring Your SPF Record for Microsoft 365

Validating authorized IP addresses to send outgoing messages on behalf of your domain is a key function of SPF authentication. The process begins with the creation of an SPF TXT record at your domain registrar. This record should include ‘include:spf.protection.outlook.com’, with the syntax being ‘v=spf1 include:spf.protection.outlook.com -all’. If you’re using Microsoft 365 Government Community Cloud High (GCC High) and Department of Defense (DoD), the SPF TXT record should include ‘v=spf1 include:spf.protection.office365.us -all’.

Keep in mind, each subdomain sending emails requires its own SPF TXT record since the parent domain’s record doesn’t automatically apply to subdomains. For complete coverage, the SPF TXT record should include the IP addresses of any on-premises email servers that send mail from the same domain.

Implementing DKIM Signing for Microsoft 365 Domains

Careful configuration of DKIM starts with creating necessary CNAME records at your domain registrar for custom domains in Microsoft 365. This involves setting up two specific CNAME records, each pointing to a unique URI provided by Microsoft. Incorporating your domain’s dns records in this dns configuration process is essential for the proper functioning of your custom domains. Microsoft 365 employs two DKIM selectors for custom domains, with only one active at a time for email signing.

Once the CNAME records have been added to the domain’s DNS settings, DKIM signing is enabled via the Microsoft 365 Defender portal or Exchange Online PowerShell. Before you proceed, ensure that the public key for DKIM signing is published in the DNS records as a TXT or CNAME record. To maintain email security, make sure that DKIM-signed outbound emails use a domain that matches the RFC5322.From domain, and the rsa-sha256 signing algorithm is used for creating signature hashes.

Activating email signing initiates the process of sending emails with your domain’s encrypted signature, marking the setup completion.

Establishing a DMARC Policy for Microsoft 365

DMARC serves as the final layer of email security, leveraging SPF and DKIM results to verify domain alignment between the MAIL FROM and From addresses, thereby mitigating email spoofing. A message passes DMARC when either SPF or DKIM passes and the domain aligns with the From address domain, thus verifying the email’s authenticity.

Setting up DMARC involves:

  1. Creating a TXT record in DNS with the hostname ‘_dmarc’, which specifies the DMARC policy and instructions for reporting.

  2. DMARC policies should primarily be set to ‘reject’, or ‘quarantine’ as a secondary option, with a recommendation to avoid using the ‘pct’ element or ensure it is set to 100.

  3. Starting with a policy of ‘none’ is a transitional state, and better policies such as ‘reject’ or ‘quarantine’ should be adopted to maximize email security.

A gradual implementation of DMARC is advised, beginning with a policy of ‘none’ and proceeding to ‘reject’ once proper validation ensures no legitimate email is affected. DMARC reports are integral for specifying where to send summaries of DMARC results and detailed reports on individual email authentication failures.

Optimizing Google Workspace with SPF, DKIM, and DMARC

Implementation of SPF, DKIM, and DMARC protocols can significantly enhance email security for Google Workspace users. Similar to Microsoft 365, these protocols play a pivotal role in ensuring proper email authentication and protection against spoofing in Google Workspace.

Setting Up a Valid SPF Record in Google Workspace

Establishing a valid SPF record in Google Workspace involves accessing the DNS TXT record settings via your domain provider’s management console. The SPF record for a domain sending emails only from Google Workspace should be: v=spf1 include:_spf.google.com ~all. If you have additional email senders outside of Google Workspace, you’ll need to create a custom SPF record that includes those senders.

The Time-To-Live (TTL) for the SPF record should be set to 1 hour or 3600 seconds for optimal results. Remember that if you’re managing a subdomain, the SPF record must be applied directly to the subdomain and is not automatically inherited from the primary domain. To avoid any complications, ensure that your domain has only one SPF record, except when applying SPF to subdomains with the Host setting.

After updating SPF records, it can take up to 48 hours for SPF authentication to become active.

Enabling DKIM Authentication in Google Workspace

To authenticate DKIM in Google Workspace, follow these steps:

  1. Sign into the Admin Console.

  2. Navigate to Apps > Google Workspace > Gmail > Authenticate email.

  3. Choose the domain for DKIM setup.

  4. Click ‘Generate new record’.

  5. Select a 1024-bit key length.

  6. Keep the Prefix selector as default.

Once you’ve generated the DKIM record, you can copy the DKIM values and add them as a TXT record in your domain’s DNS settings. To turn on DKIM signing, return to the Authenticate Email section, select your domain, and click ‘Start Authentication’. Be mindful of DNS TXT record character limits to avoid errors.

Crafting Your DMARC Strategy in Google Workspace

Implementing a DMARC strategy for Google Workspace requires the addition of a TXT record named _dmarc to your domain’s DNS settings. After adding the DMARC TXT record, you can use the Google Admin Toolbox’s Dig feature to verify that it is formatted correctly within your DNS settings.

A DMARC record is identifiable by a TXT record entry starting with v=DMARC, and the policy is defined through tags like p for the policy, rua for reporting, and optionally sp for subdomain policy. To define the policy for email handling, you can use the p tag with options ‘none’, ‘quarantine’, or ‘reject’, and configure policy alignment with tags adkim and aspf for DKIM and SPF. Be mindful of automatic domain name appending by some domain hosts when setting up the DMARC TXT record name, as this could lead to formatting issues.

Best Practices for Maintaining Email Authentication Protocols

Proper maintenance of email authentication protocols demands continuous monitoring and strict adherence to recommended practices. It’s crucial to regularly review and update SPF records to ensure all authorized IP addresses are included and to remove any that are outdated or decommissioned. Implementing a regular rotation of DKIM keys also bolsters security. Think of it as changing passwords periodically, which involves generating new keys and revising DNS records.

Monitoring DMARC reports frequently can provide valuable insights into email traffic and spot unauthorized domain usage, enhancing your understanding of authentication issues. Using these insights, you can refine your DMARC policy, moving from a ‘none’ policy to stricter options as confidence in your email authentication processes grows. Utilizing verification tools to confirm that SPF and DKIM records are properly configured is another recommended best practice.

Troubleshooting Common Issues with SPF, DKIM, and DMARC

Despite being potent tools for enhancing email security, SPF, DKIM, and DMARC come with their own set of challenges. Common issues include fail spf due to DNS lookup constraints, character limits for records, maintaining up-to-date records, SPF record syntax errors, and exceeding the DNS lookup limit. These can be resolved by ensuring only one SPF record with proper syntax and termination, staying within 10 DNS lookups, and listing all authorized sending IP addresses.

DKIM failures often result from authentication issues due to outgoing message alterations by mail servers, incorrect DKIM keys, or messages not passing authentication. You can troubleshoot these issues by checking for ‘body hash did not verify’ in the headers and ensuring outbound gateways don’t modify messages post-DKIM signing. Also, ensure that the DKIM record in the Admin console matches the provider’s value.

Integrating Third-Party Services with SPF, DKIM, and DMARC

A seamless integration of third-party services with SPF, DKIM, and DMARC is achievable with the correct approach. Before enabling DMARC, ensure third-party mail services used are authenticated with SPF and DKIM to prevent legitimate messages from failing DMARC checks. Messages sent from third-party email services should be authenticated with SPF and DKIM to ensure they align with DMARC policies.

Add the IP address of third-party email services’ sending mail servers to your domain’s SPF record to ensure messages are authenticated. If you’re using third-party apps or services to send email on your behalf, include their mail server in your SPF record for proper email authentication. Collaborate with third-party providers to confirm DKIM setup and align the provider’s sending domain with your own domain’s DKIM records.

Monitoring and Analyzing DMARC Reports

DMARC reports serve as vital resources for domain owners aiming to scrutinize and understand their email traffic. By providing insights into authentication successes and failures, they can help identify and correct configuration issues with the source, ensuring robust email authentication and security.

DMARC reports are bifurcated into Aggregate Reports, which provide a summary of a period’s results, and Failure Reports, which give details on individual failed messages. To facilitate DMARC report analysis, you can use tools such as EasyDMARC’s Analyzer and Mimecast’s Record Checks. Additionally, dedicated management of report volume is recommended.


In today’s cyber-threat-laden landscape, implementing SPF, DKIM, and DMARC can significantly bolster your email security. These protocols authenticate the source of your emails, maintain their integrity, and build trust with recipients. Whether you’re using Microsoft 365 or Google Workspace, mastering these protocols can protect your domain from misuse, enhance your reputation, and foster trust with recipients.

Frequently Asked Questions

Does Office 365 need DMARC?

Yes, Office 365 users should enable and manage DMARC for their own domain to ensure proper email security and protection against phishing and domain spoofing. It is an essential tool for organizations using Office 365.

Does Gmail require SPF and DKIM?

Yes, Gmail requires SPF and DKIM for sender authentication. Both SPF and DKIM authentication are necessary for strongly authenticating emails sent through Gmail.

Does Google Workspace support DMARC?

Yes, Google Workspace supports DMARC, and to configure it, you need to set up DKIM and SPF first. These authentication methods are used in conjunction with DMARC to enhance email security.

How do I add SPF and DKIM records to Google Workspace?

To set up SPF for Google Workspace, log in to your domain’s DNS dashboard and create or update the TXT record starting with v=spf1. For DKIM, sign in to the Admin Console, navigate to Apps > Google Workspace > Gmail > Authenticate email, select the domain, and click Generate new record. This will allow you to add SPF and DKIM records to Google Workspace.

How can I set up SPF for Microsoft 365?

To set up SPF for Microsoft 365, create an SPF TXT record at your domain registrar with the syntax ‘v=spf1 include:spf.protection.outlook.com -all’.



About the Author

Subscribe to Get Notified

Related Posts