# 550 5.7.510 does not accept email over IPv6: what it means and the fix

> 550 5.7.510 means the recipient's Microsoft 365 domain does not accept mail over IPv6 and you connected that way. Send over IPv4, or have them enable IPv6.

- Published: 2026-11-09
- Author: Koltrix Team
- Category: Deliverability
- Source: https://koltrix.com/blog/550-5-7-510-does-not-accept-email-over-ipv6-what-it-means-and-the-fix

A bounce that reads "550 5.7.510 Access denied, [contoso.com] does not accept email over IPv6" looks like a policy block, but it is closer to a wrong-door error. Your sending server reached the recipient's Microsoft 365 mail endpoint over IPv6, and that domain has not been set up to take mail that way. Nothing is wrong with your message, your content or your reputation.

This post explains what the code says, why it appears even though the recipient is a normal Microsoft 365 customer, and how to fix it from either side of the conversation.

## What does "550 5.7.510 does not accept email over IPv6" mean?

It means the receiving system refused your connection permanently because you made it over IPv6 and the recipient's domain does not accept inbound mail over IPv6. IPv6 is the newer internet addressing system, with long addresses such as `2001:db8::25`, that runs next to the older IPv4 addresses such as `203.0.113.25`. A mail server can have both kinds of address at once.

Microsoft's own [Exchange Online NDR reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) lists 5.7.510 as `Access denied, [contoso.com] does not accept email over IPv6`, with the explanation that the sender is trying to transmit a message over IPv6 but the recipient does not accept email messages over IPv6. The `550` is the permanent reply code from [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321), and `5.7.510` is an enhanced status code in the format [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463) defines. The 5.7.510 number itself is Microsoft's own, not a general standard.

Do not confuse it with the neighbors in the same table. 5.7.509 is a DMARC rejection, 5.7.511 is a banned sending IP, and 5.7.512 is a message with no valid From address. Only 5.7.510 is about the IP version.

## Why would a Microsoft 365 domain refuse IPv6?

Because inbound IPv6 mail to Exchange Online is not on by default for every domain. In an archived Microsoft Exchange team post from 2014, the service did not allow inbound IPv6 connections by default, and a customer had to ask for it, domain by domain. Domains not enabled did not return AAAA records for their MX host, and a sender who connected over IPv6 anyway got a permanent rejection. That post is old and archived, so treat the opt-in detail as history and check the current state with Microsoft, but it explains the shape of the error.

A "AAAA record" is the DNS record that maps a hostname to an IPv6 address, the same way an A record maps it to IPv4. Here is what a sender should normally see for a domain that has not enabled IPv6:

| Record lookup on the MX host | Result for a domain without IPv6 |
| --- | --- |
| A record | One or more IPv4 addresses |
| AAAA record | None returned |

So the usual cause is a sender that bypassed the normal lookup, was handed an IPv6 address from stale DNS, or was told to use one by its own configuration. Sending servers are supposed to follow MX records, and if the MX host has no IPv6 address there is nothing to prefer.

## How do you tell the cause on your side?

Read the bounce for the exact connecting address, then look at how your server picked it. These are the common causes:

1. **A hard-coded relay or smart host.** Your server is set to deliver to a specific IPv6 address or a hostname you control that resolves to one, instead of looking up the recipient's MX.
2. **A stale or hand-edited DNS entry.** An old `AAAA` record, a hosts-file entry or a cached answer points at an IPv6 address for a mail host.
3. **A forced IPv6 transport.** The server or library is set to IPv6 only, or an application inside a container is bound to an IPv6 address.
4. **A forwarding or security gateway** in the path that connects over IPv6 on your behalf. The bounce names the system that generated it, so check which hop it is.

You can see which address family a delivery used in the bounce's diagnostic text and in your own mail log. Then test the destination by hand, with the recipient's real MX host:

```bash
dig +short MX contoso.com
dig +short A    contoso-com.mail.protection.outlook.com
dig +short AAAA contoso-com.mail.protection.outlook.com

# Force each address family to see which one fails
swaks --to someone@contoso.com --from you@yourdomain.com -4
swaks --to someone@contoso.com --from you@yourdomain.com -6
```

