Why do emails land in spam even if SPF, DKIM, and DMARC pass?

While SPF, DKIM, and DMARC are crucial, they mainly verify the sender's identity. Inbox providers also evaluate sender reputation, the IP address's history, email content quality, and recipient engagement. If any of these factors are poor, emails can still go to spam, even with perfect authentication. For more information, see our article on why emails land in spam despite passing SPF, DKIM, DMARC .

What is IP reputation and how does it affect HR system emails?

IP reputation is the trustworthiness score of the server's IP address from which your emails are sent. If your HR system uses shared IPs, their reputation can be affected by other senders using the same IPs. A poor IP reputation, even if your domain's is good, can cause emails to go to spam. This is common with cloud providers using generic rDNS.

Why is generic rDNS a problem for email deliverability?

Generic rDNS (Reverse DNS) records, often found with cloud service providers like AWS, do not clearly identify the email sender. Mailbox providers see this as a red flag because spammers frequently use such configurations. Customizing the rDNS to reflect your domain or the HR system's legitimate sending practices helps establish trust and improve deliverability.

How can I troubleshoot this issue effectively?

Analyze the full email headers of both successful and spam-filtered emails to identify differences in sending path, IP addresses, and any custom headers added by the HR system. Check for any warnings in headers like X-Microsoft-Antispam or X-Forefront-Antispam-Report . Also, use Google Postmaster Tools to check your domain's reputation with Gmail .

Should I contact my HR system vendor about this problem?

Yes, it is crucial to communicate with your HR system vendor. Share the header analysis and discuss the importance of proper email infrastructure, including dedicated IP addresses if possible, and correct rDNS configuration. They are responsible for the technical setup of their outbound mail services and can implement the necessary changes to improve deliverability.

Why are emails sent via an HR system connected to Gmail landing in spam despite authentication passing? - Troubleshooting - Email deliverability - Knowledge base

It is a common scenario: you have an HR system, or any third-party application, connected to your Gmail account to send emails, and despite all authentication checks passing, these messages are still landing in the spam folder. This can be incredibly frustrating, especially when direct emails sent from Gmail arrive in the inbox without issue. It points to underlying factors beyond SPF, DKIM, and DMARC that influence email deliverability, especially with major inbox providers like Gmail and

Outlook. If you are encountering this problem, you are not alone, and there are specific areas to investigate to resolve it.

While passing email authentication protocols is foundational for good deliverability, it is merely the first step. Mailbox providers assess numerous signals to determine whether an email is legitimate or spam. These signals include the sender's reputation, the content of the email, and the infrastructure used to send it. When an HR system acts as an intermediary, it introduces additional layers where issues can arise, even if the core authentication records are correctly configured and verified.

Suped DMARC monitoring

Free forever, no credit card required

Learn more

Trusted by teams securing millions of inboxes

Understanding IP reputation and rDNS

One of the most common culprits, even when authentication passes, is the underlying IP reputation of the sending server. While your domain might have a stellar reputation, the IP address used by your HR system to relay emails through

Gmail's SMTP servers could be the issue. Many third-party applications and cloud providers use shared IP ranges, meaning that other senders using the same IP addresses could be engaged in spammy behavior. This tarnishes the IP's reputation, affecting all mail sent from it, including your legitimate HR emails.

In particular, generic Reverse DNS (rDNS) records, common for cloud infrastructure like Amazon Web Services (AWS) EC2 instances, are often viewed with suspicion by receiving mail servers. If the HR system's outbound mail server has a generic rDNS (e.g., ec2-XX-XXX-XX-XX.compute.amazonaws.com), it signals that the server might not be properly configured for sending email, making it more prone to being flagged. Mailbox providers interpret this as a higher risk for spam, even if your SPF, DKIM, and DMARC records align perfectly.

Example of generic rDNS in email headers

Received: from taskqueue2-email-send.prod (ec2-35-165-96-70.us-west-2.compute.amazonaws.com. [35.165.96.70])
by smtp.gmail.com with ESMTPSA id a12sm4642601pfk.188.2019.11.21.13.50.18

Additionally, an IP address appearing on an email blocklist (or blacklist) can contribute to deliverability issues. While a minor blacklist like SORBS might not be the sole cause of blocking, its presence is an indicator of past or ongoing problematic sending behavior from that IP, even if not directly attributable to your current mail streams. If your HR system is using an IP that has been previously used for spam, it inherits that negative reputation, affecting its ability to reach the inbox. You can find more information about email blocklists in our in-depth guide.

Content and sending behavior considerations

The content and characteristics of the emails themselves play a significant role. Even if authentication passes, certain elements within the email can trigger spam filters. For HR system emails, especially rejection letters or similar communications, the content might unintentionally contain terms or phrases that spam filters associate with bulk, unsolicited mail. This can be subtle, such as phrasing that sounds generic or overly formal, or the inclusion of certain types of links.

