Google and Yahoo DMARC Requirement: Answering Your Webinar Questions 

In our recent webinar, “Email Revolution: Meeting Google and Yahoo’s DMARC Requirement for 2024,” where we brought together email deliverability and authentication experts, we received tons of insightful questions from our engaged audience. 

These questions touched on various aspects of email deliverability, authentication, and compliance with DMARC policies. In this blog post, we aim to comprehensively address each of these questions, offering insights and guidance to help you with DMARC enforcement. Let’s delve into the answers to your questions.

Answering Your Webinar Questions

The importance of interpreting DMARC reports and recommended tools for analyzing DMARC XML files.

Analyzing a DMARC report is crucial for the success of your DMARC implementation and enforcement project.

DMARC XML files contain vital information, including the outgoing server IP address, SPF and DKIM authentication results, and the email’s disposition (whether it was delivered to the inbox, quarantined, or rejected based on your DMARC policy). However, if you send thousands or even hundreds of emails daily, and your organization uses multiple email sources (which is common), manually analyzing XML files becomes nearly impossible. Imagine your inbox overflowing with XML files, each requiring download and review, including performing reverse IP lookups to identify the vendor, among other tasks. This process could take days or weeks to interpret the data comprehensively. This is where DMARC reporting tools like EasyDMARC become indispensable. EasyDMARC automates the parsing of your XML files into readable data and organizes the reports into tabs, making it easier to identify and address issues with your email sources. Additionally, it offers extra features, such as checking whether your email service’s IP address is blocklisted and providing direct guidance on fixing source issues.

Concerns regarding the common practice of configuring CNAME records for DKIM keys pointing to a partner’s domain.

The first thing to understand about DKIM (DomainKeys Identified Mail) is that it requires both a private and a public key to function. The private key is typically held by the sending server, often not disclosed when using third-party Email Service Providers (ESPs) such as Mailchimp, ConvertKit, Google, Microsoft, etc. These vendors retain the private key on their end and provide you with the public key.

The key difference arises when some servers offer the public key as either a TXT or CNAME record. Vendors who provide CNAME records usually do so because they wish to manage key rotation on their behalf. By pointing the DKIM signature to the vendor’s domain via a CNAME record, they can handle all necessary key rotations. This would not be feasible with a TXT record.

However, merely pointing your DKIM to a partner’s domain without ensuring the private key is properly configured in the backend will result in failure. The effectiveness and security of DKIM hinge on both keys functioning together correctly.

Discussion on different DMARC policies (p=none, p=quarantine, p=reject) and their impact on email deliverability and spam detection.

Understanding the impact of DMARC policies on email deliverability and spam detection is crucial. By implementing a DMARC policy, you are instructing receiving servers on how to handle your emails based on whether they pass or fail SPF and DKIM authentication checks.

It’s a common misconception that DMARC policies directly influence email deliverability. The reality is, while implementing a DMARC policy does not directly affect deliverability, it can indirectly enhance it. However, it’s vital to recognize that email deliverability depends on numerous factors, and there is no single solution to ensure optimal performance.

Here are three ways in which DMARC can indirectly improve your email deliverability and effectiveness in combating spam:

• Starting with a DMARC Policy of ‘p=none’: This initial step doesn’t enforce any actions on emails failing authentication but enables you to receive reports. These reports are crucial for identifying and authenticating all outgoing email sources. Ensuring that all your email sources pass SPF and DKIM checks (and are aligned) can help improve the deliverability of your emails.

• Moving to ‘p=quarantine’ or ‘p=reject’: By escalating your DMARC policy to quarantine or reject, you significantly reduce the risk of someone impersonating or spoofing your domain. This not only protects your brand but also sends a positive signal to receiving servers, potentially boosting your email deliverability.

• With ‘p=reject,’ Preventing Spoofing: Enforcing a ‘p=reject’ policy means that emails attempting to spoof your domain are likely to be blocked at the SMTP level by most receivers that respect DMARC policies. This reduces the risk of your domain being used for spam, thereby protecting your email reputation.

