Why are legitimate GSuite emails going to spam after a domain impersonation attempt and DMARC policy change?
Matthew Whittaker
Co-founder & CTO, Suped
Published 16 Jun 2025
Updated 17 Aug 2025
8 min read
Recently, my client's domain experienced a significant domain impersonation attempt. Tens of thousands of fraudulent emails were sent, seemingly from their domain. At that time, we had a DMARC policy set to p=none, which meant that mailbox providers were instructed to do nothing with emails that failed DMARC authentication.
In response to the impersonation attempt, I immediately updated the DMARC policy to p=quarantine. This was a necessary step to better protect the domain from future abuse and ensure that fraudulent emails would be moved to spam or junk folders.
However, an unforeseen issue arose: legitimate emails sent from GSuite and integrated third-party customer service tools like Gorgias began landing in spam folders. Surprisingly, marketing emails sent via Klaviyo continued to reach inboxes without issue. This discrepancy puzzled me, as the legitimate GSuite emails were critical for customer support and business operations. My immediate concern was why these essential communications were suddenly being misclassified.
The primary reason legitimate emails go to spam after a DMARC policy change is often due to unauthenticated sending sources. When a domain’s DMARC policy is set to p=quarantine or p=reject, any email that fails DMARC authentication (meaning it doesn't pass SPF or DKIM checks, or fails DMARC alignment) will be treated according to that policy. If GSuite was not fully authenticated, those legitimate emails would then be caught by the new policy and sent to spam. This is precisely what the policy is designed to do for unauthorized mail, but it inadvertently affects legitimate traffic if not all sending sources are properly configured. You can find more details on why legitimate email fails DMARC verification even when doing everything right and why changing DMARC to quarantine causes issues.
The difference in deliverability between Klaviyo and GSuite highlights this point. Klaviyo emails were likely already correctly configured with SPF and DKIM, and crucially, they achieved DMARC alignment. This meant they were able to continue passing authentication checks even under the stricter DMARC policy. GSuite emails, however, seem to have lacked proper authentication or alignment, leading to their classification as suspicious mail by mailbox providers. For further information, see our guide on why emails go to spam due to DMARC failures.
It is common for organizations to have multiple legitimate sending sources. When moving from a relaxed DMARC policy like p=none to an enforced one (quarantine or reject), any overlooked sending source will experience deliverability issues. The impersonation attempt served as a catalyst, pushing the domain to implement a stronger DMARC policy that then exposed the underlying configuration gaps for Google Workspace. It is crucial to follow a systematic approach to avoid such issues. We have a guide on how to safely transition your DMARC policy.
The critical role of email authentication
Email authentication protocols like SPF, DKIM, and DMARC are the backbone of modern email security. They are essential for preventing spam, phishing, and domain impersonation. Recent requirements from major mailbox providers like Gmail and Yahoo emphasize the critical need for all senders, especially bulk senders, to implement these protocols. I found Google's guide on troubleshooting DMARC issues to be very helpful in understanding the technicalities involved. You can also review a simple guide to DMARC, SPF, and DKIM for a foundational understanding.
The primary oversight in my client's situation was missing the proper DKIM setup for GSuite emails. While other sending platforms were correctly authenticated, GSuite, which handles essential one-to-one communications and customer support, was not fully covered. This highlights a common pitfall: even if you have SPF and DKIM records in place, they must be correctly configured for all your sending sources.
DMARC works by instructing receiving mail servers on how to handle emails that fail authentication. For an email to pass DMARC, either its SPF or DKIM must pass, and the domain used in the From header must align with the SPF or DKIM authenticated domain. With a p=quarantine policy, if GSuite emails weren't properly authenticated or aligned, they would be flagged for quarantine, sending them straight to spam. Here's a typical DMARC record that instructs mail servers to quarantine messages that fail authentication:
Even when I saw headers indicating passing authentication, legitimate emails were still landing in spam. This can happen if there are still underlying DMARC alignment issues, or if the domain's reputation has been severely impacted. Sometimes, even if SPF or DKIM passes individually, DMARC alignment might fail if the From domain doesn't match the authenticated domain. For more insights on this, you can read about what DMARC policies senders should use.
Addressing reputation and propagation delays
A domain's reputation is built over time based on its sending habits and authentication status. The significant impersonation attempt, even under a p=none DMARC policy, likely had a negative impact on my client's domain reputation with major mailbox providers. This blacklisting (or blocklisting) of the domain, even if temporary, would cause legitimate emails to be scrutinized more heavily. When the DMARC policy was tightened to quarantine, it amplified the effect of this already diminished reputation. Monitoring tools like Google Postmaster Tools are essential for observing these reputation changes.
Even after implementing the correct SPF and DKIM for GSuite, it's important to understand that changes to DNS records and domain reputation do not take effect instantaneously across the entire internet. DNS propagation can take hours, and for mailbox providers to fully recognize the improved authentication and rebuild trust in the domain, it can take days or even weeks. This is often referred to as a wait and see approach.
The importance of patience
After making critical DNS changes, such as updating SPF records or enabling DKIM for new sending sources, it takes time for these changes to propagate across DNS servers worldwide. More importantly, mailbox providers need time to process these new authentication signals and update their internal reputation scores for your domain. Immediate improvements are rare, and consistent, authenticated sending over time is necessary to rebuild trust and improve deliverability.
The distinction between Klaviyo emails and GSuite emails is also crucial. Bulk email services like Klaviyo often use their own sending infrastructure, which has an established reputation separate from your primary domain's one-to-one email reputation. While DMARC connects them to your domain, their underlying IP and domain reputation for bulk sending might be more robust. Corporate (one-to-one) emails, especially those sent directly from Google Workspace accounts, are typically tied more directly to the core domain's reputation. When that reputation takes a hit, or if authentication is not perfect, these essential communications are often the first to suffer. Below is a comparison of common factors affecting deliverability for bulk vs. corporate emails:
Bulk email (Klaviyo)
Reputation: Leverages the sending provider's (e.g., Klaviyo's) established IP and domain reputation.
Volume: High volume, often with dedicated IP addresses, allowing for consistent reputation building.
Authentication: Providers guide users through SPF/DKIM setup for optimal DMARC alignment.
Corporate email (GSuite)
Reputation: Directly tied to the core domain's reputation, making it more sensitive to domain-wide issues.
Volume: Often lower volume one-to-one communication, but still subject to strict filtering.
Authentication: Requires manual configuration of SPF and DKIM within Google's administrative console.
Views from the trenches
Best practices
Implement a DMARC policy with a phased approach, starting with p=none.
Always ensure all legitimate sending sources are authenticated with SPF and DKIM.
Monitor DMARC reports regularly to identify authentication failures.
Common pitfalls
Changing DMARC policy directly from p=none to p=quarantine/reject.
Forgetting to authenticate all third-party sending services (like GSuite for corporate email).
Expecting instant deliverability recovery after fixing authentication issues.
Expert tips
Use DMARC reports to identify specific authentication failures.
Patience is crucial for deliverability improvement after major changes.
Separate marketing email reputation from corporate email reputation if possible.
Expert view
Expert from Email Geeks says if legitimate emails are going to spam, it's likely due to them not passing DMARC validation checks, and receiving domains are honoring the quarantine policy. This indicates an underlying authentication configuration issue.
2024-01-19 - Email Geeks
Expert view
Expert from Email Geeks says that when significant changes are made to domain authentication records, the systems require time to process and for the filters to catch up. Patience is key.
2024-01-19 - Email Geeks
Restoring your GSuite email deliverability
Experiencing legitimate GSuite emails landing in spam after a domain impersonation attempt and a DMARC policy change is a frustrating, but solvable, challenge. It typically points to a combination of factors: an initial authentication gap for a specific sending source (like GSuite), the immediate enforcement of a stricter DMARC policy, and the time required for domain reputation to recover. We cover similar issues in our article on why emails land in spam despite passing authentication.
The path to resolution involves a methodical approach: ensuring all legitimate sending sources are fully authenticated with SPF and DKIM, verifying DMARC alignment, and patiently allowing DNS changes to propagate. Continuously monitoring DMARC reports, particularly forensic reports (RUF), and keeping an eye on your domain's reputation through tools like Google Postmaster Tools, are crucial for long-term email health. Understanding and troubleshooting DMARC reports from Google and Yahoo is a must.
While immediate fixes might not be apparent, consistent adherence to authentication best practices and diligent monitoring will eventually restore your domain's sending reputation and ensure your legitimate GSuite emails reach the inbox as intended. For broader insights, consider our guide on why your emails are going to spam.
GSuite and integrated third-party customer service tools like Gorgias began landing in spam folders. Surprisingly, marketing emails sent via Klaviyo continued to reach inboxes without issue. This discrepancy puzzled me, as the legitimate GSuite emails were critical for customer support and business operations. My immediate concern was why these essential communications were suddenly being misclassified.
Gmail and 
Yahoo emphasize the critical need for all senders, especially bulk senders, to implement these protocols. I found Google's guide on troubleshooting DMARC issues to be very helpful in understanding the technicalities involved. You can also review a simple guide to DMARC, SPF, and DKIM for a foundational understanding.
GSuite emails. While other sending platforms were correctly authenticated, GSuite, which handles essential one-to-one communications and customer support, was not fully covered. This highlights a common pitfall: even if you have SPF and DKIM records in place, they must be correctly configured for all your sending sources.
Google Workspace accounts, are typically tied more directly to the core domain's reputation. When that reputation takes a hit, or if authentication is not perfect, these essential communications are often the first to suffer. Below is a comparison of common factors affecting deliverability for bulk vs. corporate emails:
