Why are spoofed emails passing DMARC authentication with IPv6?
Published 26 Jul 2025
Updated 21 Oct 2026
11 min read
Summarize with
Updated on 21 Oct 2026: We clarified IPv6 SPF authorization, trusted header checks, and why DMARC enforcement cannot stop abuse through authorized senders.
Spoofed emails pass DMARC with IPv6 for the same reason they pass with IPv4: DMARC sees a valid SPF or DKIM result for a domain that matches the visible From domain. IPv6 does not change the DMARC rules. It changes the address family used by the sending host, and that can make the result look surprising when a large provider authorizes broad IPv6 ranges.
dmarc=pass does not mean the message content is safe or approved by the brand owner. It means the receiving mailbox provider found a passing SPF or DKIM path whose authenticated domain matched the domain in the message's From header. A passing result establishes domain authentication.
- The IPv6 host was authorized by SPF, or the message had a passing DKIM signature, and that authenticated domain matched the visible From domain.
- A random local-part before the at sign does not fail DMARC when the domain after the at sign is authenticated.
- Inspect the full headers, validate the sending IP against SPF, then identify the sending route and its owner.
How DMARC passes over IPv6
DMARC passes when SPF passes and the SPF-authenticated domain matches the visible From domain, or DKIM passes and the DKIM signing domain matches the visible From domain. Under relaxed matching, the domains can share the same organizational domain. Under strict matching, they must be identical. IPv6 is only the source address format used during the SPF check.
In a header like this, the receiving system is telling you that the IPv6 sender is permitted by SPF for the envelope sender domain, and that domain matches the domain in the visible From header. That gives DMARC enough to pass. For a bounce with an empty MAIL FROM, SPF uses the HELO domain instead. A standalone HELO pass does not satisfy DMARC when MAIL FROM is nonempty. The IPv6 address below is reserved for documentation.
Simplified Authentication-Results exampletext
From: notice@accountprotection.example Return-Path: <notice@accountprotection.example> Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=notice@accountprotection.example; dmarc=pass header.from=accountprotection.example Received-SPF: pass client-ip=2001:db8::25; envelope-from="notice@accountprotection.example"; receiver=mx.example.net
DMARC pass is not brand approval
A message can pass DMARC and still carry phishing links or malicious attachments sent through a compromised authorized account. DMARC checks domain authentication. It does not inspect the message body or attachments.
- The SPF path checks whether the connecting IPv6 address is authorized for the envelope sender domain.
- The DKIM path checks for a valid signature using a domain that matches the visible From domain.
- DMARC does not decide whether the message text matches the normal style of the brand.
This is why a message can look spoofed to a human but still pass the technical check. The sender name, local-part, subject line, or body can look wrong. If the authenticated domain matches under the published DMARC mode, DMARC passes.
How IPv6 affects SPF
SPF evaluates the connecting IPv6 address against the same TXT record used for IPv4. A domain does not need a separate SPF record for IPv6.
DMARC passes when SPF over IPv6 or DKIM authenticates a domain matching the visible From domain.
SPF can authorize IPv6 directly with an ip6 mechanism and an optional CIDR prefix. The a and mx mechanisms can also match IPv6 through AAAA records, while include and redirect paths can lead to provider records that authorize IPv6. Large mail platforms commonly publish these routes. If a bad message uses an authorized route and the SPF domain matches the visible From domain, DMARC can pass.
|
|
|
|---|---|---|
SPF match | IPv6 is authorized | Envelope domain |
DKIM pass | Signature domain matches | DKIM d value |
Forwarding | A matching DKIM signature survives | Received chain |
Provider abuse | Real system sent it | Account source |
Delegated subdomain | Relaxed domain match succeeds | Authenticated domain |
Common reasons a suspicious message passes DMARC over IPv6.
An ip6 mechanism does not consume one of SPF's 10 DNS-query terms, but a, mx, include, exists, ptr, and redirect do. Exceeding that limit returns SPF permerror rather than pass. Also check for multiple SPF records, since more than one applicable SPF TXT record produces permerror. A matching DKIM pass can still make DMARC pass when SPF returns permerror.
The local-part is not evidence of a DMARC failure. A sender like randomstring@example.com can pass DMARC if example.com authenticated the message. DMARC has no rule that says the local-part must be an expected mailbox.
Check for overly broad IPv6 authorization
Inspect the prefix as well as the address. Under RFC 7208, an ip6 mechanism without a prefix defaults to /128, which authorizes one address. A /64 authorizes the entire subnet. Use the provider's documented sending ranges.
Illustrative SPF record for one IPv6 hosttext
Host: example.com Type: TXT Value: v=spf1 ip6:2001:db8::25/128 -all
This documentation-only example authorizes one IPv6 host. Replace it with your real sending sources before publishing.
- Check nested include and redirect targets for broader ranges than intended.
- Replace +all or unqualified all with a policy that authorizes only intended senders. Either form passes any address that reaches it.
- Confirm that a shared provider restricts who can use your envelope sender domain. An IP match does not identify an individual customer account.
- Compare IPv6 addresses numerically; compressed and expanded forms can describe the same address.
How current DMARC rules affect domain matching
RFC 9989 is the current DMARC specification and obsoletes RFC 7489. The central result has not changed: DMARC passes when a passing SPF or DKIM identity matches the visible From domain. IPv4 and IPv6 still follow the same rule.
- RFC 9989 defines a bounded DNS tree walk for policy discovery and organizational-domain discovery. Receiver implementation determines whether the new method is used.
- The pct tag is historic, so do not depend on pct=25 or another partial value to stage enforcement.
- For receivers implementing RFC 9989, t=y reduces p=reject to quarantine and p=quarantine to none. It is not percentage sampling, and support must be checked before relying on it.
- Aggregate and failure report formats are defined separately in RFC 9990 and RFC 9991.
Receivers using the older public suffix method and those using DNS tree walk can discover different organizational domains. An explicit DMARC record selects the policy for that From domain; it does not, by itself, resolve organizational-domain discovery for relaxed matching. Strict matching avoids that comparison, but enable it only after checking legitimate senders.
How to read IPv6 authentication headers
Use Authentication-Results written by the receiving system or an explicitly trusted gateway, following RFC 8601. Check its authentication service identifier against the receiving provider's documented identifiers; the topmost header is not automatically trustworthy. Look for the SPF result, envelope sender domain, DKIM signing domain, DMARC result, and visible From domain.
What DMARC checked
- SPF checks whether the connecting IP address was authorized for the MAIL FROM identity, using the HELO domain only when MAIL FROM is empty.
- DKIM checks whether a cryptographic signature validates the signed message parts.
- DMARC checks whether a passing SPF or DKIM domain matches the visible From domain under the published mode.
What DMARC did not check
- DMARC does not verify whether the display name belongs to the person or brand shown.
- DMARC does not check the message body, attachments, or Reply-To address for safety.
- DMARC does not verify whether the local-part before the at sign belongs to a real mailbox.
If the header says spf=pass and dmarc=pass, inspect smtp.mailfrom for the envelope sender domain. Return-Path normally records this address in a delivered message. If the domain matches header.from under relaxed or strict mode, the result is expected. Otherwise, inspect each passing DKIM signature: its d= value, often reported as header.d, can explain the DMARC pass.
How much trust each signal deserves
DMARC is strong for domain authentication, but it is only one input to message handling.
Strong
DMARC pass
SPF or DKIM matches the visible From domain.
Warning
Review source
The sender is authenticated but the content is abnormal.
Critical
Apply local policy
The message fails DMARC while claiming a protected domain.
For a quick record check, Suped's DMARC checker can confirm whether the published policy is valid before you investigate message-level results.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Why authenticated email can still be abusive
A message can be abusive even though its authentication result is technically correct. The clearest example is an attacker using a provider path that the domain owner authorized. This can happen through a compromised account, weak controls on a shared sending platform, misused automation, or a vendor sending mail that the domain owner did not intend.
A passing result can still be an incident
If the sending route is authorized but the message is unwanted, the fix is not only DNS. The domain owner needs sender governance: which systems can send, which users can trigger mail, which vendor accounts can use the domain, and how access is revoked.
Delegated subdomains need separate attention. Under relaxed matching, an authenticated subdomain can match a parent From domain when both have the same organizational domain. A compromised or poorly controlled delegated subdomain can therefore create a real DMARC pass. The p and sp policy tags tell receivers how the domain owner wants failed messages handled. Neither p=reject nor sp=reject blocks a message that already passes DMARC. Use explicit records for active From domains, and consider strict matching only when legitimate sending paths support it. Suped's domain health checker can review DMARC, SPF, and DKIM together.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Forwarding often breaks SPF because the connecting IP changes. DKIM can survive when the forwarder does not alter signed content, which can preserve a DMARC pass. ARC is different: it records authentication observed earlier in the chain and can support a receiver's local decision after forwarding, but it does not change a DMARC fail result into pass.
How to investigate a suspicious IPv6 sender
Do not start by blocking the visible domain. Blocking a major account or notification domain can break real mail. Start by proving which identity authenticated the message and whether that identity was expected to send that class of mail.
- Capture the raw message source because forwarding a message inline can change the evidence.
- Use the receiver's trusted Authentication-Results and Received entries to identify the connecting IPv6 address.
- Compare that IPv6 address with SPF for smtp.mailfrom, following include and redirect paths. Check HELO only for an empty MAIL FROM.
- Inspect each DKIM signing domain (d=) and selector (s=), then confirm which signatures the receiver validated.
- Apply the published relaxed or strict mode to the authenticated domain and header.from.
- Classify the source as an approved provider, a forwarding path, a delegated subdomain, or an unrelated lookalike domain.
If the message passed through a real provider system, contact the provider's abuse channel with full headers. If the domain is yours, check account permissions and sending logs to identify who triggered the message. If the message uses a lookalike domain, DMARC for your domain cannot stop it. That needs mailbox filtering, brand monitoring, user reporting, and takedown handling.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
In Suped's product, filter DMARC aggregate data by source IP, authentication result, and domain. Compare the IPv6 source with the sender inventory and review its message counts and failures, then ask the domain owner to confirm the sending route.
How to fix authorized sending gaps
If the message is passing because your own domain authorized the route, tighten sender control. SPF and DKIM have to match the senders you still use, and old senders have to be removed. Make sure only approved systems can authenticate as your domain.
DMARC enforcement with optional strict matchingtext
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s
Enable p=reject after reports show that legitimate sources authenticate. Treat adkim=s and aspf=s as separate decisions: they require exact domain matches and can break legitimate subdomain use. Neither setting stops abuse that already authenticates using the exact From domain. DMARC still passes if either qualifying method succeeds; strict settings do not require both SPF and DKIM to pass.
- Remove unused SPF senders, authorize IPv6 ranges only when needed, keep one SPF record, and stay within lookup limits.
- Sign third-party mail with your own DKIM domain so a surviving signature can satisfy DMARC after forwarding.
- Publish deliberate subdomain policies and control every delegated subdomain that can authenticate.
- Move from monitoring to quarantine or reject after real sources are accounted for, without relying on the historic pct tag.
- Revoke compromised account access and unused API credentials, and require multifactor authentication for administrative access.
- Watch blocklist (blacklist) signals when abuse starts to affect sending IPs or domains.
If DNS changes are slow or spread across teams, Suped's Hosted DMARC supports policy staging without repeated TXT record edits. Suped's reporting can be used to confirm that known IPv4 and IPv6 sources still pass before each policy change.
How to monitor IPv6 sources with Suped
A single header explains one message. DMARC aggregate reports contain source IPs and authentication counts for both passing and failing traffic. They do not contain message bodies or prove which account sent a message, and coverage depends on participating receivers.
Suped's DMARC monitoring turns receiver reports into a source inventory with authentication results and sender classifications. Review the IPv6 source IP, compare its domains and message counts, then confirm whether the owner recognizes the source.
The practical Suped workflow
- Connect the domain and enable DMARC reporting to collect receiver data.
- Separate known senders from unknown sources and suspicious IPv6 traffic.
- Repair SPF, DKIM, policy, or account-control gaps found for the source.
- Move toward reject only after reports show that legitimate sources authenticate.
Record a decision for every source: approve it, repair its authentication, remove its authorization, or escalate abuse.
Frequently asked questions
No. DMARC uses the same SPF and DKIM domain-matching rules for IPv4 and IPv6. A matching DKIM pass can satisfy DMARC even if SPF fails.
Yes. DMARC checks the domain, not whether the local-part before the at sign is a real or familiar mailbox.
Not as a first step. Blocking a major notification domain can break legitimate mail. Inspect the authenticated source and message path first.
Spam passes DMARC when it uses an authenticated route for the visible From domain or carries a valid matching DKIM signature. DMARC is not a content filter.
No. ARC can preserve authentication observations across forwarding and influence a receiver's local handling, but it does not change the DMARC result itself.
No. p=reject requests rejection of messages that fail DMARC. Mail that passes through an authorized account still needs account controls and recipient-side content filtering. Strict domain matching does not block an authenticated sender using the exact From domain.