However, it’s important not to overlook other factors that can affect deliverability. If you’re experiencing issues, they might be related to other aspects beyond DMARC policies.

The specific requirements or guidance from major email platforms like Google and Yahoo regarding DMARC policies.

Google and Yahoo currently recommend implementing DMARC with a policy of “p=none” as a basic requirement. This initial step encourages organizations to adopt DMARC, establishing a foundation for email authentication without immediately enforcing policies that could disrupt legitimate email traffic. This cautious approach acknowledges the complexity of properly configuring DMARC and the risk of inadvertently blocking valid emails.

To meet Google’s and Yahoo’s requirements, it’s sufficient to start with a DMARC record of “v=DMARC1; p=none” However, this is just the beginning. Achieving SPF and/or DKIM alignment is crucial and depends on the configuration set by your Email Service Provider (ESP).

Adding a Reporting URI for Aggregate Reports (RUA) to your DMARC record is highly recommended. This action lets you receive detailed reports, helping you spot and correct any sources failing SPF and DKIM checks. Using a service like EasyDMARC can simplify this by converting complex reports into a user-friendly format (Use our DMARC aggregate report parser tool after getting your XML reports in-app with EasyDMARC’s “rua” tag or otherwise.)

Your next objective should be to meticulously analyze these reports to identify “Non-Compliant” sources — those failing SPF and DKIM checks. Addressing these issues will elevate your compliance with Google and Yahoo’s standards. Additionally, ensuring that all your sending server IPs have valid PTR records is another critical step, which can be monitored through DMARC reports and tools like EasyDMARC.

In summary, beginning with a DMARC policy of “p=none” and an RUA address is a good initial step but not the final objective. Utilizing tools like EasyDMARC for report management, conducting thorough analyses, resolving issues with non-compliant sources, and adhering to best practices in email authentication will align you more closely with the expectations of major email platforms like Google and Yahoo.

The difference between SPF record configurations (-all vs. ~all) and the recommendation.

Before discussing the differences between “-all” and “~all” in SPF record configurations, it’s essential to understand that SPF (Sender Policy Framework) was one of the first email authentication protocols introduced in the early 2000s. Initially, email receivers would take direct actions based on the specific policy applied—either HardFail (“-all”) or SoftFail (“~all”). HardFail was meant to block the email outright if it failed SPF checks, while SoftFail suggested the email be quarantined or marked as spam.

It’s also crucial to note that SPF checks verify the Return-Path address, not the “From:” address. The Return-Path address is the server address used to handle bounces, whereas the “From:” address is part of the SMTP DATA visible to anyone who opens their email client.

Fast forward to today, the majority of Mailbox Providers (MBPs) do not enforce direct “rejection” rules for emails with a HardFail (“-all”) specified in the SPF record. Instead, they now rely on DMARC policies to dictate actions on emails that fail both SPF and DKIM checks. However, some ISPs, particularly smaller or local ones, may still adhere to the original intent of SPF policies. Additionally, specific rules can be applied in your SEGs (Secure Email Gateways) to dictate how emails failing SPF with a HardFail should be treated.

Taking all of this into account, there isn’t a one-size-fits-all recommendation between “~all” (SoftFail) and “-all” (HardFail). However, we strongly recommend using “~all” (SoftFail) to minimize the risk of false positives and emphasize enforcing a DMARC policy with “p=reject” as your primary strategy to block spoofing attempts.

The necessity of separate DKIM records for each subdomain and how it affects DMARC settings.

Having separate DKIM records for each subdomain doesn’t directly affect DMARC settings in either a positive or negative way. As long as you have a custom DKIM setup for your domain and use it across all your subdomains, and if you don’t have the “adkim=s” (strict alignment) rule applied in your DMARC record, then everything should work fine. However, having separate DKIM records for all subdomains could have positive effects from another perspective, such as building reputation for each of your subdomains separately rather than aligning every reputation with your root domain. For example, Google and Yahoo build your domain’s reputation with respect to the DKIM domain/subdomain you use in your emails, so having explicit DKIM for all your subdomains can help segment everything.

