Why is a new IP address showing up in my GPT dashboard with SPF failing but DKIM passing?
Michael Ko
Co-founder & CEO, Suped
Published 16 May 2025
Updated 16 Aug 2025
9 min read
Discovering a new IP address in your Google Postmaster Tools (GPT) dashboard with SPF failing but DKIM passing can be perplexing. It suggests that while the message's origin is not authorized according to your Sender Policy Framework (SPF) record, the message itself retains its cryptographic signature, indicating it hasn't been tampered with and originates from a legitimate source that possesses your domain's private DKIM key. This unusual combination often points to specific scenarios beyond simple misconfiguration.
I've encountered this situation before, and it typically requires a systematic investigation to pinpoint the root cause. The key is understanding how SPF and DKIM work independently and how DMARC (Domain-based Message Authentication, Reporting & Conformance) leverages both for email authentication and reporting.
To fully grasp the issue, let's briefly review the roles of SPF, DKIM, and DMARC. SPF verifies if an email originates from an IP address authorized by the sending domain's DNS records. DKIM adds a digital signature to email headers, allowing the recipient server to verify that the message hasn't been altered in transit and that it indeed came from the claimed sender. DMARC then uses the results of both SPF and DKIM checks, along with alignment requirements, to determine how to handle messages.
Understanding SPF
SPF (Sender Policy Framework) is a DNS TXT record that lists all IP addresses authorized to send email on behalf of your domain. When an email is received, the recipient server checks the SPF record against the sending IP address. If the IP isn't listed, the SPF check fails. This is crucial for preventing email spoofing, as it ensures that only authorized servers send mail from your domain. For more information, see how SPF authentication works.
Understanding DKIM
DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify that an email message has not been altered in transit and that it was sent by an authorized sender. The sender signs the email with a private key, and the recipient verifies it using a public key published in your domain's DNS. If DKIM passes, it indicates that the sender had access to your domain's private key, confirming legitimacy regardless of the originating IP.
The scenario where SPF fails but DKIM passes suggests that an unauthorized IP sent the email, but it was signed correctly. This is puzzling because typically, if SPF fails, it means the sender IP is not on your allowed list. However, if DKIM passes, it means the email was signed using a legitimate private key associated with your domain, implying the sender is authorized in some capacity, even if their IP isn't. This brings us to potential explanations that go beyond a simple missing SPF entry.
Potential causes: forwarding and beyond
One of the most common reasons for this peculiar pattern is email forwarding. When an email is forwarded, it often goes through an intermediary server that changes the original sending IP address. The SPF check for the original domain will then fail because the forwarding server's IP is not included in the original domain's SPF record. However, the DKIM signature, which is part of the email header and body, remains intact unless modified by the forwarding server itself.
Before forwarding
SPF: Passes. The email is sent directly from an IP authorized in your SPF record.
DKIM: Passes. The email is signed with your domain's private key, and the signature is valid.
DMARC: Passes. Both SPF and DKIM checks align with the From: domain.
After forwarding
SPF: Fails. The forwarding server's IP is typically not included in the original sender's SPF record.
DKIM: Passes. The DKIM signature, if not modified by the forwarding server, remains valid.
DMARC: Passes (often due to DKIM alignment). DMARC usually only requires one of SPF or DKIM to pass and align.
While forwarding often explains SPF failure with DKIM passing, the volume showing up in Google Postmaster Tools (GPT) is unusual for casual forwarding. It suggests a significant amount of mail is being forwarded through a specific intermediary, such as an email security gateway or a bulk forwarding service that your recipients might be using. This means that a large group of your recipients might be on a system that forwards email, or you're seeing reports from a specific organization with a massive auto-forwarding or routing setup. The fact that the IP belongs to a major ISP like Comcast reinforces this, as residential or business networks sometimes have their own mail relays.
Another possibility, though less common given a passing DKIM, could be a compromised ESP or sending system. If a malicious actor gained access to your ESP's private DKIM key, they could send emails signed with your domain from unauthorized IP addresses. However, this is less likely to result in consistent, high-volume DKIM passing, as such an exploit would typically lead to blacklisting (or blocklisting) and immediate action from the ESP.
Investigating the unexpected IP
The first step in diagnosing this issue is to delve into your DMARC aggregate reports. These reports provide XML data detailing which IPs are sending mail on your behalf, their SPF and DKIM authentication results, and the corresponding DMARC outcome. Pay close attention to the source IP, the volume of emails from that IP, and the reporting organization. If it's exclusively Google (Gmail) reporting this, it could indicate a specific issue with how Google processes certain forwarded mail, or a large segment of your Google recipients are forwarding emails. If multiple reporters (like Verizon, Yahoo, etc.) show this IP, it points to a broader forwarding or routing scenario.
Next, identify the DKIM selector associated with the emails from this IP. The DMARC report will specify the selector used for the passing DKIM signature. Knowing this selector can confirm which of your sending services (or their sub-domains) is generating the email, even if the IP is unexpected. If the DKIM selector belongs to your primary Email Service Provider (ESP), but the IP is not theirs, it strongly suggests forwarding. It's vital to have a clear understanding of your legitimate sending infrastructure and the IPs used by your ESP. Occasionally, ESPs may spin up new infrastructure or use third-party relays, but they should always update their SPF records or communicate these changes.
Investigative steps
DMARC reports: Examine the XML reports to confirm the IP, volume, and reporting mailbox provider. Is it a consistent volume or sporadic bursts?
DKIM selector: Note the specific DKIM selector in the report. This points to the entity that signed the email. If it's your ESP's selector, the signature is valid.
Reverse IP lookup: Confirm the IP's ownership. If it's an ISP like Comcast, it often suggests a consumer or business network forwarding.
ESP communication: Even if they deny ownership of the IP, ask if they have any known issues with forwarding or new IPs that might not be fully integrated into SPF. Reconfirm your expected sending IPs with them.
It's also worth checking if the SPF failure is a softfail (indicated by ~all in your SPF record) or a hardfail (indicated by -all). A softfail is less impactful than a hardfail, but both signal a mismatch. Since DKIM is passing, your DMARC policy likely allows for this, as it only requires one of the two (SPF or DKIM) to pass and align. The fact that DMARC is passing means these emails are generally reaching the inbox, but the SPF failure still provides valuable information about the email's journey.
SPF alignment and DMARC considerations
The issue of SPF alignment is central here. For DMARC, SPF alignment means the Return-Path domain (also known as the MailFrom or Envelope-From domain) must match the From: header domain. If your DMARC record has a aspf=s tag, it enforces strict alignment, meaning the Return-Path domain must exactly match the From: domain. This can cause SPF failures for subdomains, even if they're legitimate, as the Return-Path often uses a subdomain for bounces. However, in cases of forwarding, the Return-Path can be rewritten, leading to an SPF failure irrespective of your DMARC alignment setting.
While SPF alignment failures are common with forwarding, it's important to differentiate between a DMARC alignment failure and a simple SPF authentication failure. In your scenario, the DKIM pass is salvaging DMARC, but the SPF failure in GPT still indicates a potential blind spot or an unexpected mail flow. You might want to review SPF alignment failures for more context.
Given the volume, it's less likely to be an isolated user forwarding emails. It could be a corporate network, a mailing list, or a security appliance that forwards mail. If you have access to any forwarded email headers, that would provide invaluable insight into the actual path the email took and why the SPF failed. Without those headers, you're relying on the aggregate data from GPT and DMARC reports.
Addressing the SPF failures
I often advise clients to ensure their SPF records are comprehensive, listing all legitimate sending IPs and services. If you have multiple sending systems or marketing platforms, each needs to be included. However, given that a new IP appeared and SPF is failing while DKIM is passing, directly adding this Comcast IP to your SPF is probably not the answer unless you can confirm it's a legitimate, recurring sending source that your ESP somehow missed. More likely, it's an intermediary.
If, after careful investigation of your DMARC reports, you are still stumped, consider that Google Postmaster Tools, while incredibly useful, does not guarantee 100% accurate data, especially concerning forwarding. They state they make their best effort to represent data accurately, but complex mail flows can sometimes muddy the waters. However, don't dismiss the data entirely, as it often reveals genuine, albeit obscure, issues.
Wrapping up
The appearance of an unexpected IP in your GPT dashboard with SPF failing but DKIM passing is a strong indicator of email forwarding. While it's generally not something to panic about if DMARC passes, it's worth investigating to understand your email's journey and ensure there are no deeper security concerns. Analyzing your DMARC reports thoroughly, understanding the DKIM selector, and ensuring your legitimate sending IPs are correctly configured in SPF are crucial steps. This proactive approach ensures your email infrastructure remains robust and your deliverability high.
Views from the trenches
Best practices
Actively monitor DMARC aggregate reports for unexpected IPs and authentication patterns, especially those with high volume.
Regularly review your SPF record to ensure it includes all legitimate sending services and their respective IP addresses.
Work closely with your ESP to understand their sending infrastructure and confirm any changes to their IP ranges.
Prioritize DKIM authentication, as its passing status often salvages DMARC even when SPF fails due to forwarding.
Common pitfalls
Ignoring unexpected IPs in Google Postmaster Tools, assuming they are harmless anomalies.
Failing to analyze raw DMARC reports for detailed insights into mail flow and authentication results.
Assuming that a passing DKIM means no further investigation is needed when SPF is consistently failing.
Not considering email forwarding as a primary cause for SPF failures with passing DKIM signatures.
Expert tips
Use a DMARC monitoring tool to easily parse and analyze your DMARC XML reports, making it simpler to identify these types of anomalies.
If you suspect a compromised key, immediately rotate your DKIM keys with your ESP to invalidate any old signatures.
For large organizations, investigate internal mail routing or security gateways that might be altering email paths.
Always maintain a DMARC policy that is at least at 'p=none' to receive reports, allowing you to observe these issues without affecting deliverability.
Marketer view
Marketer from Email Geeks says they talked to their ESP, but they claimed the IP was not theirs. They were looking for speculation to understand what to look for.
2021-07-15 - Email Geeks
Expert view
Expert from Email Geeks says a possible cause could be a compromised ESP, and suggested regenerating the DKIM key at the ESP to see if that resolves the issue.
2021-07-15 - Email Geeks
Related pages
For further insights, you can explore the following resources:
Comcast reinforces this, as residential or business networks sometimes have their own mail relays.
Google (Gmail) reporting this, it could indicate a specific issue with how Google processes certain forwarded mail, or a large segment of your Google recipients are forwarding emails. If multiple reporters (like Verizon, 
Yahoo, etc.) show this IP, it points to a broader forwarding or routing scenario.
