Why are spoofed emails passing DMARC authentication with IPv6?
Matthew Whittaker
Co-founder & CTO, Suped
Published 26 Jul 2025
Updated 19 Aug 2025
9 min read
Email spoofing remains a persistent threat, even for domains that have implemented robust email authentication protocols. It can be particularly confusing when spoofed emails appear to pass DMARC authentication, especially when they originate from IPv6 addresses. I often see questions about how this is even possible, given DMARC's purpose to prevent unauthorized use of a domain.
The core issue isn't a fundamental flaw in DMARC itself, but rather nuanced configurations and interactions between SPF, DKIM, and DMARC, particularly in the context of IPv6. Understanding these intricacies is key to identifying and mitigating such advanced spoofing attempts. The header I analyzed, for instance, showed a spoofed email from Microsoft, which surprisingly passed DMARC.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is built upon two foundational email authentication protocols: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). SPF allows domain owners to publish a list of authorized IP addresses that are permitted to send email on behalf of their domain. When an email is received, the recipient server checks if the sending IP address is on this list.
DKIM provides a cryptographic signature that verifies the email has not been tampered with in transit and confirms the sender's identity. DMARC then ties these two together, allowing domain owners to specify how recipient mail servers should handle emails that fail SPF or DKIM checks, and to receive reports on authentication results. For DMARC to pass, either SPF or DKIM must pass and, crucially, align with the From domain in the email header.
The introduction of IPv6 has added a layer of complexity to this ecosystem. While IPv6 offers a vastly larger address space and is becoming more prevalent, many organizations may not have fully updated their SPF records to include all legitimate IPv6 sending sources. This can lead to a gap where legitimate emails might fail SPF if sent via IPv6 addresses not listed, or conversely, where spoofed emails might pass if the SPF record is too broadly defined and includes a range or mechanism that inadvertently covers the attacker's IPv6 address.
To delve deeper into these email authentication methods, consider reading a simple guide to DMARC, SPF, and DKIM that outlines their core functions and interdependencies.
The IPv6 factor in DMARC bypass
The primary reason spoofed emails, especially those using IPv6, can pass DMARC is often due to an overly permissive or incorrectly configured SPF record. While SPF is designed to authorize specific IP addresses, if it uses mechanisms like +all or ~all, or includes broad ranges (e.g., entire CIDR blocks of cloud providers), an attacker might exploit this. If a spoofed email's source IPv6 address falls within a permitted range, SPF will pass. Since DMARC only requires one of SPF or DKIM to pass (and align), this can lead to a spoofed email passing DMARC.
Another scenario involves legitimate third-party senders. If your SPF record includes an include mechanism for a service like Microsoft's protection services (spf.protection.outlook.com), and that service has a broad IPv6 range, an attacker could potentially send an email from an IPv6 address within that range. Because it's a valid IP according to spf.protection.outlook.com, SPF would pass, and if the domains align, DMARC would pass too. This often happens because large providers have extensive IP ranges, including IPv6, and their SPF records reflect this.
The RFC 7489, which defines DMARC, outlines its purpose to detect and prevent email spoofing. However, it relies on the underlying authentication mechanisms, SPF and DKIM, to be correctly implemented and strictly configured. If there are any loopholes in these configurations, particularly with IPv6 addresses that might be less scrutinized, spoofed messages can slip through. A good resource for understanding how Google authorizes mail servers by IPv6 address can be found in their Workspace Admin Help documentation.
Risky SPF configuration
An SPF record that is too broad, for example, by using v=spf1 include:thirdparty.com include:another.com ~all. If any included third-party SPF record is compromised or too broad itself, it creates a vulnerability. Attackers can leverage legitimate IP ranges within these included domains to send spoofed emails that pass SPF.
Common misconfigurations and vulnerabilities
Several common misconfigurations can lead to spoofed emails passing DMARC with IPv6. The most frequent culprit is a poorly constructed SPF record. For instance, some organizations might use a ~all mechanism in their SPF record, which means emails from unauthorized IPs will only be soft-failed rather than hard-failed. This allows receiving servers to accept the email, especially if DMARC is set to p=none or if DKIM passes. Additionally, failing to update SPF to include new IPv6 ranges for legitimate senders or forgetting to remove old ones can leave vulnerabilities. For more on this, check out how a phishing email can pass SPF and DKIM.
Another vulnerability arises from the handling of mail forwarding. When an email is forwarded, its original IP address is often replaced by the forwarding server's IP. This can cause SPF to break, as the forwarding server's IP isn't authorized to send for the original domain. While DKIM often survives forwarding, if the DMARC policy relies heavily on SPF for alignment, this scenario can cause legitimate emails to fail DMARC. Conversely, if a forwarding service has a misconfigured SPF record that broadly permits IPs, it could inadvertently allow spoofed messages to pass through their system and then on to recipients, seemingly authenticated.
It's also worth noting that DMARC reports (aggregate and forensic) are crucial for spotting these anomalies. If you're not actively monitoring these reports, you might not even realize that spoofed emails are passing DMARC authentication. These reports provide insights into authentication failures and passes, including the source IPs, allowing you to identify unauthorized sending activity, whether IPv4 or IPv6. Understanding and troubleshooting DMARC reports from Google and Yahoo is vital for this process.
Remediation strategies and best practices
To prevent spoofed emails from passing DMARC via IPv6, a comprehensive approach to email authentication is essential. First, meticulously audit your SPF record. Ensure that all legitimate sending IPs, both IPv4 and IPv6, are explicitly included using a, aaaa, or ip6 mechanisms with appropriate CIDR ranges. Equally important is to use a -all (hard fail) mechanism at the end of your SPF record once you are confident all valid sources are covered. This instructs receiving servers to reject emails from unauthorized IPs, rather than soft-failing them.
Gradually transition your DMARC policy from p=none to p=quarantine and then to p=reject. This phased approach allows you to gather DMARC reports and identify any legitimate mail flows that might be failing authentication before enforcing stricter policies. Monitoring these reports is critical. They will show you precisely which IPs, including IPv6, are sending mail for your domain and their authentication results. This visibility helps you uncover any unexpected passes or failures.
Additionally, ensure all your legitimate email sending services, including transactional email providers and marketing platforms, are configured correctly with both SPF and DKIM. Always prioritize DKIM as it is more resilient to forwarding than SPF and provides cryptographic assurance of message integrity. By combining strict SPF, comprehensive DKIM, and an enforced DMARC policy with vigilant monitoring, you significantly reduce the chances of spoofed emails passing authentication, whether they use IPv4 or IPv6. You can find more detail on how to safely transition your DMARC policy for maximum protection.
This example includes a specific IPv4 address, a specific IPv6 address, and an include mechanism for a third-party, ending with a -all policy for strict enforcement.
Views from the trenches
Best practices
Always use a strict SPF policy, such as '-all', to hard-fail unauthorized senders. Only use '~all' during initial monitoring.
Regularly audit your SPF record to ensure all IPv6 and IPv4 sending IPs are included and outdated ones are removed.
Ensure your DKIM configuration is robust, as it provides a more stable authentication method less affected by forwarding.
Transition your DMARC policy from 'p=none' to 'p=quarantine' and then to 'p=reject' only after extensive monitoring.
Utilize DMARC aggregate and forensic reports to identify all email sources, including unknown IPv6 senders.
Common pitfalls
Forgetting to include IPv6 addresses in SPF records, which can allow spoofed emails to pass if the SPF record is otherwise permissive.
Using overly broad SPF 'include' mechanisms that unintentionally authorize large IP ranges that attackers can exploit.
Not monitoring DMARC reports, leading to a lack of visibility into unauthorized sending activity passing DMARC.
Having a DMARC 'p=none' policy for too long, which provides no enforcement against spoofing, even if authentication fails.
Incorrectly configuring email forwarding, which can break SPF alignment and make it harder to differentiate legitimate from spoofed mail.
Expert tips
"Consider the SPF 'lookup limit' of 10 DNS lookups. Adding many 'include' mechanisms or 'ptr' records can exceed this, causing SPF failures. Keep your SPF concise."
"Implement DMARC at 'p=quarantine' first, even if it's only for a small percentage of mail, to gather data on IPv6 senders before moving to 'p=reject'."
"Pay close attention to the 'Disposition' field in your DMARC aggregate reports. 'none' for failures can indicate an issue even if DMARC 'passes' for spoofed mail due to other factors."
"If you use shared sending infrastructure, understand their SPF and DKIM practices. Their configuration directly impacts your domain's authentication."
"Don't rely solely on automated DMARC tools. Periodically manually review your DMARC XML reports to spot patterns that automated systems might miss."
Expert view
Expert from Email Geeks says they have seen authentication anomalies related to IPv6 when dealing with spam from major senders like Microsoft and Disney.
2022-06-06 - Email Geeks
Expert view
Expert from Email Geeks indicates that an email passing SPF and aligning with the From header would result in DMARC passing.
2022-06-06 - Email Geeks
Securing your email ecosystem
The phenomenon of spoofed emails passing DMARC authentication with IPv6 is a nuanced challenge, often stemming from SPF record misconfigurations, especially those that are overly permissive or not fully updated for IPv6 addresses. While DMARC is a powerful defense against email spoofing (or blocklisting), its effectiveness is directly tied to the precise implementation and alignment of SPF and DKIM. If you're finding that legitimate email is failing DMARC, or conversely, spoofed mail is passing, a deep dive into your DNS records and DMARC reports is essential.
Proactive monitoring through DMARC reports, diligent SPF record management, and a cautious approach to DMARC policy enforcement are paramount. By tightening SPF policies and ensuring all legitimate sending sources are properly accounted for, including those using IPv6, you can significantly bolster your domain's email security posture and protect your brand from malicious spoofing attempts. This ongoing vigilance is crucial for maintaining strong email deliverability and protecting recipients.
Microsoft's protection services (spf.protection.outlook.com), and that service has a broad IPv6 range, an attacker could potentially send an email from an IPv6 address within that range. Because it's a valid IP according to spf.protection.outlook.com, SPF would pass, and if the domains align, DMARC would pass too. This often happens because large providers have extensive IP ranges, including IPv6, and their SPF records reflect this.