Best practices for dealing with DMARC subdomain policies

In the majority of cases, we recommend not having an explicit subdomain policy in your DMARC record, allowing your main policy to automatically apply to all your subdomains. According to DMARC specifications, if you don’t have a subdomain policy explicitly defined in your DMARC record, then your root domain policy will inherit across all your subdomains. This approach is generally recommended.

However, there are some specific scenarios where we advise our customers to use an explicit DMARC subdomain policy. Instead of using the “sp=” tag in their root domain’s DMARC record, they should implement a completely independent DMARC policy on their subdomain. This strategy is typically adopted if the customer deals with an Email Service Provider (ESP) that does not support DMARC alignment, and they wish to avoid hindering the progress of implementing a “p=reject” policy on their domain. In such cases, applying the ESP sending through the subdomain and having a specific DMARC policy (usually with “p=none” as the ESP doesn’t support DMARC alignment) allows for a tailored approach that accommodates the ESP’s limitations while still moving towards stronger email authentication practices. Another scenario involves organizations with subdomains that operate independently from the root domain, where the customer prefers to apply a policy directly to the subdomain itself.

Best practice for dealing with SPF lookups, specifically the issue of exceeding 10 DNS lookups.

The issue of exceeding the 10 DNS lookup limit in SPF records is a common challenge for many organizations today, often resulting from how Email Service Providers (ESPs) instruct their customers to update their SPF records. Some ESPs recommend setting up a specific subdomain to handle the SPF record, yet it’s common to see administrators also include these SPF includes in their root domain. This situation arises not from a lack of diligence on the part of the administrators but rather due to guidance from ESPs and misunderstandings about SPF functionality (notably, how SPF verifies the Return-Path address instead of the “From:” address, as covered in a previous discussion). To manage the SPF 10 DNS lookup limitation effectively, two main strategies are recommended: SPF hygiene and automated flattening solutions.

In conclusion, the use of EasySPF (EasyDMARC’s dynamic SPF flattening solution) is highly recommended for several reasons. Unlike manual SPF flattening, which is not advised due to its potential to severely complicate SPF management, EasySPF offers a reliable and automated solution. Manual SPF flattening—converting third-party hosts to IP addresses and thus bypassing automatic updates when a third-party’s infrastructure changes—is fraught with risks and should be avoided at all costs.

The EasySPF solution provides several key benefits:

• It automatically flattens your SPF record, ensuring that any changes made by third-party sources are reflected in your SPF without manual intervention.
• It integrates DMARC reports with the EasySPF dashboard, allowing for comprehensive analysis of email sending sources. This feature helps verify the active use of sources whitelisted in your SPF record, aiding in the SPF hygiene process by identifying and eliminating unused sources.
• It accesses a comprehensive backend of over 1000 verified email vendors, curated and refined by our email experts over years of meticulous analysis and adjustment. This database is leveraged to provide targeted recommendations on whether to keep or remove specific SPF includes based on how each ESP handles the Return-Path functionality and their alignment capabilities.

Strategies for improving email deliverability, particularly in cases where emails are being rejected or marked as spam.

When addressing email deliverability issues, numerous factors merit attention. If emails are outright rejected, you will typically receive a bounce error code that specifies the reason for rejection, offering significant clues for troubleshooting and resolution. Regarding emails marked as spam, it’s crucial to recognize that providers like Google and Yahoo place substantial emphasis on the “engagement” metric to evaluate your sending practices and determine email placement in either the inbox or spam folder.

Understanding these core principles, there are several predefined strategies to ensure your emails are favorably received by email algorithms:

• Authentication & Alignment: Ensure every server used for sending emails has your domain managing at least the DKIM “d=” section. Additionally, using a custom Return-Path provides a significant advantage.

• DMARC Policy Enforcement: Implementing a DMARC policy set to “p=reject” is crucial for eliminating spoofing attempts made against your organization, thereby conveying a positive signal to email service providers. It’s important to approach the adoption of a “p=reject” policy with caution, ensuring it’s carefully phased in rather than applied abruptly. Gradual implementation allows for the monitoring and adjustment of your email practices to minimize potential disruptions to legitimate email delivery.

