Why are emails from Microsoft accounts being rejected by Gmail, and what is the role of IPv6?
Updated on 7 Oct 2026: We clarified Outlook.com and Microsoft 365 fixes, Gmail's nested rejection codes, and the evidence needed to diagnose IPv6 delivery failures.
Emails from Microsoft accounts get rejected by Gmail when the message fails Gmail's authentication, infrastructure, formatting, reputation, or abuse checks. IPv6 is relevant when the SMTP response identifies an IPv6 PTR or authentication problem, a low-reputation IPv6 address, or repeated tests isolate the Microsoft IPv6 path. An IPv6 address in the bounce does not by itself prove that IPv6 reputation caused the rejection.
Read the complete Gmail response before changing DNS. Gmail uses 550 5.7.1 for several different failures, including very low domain reputation, very low IP reputation, IPv6 PTR or authentication failures, unsolicited mail, and malformed headers. If the response names low domain reputation, investigate the domain and its sending history even when the connection used Microsoft IPv6 infrastructure.
- Direct cause: Gmail rejects the SMTP transaction because a specific acceptance rule failed.
- IPv6 role: The IPv6 source has its own PTR, authentication, and reputation evidence, but the bounce must connect that evidence to the failure.
- First check: Capture the exact response, then verify SPF, DKIM, DMARC domain alignment, forward and reverse DNS, and message headers.
- Practical fix: Correct domain-side faults first. If clean comparison tests isolate Microsoft, escalate with the source IP, outbound pool, timestamps, message IDs, and full bounce.
Outlook.com accounts and Microsoft 365 need different fixes
Identify the sending service first. Personal Outlook.com, Hotmail, and Live accounts use domains and authentication managed by Microsoft. Microsoft 365 custom-domain mailboxes let the domain owner configure SPF, DKIM, and DMARC. The Outlook app is an email client; turning off IPv6 on your computer does not change the outbound connection made by Microsoft's cloud servers.
- For a personal account, save the full non-delivery report and contact Outlook.com support. Microsoft controls the sender domain's DNS and outbound infrastructure.
- For a Microsoft 365 custom domain, validate your DNS and sending identity, then use Exchange Online Message trace and tenant support to investigate the route.
Microsoft marked the Outlook.com country-domain Gmail issue as fixed on 6 August 2024. The Outlook.com alias recommendation reported in 2024 was a workaround for that incident. Microsoft's Outlook.com issue status says affected users can return to their country-domain address. Diagnose a current rejection using its own bounce text.
How to read Gmail rejection codes
Gmail does not accept or reject email based on the brand name alone. It evaluates the message, envelope sender, header From domain, SPF, DKIM, DMARC domain alignment, IP reputation, domain reputation, forward and reverse DNS, TLS, complaint history, sending volume, and signs of abuse. A Microsoft account uses shared infrastructure, so the decision can include both your domain and Microsoft's outbound servers.
That distinction matters. If your domain sends to Gmail through a different platform but fails through Microsoft, the Microsoft route becomes a strong lead only after both tests use equivalent domain alignment, headers, content, and sending behavior. A route comparison narrows the diagnosis. It does not override a bounce that explicitly names low domain reputation.
Treat the rejection text as evidence
Gmail publishes separate rejection text for low domain reputation, low sending-IP reputation, missing or mismatched PTR records, failed authentication, and malformed messages. Save every line of the response and diagnose the condition it names. If it includes 'gcdp', a Google Workspace administrator's custom policy is involved. Use Google's SMTP error reference to interpret the complete response.
The common trap is to keep changing DNS when DNS is already correct. Validate DNS first because Gmail can reject unauthenticated mail before deeper route analysis helps. Once authentication and domain alignment pass, compare the exact Gmail response, Microsoft source address, IP family, and outbound pool.
|
|
|
|---|---|---|
Low domain reputation | Domain history | Authentication, complaints, traffic |
Low IP reputation | Sending route | Source IP and outbound pool |
IPv6 PTR error or 5.7.25 / 4.7.23 | Forward and reverse DNS | Connecting IP, PTR, matching AAAA |
5.7.26 authentication rejection | Authentication | Exact wording: SPF failure, unauthenticated mail, or DMARC policy |
421 4.7.28 rate limit | Temporary deferral | Named IP, netblock, DKIM or SPF domain, or linked URL domain |
Use the bounce wording and comparison result to decide where to look first.
Microsoft's non-delivery report (NDR) can wrap Gmail's response. For '550 5.7.350 ... -> 550 5.7.1 ...', diagnose the Gmail text after the arrow. For '550 5.4.300 Message expired -> 421 4.7.28 ...', Microsoft exhausted retries after Gmail deferred delivery. The reported IP rate-limit example demonstrates this pattern; its response does not establish a peering-capacity fault.
For a related Gmail-side rejection pattern, this page on sudden Gmail rejections is useful when the failure affects multiple senders or platforms, not only Microsoft.
Why IPv6 changes the diagnosis
IPv6 is a supported email transport. Each IPv6 sending path still needs valid DNS identity and reputation. Gmail requires a sending IP to have a PTR record that resolves to a hostname, and that hostname must resolve back to the same IP through an AAAA record for IPv6. SPF or DKIM must also authenticate the mail.
A sender can succeed on IPv4 and fail on IPv6 because Gmail judges the connecting address and DNS identity as part of the transaction. Public reports of Microsoft 365 rejections contain IPv6 sources, but the cited case says low domain reputation. That wording makes domain history and recent authentication changes part of the investigation, not proof of an IP-only problem.
Microsoft-to-Gmail email delivery flow with an IPv6 source, reputation checks, and authentication checks.
When Microsoft controls the connecting host, the tenant cannot change that host's PTR, AAAA record, or shared IP reputation. The tenant can still correct its custom-domain authentication, sending practices, and account security. Microsoft must investigate infrastructure faults or an inappropriate outbound pool.
IPv4 sending
- DNS check: PTR hostname resolves back through an A record.
- Evidence: Compare the exact IPv4 source and pool.
- Control: Microsoft controls shared Exchange Online addresses.
IPv6 sending
- DNS check: PTR hostname resolves back through an AAAA record.
- Evidence: Match the IPv6 source to the bounce wording.
- Control: Microsoft controls the route and shared address.
Use the IPv6 address Gmail identifies as the connecting source. IPv6 addresses in Microsoft's internal Received headers describe earlier hops and do not identify the outbound server that connects to Gmail. Treat IPv6 as a serious lead when Gmail names IPv6 PTR or authentication, low reputation for the shown IP, or a repeatable failure isolated to the Microsoft IPv6 path.
For the separate question of why spoofed messages can pass authentication, see IPv6 and DMARC authentication.
How to test the Microsoft sending route
Use a controlled comparison: keep the From domain, aligned authentication, message, recipient type, and timing as consistent as possible, then change the sending path. If Gmail rejects Microsoft but accepts another authenticated route, inspect the Microsoft source and outbound pool. If Gmail rejects both, return to domain reputation, authentication, content, list quality, or complaint history.
- Capture the bounce: Save the full SMTP response, including the three-digit code, enhanced status code, remote host, source address, and diagnostic token.
- Inspect headers: For a delivered Gmail test, check Gmail's Received hop and Authentication-Results, the DKIM d= domain, and the envelope sender. Microsoft's internal or ARC authentication results do not establish Gmail's result.
- Compare routes: Send the same simple message to Gmail through Microsoft and through another authorized route.
- Check domain alignment: Confirm a passing SPF or DKIM domain meets DMARC's domain alignment requirements for the header From domain.
- Trace Microsoft delivery: Record the source address and OutboundIpPoolName when Message trace exposes it.
Evidence to collect from a Gmail rejectiontext
SMTP response: full Gmail response and enhanced status code Sending service: Microsoft 365, Outlook.com, or another service Source IP: exact IPv4 or IPv6 address Gmail reports Outbound pool: OutboundIpPoolName if available Timestamp: UTC time of failed delivery Message-ID: full header value Authentication: receiving server's results and authenticated domains Comparison: same domain sent through another authorized route
A delivered Gmail test message shows which source IP Gmail saw, which domains authenticated, and whether DMARC alignment passed. If no message reaches Gmail, Suped's email tester provides received headers and authentication results at a diagnostic inbox. That test verifies the sampled delivery; Microsoft can select a different outbound source for Gmail, so it does not prove the failed attempt used the same IP.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
No data in Gmail's domain reporting does not prove the domain is clean or that IPv6 caused the failure. Domain verification and sufficient traffic are required, and low daily volume can leave data hidden for privacy. Google's reporting guidance explains these limits. Use the SMTP response, headers, Microsoft trace, and repeated tests as the immediate evidence.
Authentication checks that still matter
Gmail requires all senders to personal Gmail accounts to use SPF or DKIM. Bulk senders need SPF, DKIM, and DMARC, plus DMARC alignment for direct mail. Google defines bulk senders as those sending close to 5,000 messages or more within 24 hours, counts subdomains under the same primary domain, and retains that classification once reached. These bulk-sender rules apply to personal Gmail recipients; Google Workspace recipients can have separate administrator policies. See Google's sender guidelines FAQ.
For bulk senders, p=none meets Google's minimum DMARC-policy requirement. Marketing and subscribed messages also need one-click unsubscribe and a visible unsubscribe link. Google recommends a reported spam rate below 0.1% and avoiding 0.3% or higher. Passing authentication alone does not guarantee acceptance. See Google's sender guidelines.
A simple pass is not enough for DMARC. SPF can pass for a Microsoft envelope domain while DMARC fails because its domain relationship to the visible From domain is invalid. DKIM can also pass with a Microsoft-controlled d= domain that does not meet DMARC's domain alignment requirements. One passing mechanism with valid domain alignment is enough for DMARC. Under relaxed alignment, the domains can share the same organizational domain; strict alignment requires an exact match.
Example DMARC record for monitoringdns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=none; rua=mailto:dmarc@example.com" )
Do not publish a strict policy blindly
If Microsoft 365 and other approved systems send as your domain, monitor first. Identify every legitimate source, fix domain alignment, then move toward quarantine or reject. Strict adkim or aspf tags are optional and should be used only when the domain needs them.
Suped's DMARC monitoring groups aggregate reports by source and shows authentication and domain alignment results. During a Microsoft-to-Gmail incident, use those reports to identify persistent domain-authentication faults. Aggregate reports do not contain the full SMTP bounce or replace route testing; collect Microsoft's trace and Gmail's rejection text separately.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For a quick DNS validation, use Suped's domain health checker. For ongoing investigation, use DMARC monitoring to track authentication by source while Microsoft and Gmail routing evidence is collected separately.
Fix custom-domain authentication in Microsoft 365
For a Microsoft 365 custom domain, authorize Exchange Online in SPF and enable DKIM signing for the visible From domain. A Microsoft-controlled DKIM d= domain does not automatically cause DMARC failure: a passing SPF result with valid domain alignment can satisfy DMARC. A default onmicrosoft.com address is not inherently unauthenticated; the concern is whether the actual From domain and passing authentication meet DMARC's domain requirements.
Correct a domain-authentication fault before asking Microsoft to investigate infrastructure reputation. Passing SPF or DKIM does not remove a domain or IP reputation problem.
|
|
|
|---|---|---|
From domain | Unapproved or mismatched domain | Verified domain with authorized sending |
DKIM | Unaligned d= domain | Aligned custom domain |
SPF | Stale or incomplete | Current authorized sources |
DMARC | No reporting | Aggregate reports reviewed |
Check the actual sending identity rather than assuming a default tenant domain is faulty.
Recent Microsoft 365 migrations deserve extra attention. A working mailbox does not prove that its sending identity is complete. DKIM selectors can remain unpublished, old SPF mechanisms can survive after the old host stops sending, and automated systems can continue using an unaligned envelope domain.
For standard Exchange Online sending, retain include:spf.protection.outlook.com in the existing SPF policy instead of hard-coding the shared IPv6 address from a bounce. Other Microsoft cloud environments use different includes. Microsoft's SPF instructions list the required values. The MAIL FROM domain must have a valid SPF policy, with no more than 10 lookup-causing terms evaluated.
Microsoft 365 admin center showing Exchange Online SPF and DKIM DNS records.
Check which Microsoft outbound pool was used
Exchange Online does not send every message through the same kind of pool. Microsoft documents a normal outbound pool, a high-risk delivery pool for messages it classifies as low quality, and a separate relay pool for some forwarded or relayed mail. Microsoft's outbound delivery pool documentation explains the distinction. A Gmail rejection tied to one pool needs a different response from a custom-domain authentication failure.
An Exchange Service Administrator can use Message trace and inspect the OutboundIpPoolName property when it is available. Record that value with the source IP, Network Message ID, recipient, and UTC timestamp. This gives Microsoft support a route-specific event to investigate instead of a general complaint about Gmail.
- Normal pool: Check the exact Gmail reason, source reputation, and whether the failure repeats on the same route.
- High-risk pool: Investigate account compromise, outbound spam classification, backscatter, and the public DNS identity of the source email domain.
- Relay pool: Investigate forwarding, relaying, accepted-domain configuration, inbound SPF, and DKIM for the original sending domain.
Check public A and MX records
Microsoft states that messages whose source email domain has neither a public A record nor a public MX record are always routed through the high-risk delivery pool. Verify these record types specifically; an unrelated TXT record or an AAAA record alone does not meet the stated A-or-MX condition.
The pool name does not replace the Gmail response. Use both. A low-domain-reputation response still requires domain remediation, while an IPv6 PTR response tied to a Microsoft-controlled source requires Microsoft to check the host's forward and reverse DNS.
What to ask Microsoft to investigate
Ask Microsoft to identify the outbound pool and source used for the failed delivery, verify the IPv6 address's PTR and forward DNS, review whether the message was placed in a high-risk or relay pool, and provide a supported mitigation. Microsoft's Disable-IPv6ForAcceptedDomain documentation controls inbound delivery to your accepted domain. It does not force Exchange Online's outbound mail to Gmail over IPv4.
Do not open a vague case that says Gmail is blocking us. Include UTC timestamps, source IPs, recipient domains, full bounce text, tenant details, Message trace identifiers, OutboundIpPoolName when available, and proof of domain alignment. State whether the same message succeeds through another authorized route.
Support case wordingtext
Gmail is rejecting mail from our Microsoft 365 tenant. The attached full NDR contains this Gmail response: [exact reason and code]. Receiver-verified authentication: [SPF, DKIM, DMARC results and domains, if available]. Microsoft source IP reported by Gmail: [exact IPv4 or IPv6 address]. OutboundIpPoolName: [value if available]. UTC timestamp, Message-ID, and Network Message ID: [values]. Comparison result: [same domain and message through another authorized route]. Please verify the outbound pool, source reputation, PTR and forward DNS, and supported routing mitigation.
Treat IPv4 connector recipes cautiously
Community threads describe connector configurations that appeared to route certain Gmail traffic over IPv4, but the cited Microsoft Q&A later struck out that recipe. Do not deploy destination-specific connector changes without Microsoft confirming that the design is supported and validating mail flow.
Public Microsoft support threads document similar 550 5.7.1 failures and conflicting community fixes. They provide incident context, not proof that the same cause or connector change applies to your tenant.
Avoid changes that hide the rejection cause
Random DNS editing creates new failure modes and weakens the evidence. Duplicate SPF records, removed DKIM selectors, an untested DMARC policy, or a changed From domain can hide the original cause.
- Do not add duplicate SPF: A domain must have one SPF policy record. Multiple records can produce a permanent error.
- Do not remove DKIM: Aligned DKIM often keeps DMARC passing when SPF breaks during forwarding.
- Do not change policy first: Review reports before tightening DMARC. Lowering the policy does not fix a Gmail domain-reputation, shared-IP, or PTR rejection.
- Do not force a connector blindly: A destination-specific route can create TLS, validation, or support problems.
- Do not ignore blocklists: A blocklist or blacklist hit is supporting evidence, not automatic proof of Gmail's reason.
Suped's blocklist monitoring can track IP and domain listings beside authentication evidence. Use a blocklist (blacklist) result to support the incident timeline, but use Gmail's exact response to identify the rejection condition.
Escalation confidence
Use this as a rough guide before opening a Microsoft support case.
Weak
Low
Only one bounce and no authentication proof.
Useful
Medium
Bounce plus authentication and source-IP evidence.
Strong
High
Exact reason, route comparison, trace ID, and outbound pool.
A practical troubleshooting sequence
Start with a timeline and eliminate the basics before attributing the rejection to IPv6. The useful diagnosis is the one supported by the exact Gmail response, message headers, DNS, Microsoft trace data, and repeatable tests.
- Read the SMTP response: Separate domain reputation, IP reputation, IPv6 PTR or authentication, unauthenticated mail, and temporary deferral.
- Validate the custom domain: Confirm one SPF record, enabled Microsoft DKIM selectors, a valid DMARC record, public A or MX records, and no stale senders.
- Send a controlled test: Use a simple message with minimal links and no attachment so content differences do not cloud the route comparison.
- Inspect the route: Record the source IP, IP family, aligned domains, Message trace identifiers, and outbound pool.
- Compare and escalate: Repeat through another authorized route, then send Microsoft the evidence that isolates its path.
If the same domain is being rate limited rather than permanently rejected, the related pattern is covered in Microsoft 365 rate limits. A Gmail 4xx deferral calls for automatic retries with backoff and rate analysis; avoid repeated manual resends while Microsoft is retrying. A Gmail 5xx rejection calls for correction before resending. If Microsoft's final NDR says 'message expired', inspect the nested Gmail response before classifying the original failure.
Fix the condition Gmail names
Fix the condition Gmail names. If authentication and domain history are clean and repeated evidence isolates a Microsoft IPv6 source or outbound pool, ask Microsoft to remediate that source or provide a supported routing mitigation.
Views from the trenches
These June 2024 reports describe specific incidents. Diagnose today's rejection with current bounce text and route evidence.
Best practices
Compare Microsoft delivery with a second authenticated route before changing DNS records.
Capture the Gmail source IP, full bounce text, and message ID before opening a support case.
Check the outbound pool and domain alignment so the case identifies the failing path.
Common pitfalls
Treating every low-domain-reputation response as proof of an IPv6 reputation fault.
Publishing duplicate SPF records while trying to fix a shared infrastructure issue.
Applying an unverified IPv4 connector recipe that creates a second mail flow problem.
Expert tips
Ask Microsoft to review the outbound pool and IPv6 source when evidence isolates them.
Use a simple test message so content filtering does not obscure the route comparison.
Monitor blocklist and blacklist evidence, but follow the exact Gmail response wording.
Marketer view
Marketer from Email Geeks says the key clue is that the same domain can deliver to Gmail from other platforms while Microsoft-originated mail fails.
2024-06-04 - Email Geeks
Marketer view
Marketer from Email Geeks says Gmail can treat prior Outlook IPv6 traffic as a reputation signal and reject later mail to protect recipients.
2024-06-04 - Email Geeks