If `-4` is accepted and `-6` returns 5.7.510, the diagnosis is confirmed. Our guide to [testing SMTP with swaks and openssl](/blog/swaks-openssl-smtp-testing) shows how to read the rest of a session.

## How do you fix it as the sender?

Make your server deliver over IPv4 to that domain, since the receiver is not asking for IPv6. Retrying the same message the same way will fail again, because this is a permanent error and not a temporary deferral.

| Where the IPv6 choice is made | What to change |
| --- | --- |
| Your own MTA, such as Postfix | Prefer IPv4 for outbound delivery. In Postfix this is the `smtp_address_preference` setting, documented in the [Postfix parameter reference](https://www.postfix.org/postconf.5.html#smtp_address_preference). |
| A hard-coded smart host | Point it at the provider's hostname or an IPv4 address. |
| An old AAAA or hosts entry | Remove it so the server resolves the recipient's real MX. |
| A hosted sending service or API | Nothing to change on your side, since the provider chooses the address. Send the bounce details to their support. |

Do not disable IPv6 across the whole machine as the first move. It fixes this domain and quietly changes behavior everywhere else. A per-destination or per-protocol preference is a smaller change.

Mail you send through a hosted transactional service normally goes out from the provider's own addresses, so you cannot pick the IP version there. If you see 5.7.510 from a service you call over an API, send the full bounce to that service and quote the connecting IP.

## How do you fix it as the recipient?

If you run the Microsoft 365 domain and legitimate senders keep getting this, the decision is yours: stay IPv4 only, or turn IPv6 on. Staying IPv4 only is a valid choice, and well-configured senders fall back to IPv4 on their own. Contact Microsoft support to ask about IPv6 for your domain, because the current process is not documented in the NDR page.

Before asking for it, know what you are accepting. In the archived Microsoft post, mail arriving over IPv6 was held to stricter checks than IPv4. The sending IPv6 address had to have a PTR record, and the message had to pass SPF or DKIM. Those requirements matter to your senders as much as to you, so plan for failures when a sender has no reverse DNS on its IPv6 address. Our posts on [reverse DNS, PTR and HELO](/blog/reverse-dns-ptr-helo) and the [Gmail PTR and IPv6 requirement](/blog/gmail-550-5-7-25-the-ptr-record-gmail-requires-and-ipv6) cover that side.

## Is this the same as a 451 deferral over IPv6?

No. A `451` or `4.x.x` code means a temporary failure and your server should retry. A `550 5.7.510` is permanent and your server will bounce it after one try. Microsoft IPv6 deferrals have happened before. In 2022 [Spam Resource](https://www.spamresource.com/2022/10/problems-sending-to-microsoft-over-ipv6.html) reported senders seeing `451 4.7.500 Server busy` when delivering to Microsoft consumer domains over IPv6, with delivery over IPv4 working. Check the first digit before choosing between waiting and changing the route. The [greylisting and deferrals guide](/blog/greylisting-and-deferrals) explains when waiting is right.

## What should you check first?

Run through this list in order:

- Read the bounce and note the connecting IP address and whether it is IPv6.
- Look up the recipient's MX host, and check whether it has AAAA records.
- Force IPv4 and IPv6 in a manual test and see which one works.
- Find where your server chose IPv6: a smart host, a DNS entry, a config setting.
- Change that to IPv4 for the destination and resend a fresh message.
- If your own domain gets the error from others, decide whether to enable IPv6 and ask Microsoft.

## Bottom line

550 5.7.510 says the recipient's Microsoft 365 domain does not accept mail over IPv6 and you came in that way. As a sender, deliver over IPv4 and find the setting that chose IPv6. As the recipient, either stay IPv4 only, which is fine, or ask Microsoft about enabling IPv6 and prepare for its PTR, SPF and DKIM requirements. Nothing about your message content needs changing.