• Avoid Using Third-party URLs: When employing third-party services (e.g., Sendgrid, Mailgun) for email sending, it’s crucial to set up a custom domain for link tracking. Third-party links, shared by numerous users, can be compromised. Ensuring your domain manages all aspects is vital.
  
• Sending Practices and Warm-up: Avoid sudden spikes in sending volume, as Mailbox Providers (MBPs) react negatively to these. If increasing volume, do so gradually to maintain a positive reputation.

• Unsubscribe Link: Facilitate easy unsubscribing for your recipients. Including an unsubscribe link can reduce the likelihood of being marked as spam. Absence of this option may lead to an increase in spam complaints, significantly impacting your email deliverability success rate.

How to address non-compliant hosts, including investigating and authenticating unknown applications found in DMARC reports.

Addressing DMARC non-compliant sources involves a multi-step process:

• Evaluate the sources and their usage within your organization. DMARC aggregate reports allow you to observe the IP address and authentication results. EasyDMARC goes a step further by resolving the IP address to identify the email source, segmenting it, and providing you with the necessary information to configure and authenticate the source.

• Once you have identified the source name, the next step is to communicate with the internal team to determine which department is utilizing the source.

• After gathering this information, the remediation process typically takes place directly within the email source’s portal.

• If the source is unknown and not recognized within the company, it is advisable to proceed with DMARC enforcement. Although not the ideal solution for every scenario, it is often the most effective. By enforcing your DMARC policy, unauthenticated emails will begin to be blocked by recipient servers, resulting in a specific bounce error code indicating a DMARC failure. This situation can then be easily identified by the individuals or departments using the source, facilitating a straightforward tracking and resolution process. However, this method can be critical and is not recommended for all cases. We typically suggest this option only if you are working with a DMARC expert.

The impact of email forwarding, Google Groups, and secure-messaging systems on DMARC compliance and email security.

Email forwarding presents a unique challenge in the context of DMARC enforcement. Specifically, we refer to auto-forwarders that typically preserve the original “From:” address. In the case of email forwarding, SPF validation will invariably fail. For instance, when an email sent to a recipient hosted on Google is auto-forwarded to another party, the “Return-Path” address changes to the forwarder’s domain, resulting in SPF failure due to misalignment. Similarly, emails forwarded from a Microsoft-hosted account retain the sender’s “Return-Path” address but fail SPF checks because the sender’s SPF record does not include the auto-forwarder’s IP address.

This underscores the critical role of DKIM, which, unlike SPF, does not fail in auto-forwarding scenarios, provided the integrity of the email’s body/header is not compromised by the forwarder. For senders, the focus should be on ensuring DKIM is correctly implemented on their sending sources. DKIM typically succeeds in passing validation during auto-forwarding, unless the forwarder modifies the email in a way that affects its integrity. In such cases, the final decision to accept the email rests with the receiving server, which may rely on the ARC protocol. This protocol is applied by the Mailbox Provider (MBP) and is beyond the control of both the sender and the receiver.

Regarding Google Groups and other mailing list servers, the dynamics differ. With a DMARC policy of “p=none,” you may observe numerous instances of non-compliance among mailing list servers used within your organization. Fortunately, no action is required on your part in such scenarios. As you enforce your DMARC policy to “p=quarantine” or “p=reject,” mailing list servers, such as Google Groups, modify their processing of your emails to ensure compliance. They specifically change the “From:” address domain to that of the mailing list, while your domain is preserved as the Display Name. This adjustment is made to prevent your emails from being blocked by recipient servers, maintaining compliance with your enforced DMARC policy.

The process of moving from a p=none policy to stricter enforcement (p=quarantine or p=reject)

The process of escalating DMARC policy enforcement to stricter levels can be methodically approached through stages.

• The first stage involves implementing a DMARC record with “p=none” and specifying a RUA address to receive reports about the outgoing email ecosystem. With a “p=none” policy, you’re not enforcing any policy on emails that fail DMARC checks, hence this is known as the ‘Monitoring stage.’ This stage is crucial for data gathering.