Consider the difference in content and headers when a recruiter sends an email directly versus when the HR system sends it. The HR system might be adding specific headers, tracking pixels, or re-encoding characters in a way that is not standard, leading to flags. For instance, some systems might use URL shorteners or track links in a way that resembles malicious behavior. These subtle differences in the email's technical composition can be enough for filters to mark it as suspicious. An example of this is when the HR system uses a generic email option like hire@yourdomain.com which works fine, but individual recruiter emails from the system go to spam. This points to a specific configuration or handling difference within the HR system for individual email addresses.

Recipient engagement is another critical factor. While not directly tied to the HR system's sending, if recipients consistently mark these automated HR emails as spam, or if they rarely open or click on them, it negatively impacts your domain's sending reputation, especially with

Gmail. Gmail uses user engagement as a strong signal for filtering. If your HR system sends a large volume of rejection emails that people do not wish to receive, this passive negative feedback can quickly degrade your sender reputation, leading to more emails being marked as spam. For more insights on this, you can review Google's article on legitimate emails going to spam.

Advanced troubleshooting and monitoring

Troubleshooting this issue requires a meticulous approach, starting with a deep dive into the email headers. Compare the headers of an email sent directly from

Gmail that lands in the inbox versus one sent via the HR system that goes to spam. Look for discrepancies in fields like Received, Return-Path, Message-ID, and any custom headers added by the HR system (e.g., X-Lever-Msgid). These subtle differences can sometimes reveal how the HR system is impacting the email's journey and its perception by spam filters.

Header Field	Significance
Authentication-Results	Confirms SPF, DKIM, and DMARC passes or failures.
Received	Traces the path of the email, revealing intermediate servers and IP addresses (check rDNS for these).
Return-Path	Indicates where bounces are sent. Should align with your domain.
X-MS-Exchange-Organization-AuthSource	Microsoft-specific header showing the authentication source.
X-Microsoft-Antispam-Mailbox-Delivery	Provides internal Microsoft filtering verdicts (e.g., "dest:J" for Junk). This is crucial for Outlook deliverability.

Beyond technical headers, engage with your HR system vendor. Share your findings regarding IP reputation, rDNS, and any observed content-related issues. They might be able to configure their outbound mail infrastructure to use dedicated IP addresses for your traffic, or at least ensure proper rDNS setup that reflects a legitimate sender. They may also be able to adjust how emails are constructed to avoid spam triggers. Given that

Google and other mailbox providers are tightening their spam filters, vendors need to keep up with deliverability best practices.

Finally, monitor your domain and IP reputation regularly. While Google Postmaster Tools provides insights for

Gmail recipients, keep an eye on blocklists (blacklists) and general sender scores. If your domain's reputation is low, emails might land in spam regardless of perfect authentication. This is an ongoing process that requires continuous attention, particularly when using third-party systems that control a portion of your email sending. Our guide to understanding email domain reputation can provide more details.

Views from the trenches

Best practices

Ensure your HR system's email sending module is configured to use proper, non-generic rDNS.

Work with your HR vendor to ensure they are not using shared IP addresses with poor reputations for your email sending.

Regularly monitor your domain and IP reputation using available postmaster tools.

Review email content from your HR system for anything that might trigger spam filters.

Common pitfalls

Assuming authentication (SPF, DKIM, DMARC) is the only factor for inbox placement.

Ignoring generic rDNS on shared IP addresses from cloud providers like AWS.

Not regularly checking for your sending IPs on public email blacklists (blocklists).

Failing to review content for spam trigger words or problematic formatting.

Expert tips

Check headers for all "Received" lines to identify the originating IP and its rDNS. This is often where hidden issues lie.

Even small, obscure blacklists can indicate underlying issues that contribute to a cumulative negative score.

Microsoft domains (like Outlook.com) are often stricter due to higher spam volumes, so they are good indicators.

Differentiate between generic email options (e.g., `hire@yourdomain.com`) and individual user emails if one works and the other does not; there's a configuration difference.

Marketer view

Marketer from Email Geeks says checking the email headers to ensure all authentication is passing is the first crucial step in troubleshooting.

November 21, 2019 - Email Geeks

Marketer view

Marketer from Email Geeks says if emails are routed via an HR system just using the email address and not G Suite, checking for shared IP issues is important to see if other senders are causing problems.

November 21, 2019 - Email Geeks

Key takeaways

Emails sent through an HR system connected to

Gmail landing in spam, despite passing authentication, is a nuanced challenge. It highlights that email deliverability extends far beyond basic SPF, DKIM, and DMARC checks. The root cause often lies in the sender's IP reputation, generic rDNS from cloud providers, subtle content issues, and the specific configurations or practices of the third-party sending system.

Addressing this requires a multi-faceted approach: careful analysis of email headers, direct communication with your HR system vendor to optimize their sending infrastructure (particularly rDNS and IP addresses), and a continuous focus on maintaining a strong sender reputation. By systematically investigating these areas, you can significantly improve the inbox placement of your critical HR communications.