• The second stage requires analyzing the data received from various reporters. DMARC reports are generated every 24 hours by major ISPs. If you send emails to multiple users, their email servers will send you reports. Utilizing EasyDMARC can greatly facilitate the segmentation process, offering direct calls to action based on the analysis of received reports.

• The third stage focuses on both Non-Compliant and Compliant tabs. The Non-Compliant tab contains all the email sources that failed DMARC checks, meaning they failed both SPF and DKIM checks. The ‘Compliant’ tab, though indicating sources that passed DMARC, requires attention since DMARC compliance needs either SPF or DKIM to pass. There may be cases where neither is in place, so it’s advisable to authenticate both if possible from the source side.

• The fourth stage is about more data gathering and configuration. After evaluation in the third stage, the next step is to compile all data, bookmark it on your side, and start configuring each email source identified in the tabs. The fixing process may vary from one source to another. EasyDMARC provides guides for more than 1000 identified email sources, offering automated assistance on how to address them.

• In the fifth stage, after addressing all sources, it’s necessary to wait for additional data to ensure that all legitimate sources from your organization are compliant. It’s crucial to ensure a custom DKIM setup is in place for every source you use. While SPF may not always be available from some ESPs, DKIM should at least be implemented. If your ESP lacks DKIM, it may be time to consider alternative providers.

• The sixth stage involves confirming that all email sources in use are DMARC compliant, then gradually moving to higher enforcement levels. It’s recommended to start with “p=quarantine,” monitor reports for 2-4 weeks, and then progress to the highest level of enforcement, “p=reject.”

• The seventh stage entails ongoing evaluation after fully enforcing a “p=reject” policy. Continuous monitoring of reports is essential to ensure no new ESPs are being used without compliance.

How to handle vendors that only offer SPF/DKIM support at higher pricing tiers or the decision to switch vendors for compliance.

Email vendors should ideally not restrict SPF or DKIM setup to higher pricing tiers, as DMARC compliance critically depends on these protocols. While custom DKIM setup is widespread, it’s observed that SPF alignment often falls under premium offerings. This practice, however, shouldn’t hinder compliance, provided that custom DKIM setup is accessible. Some vendors may limit custom SPF or DKIM configurations to higher tiers but offer SMTP connection, allowing integration with other compliant ESPs.

If a vendor fails to provide at least custom DKIM setup, it’s advisable to consider alternatives that better support DMARC compliance. This approach ensures your email delivery strategy aligns with the new Google and Yahoo DMARC requirements.

The role of dedicated vs. shared servers in email authentication and deliverability.

We often receive questions about dedicated versus shared servers for email. It’s important to understand a few key points before making a choice.

Shared Servers (like those from Google, Microsoft, or email platforms such as MailChimp, ConvertKit, ActiveCampaign) mean you’re using their infrastructure to send emails on behalf of your domain.

Dedicated Servers imply hosting your own email server with your IP addresses, giving you complete control.

For authentication, there’s no fundamental difference between shared and dedicated servers. With shared servers, you must include their server details in your SPF record, like “_spf.google.com” for Google, which encompasses all IPs Google uses for emailing. For dedicated servers, you’ll list all your IPs in the SPF. DKIM setup on shared servers usually involves getting the Public Key from the provider’s portal, while dedicated servers require installing and managing both DKIM Private and Public keys yourself.

Regarding deliverability, shared servers benefit from the email service provider’s management of IP reputation and deliverability factors, including feedback loops and bounce handling. Dedicated servers require manual setup for these aspects, demanding significant technical expertise.

In summary, if you lack a dedicated team for managing the complexities of dedicated servers, opting for shared servers is advisable for ease of management and reliability.

---

We hope that our responses have provided actionable insights to empower you in your journey towards DMARC compliance and enhanced email deliverability. For those who may have missed the webinar, we have the recording available through the following link for you. Feel free to contact us if you have any further questions or require additional assistance.