Skip to main content
Relaymetry

Outlook 5.7.510 Fix: Recipient Does Not Accept Email Over IPv6

An Outlook 5.7.510 bounce means the recipient’s mail system does not accept email over IPv6. Your server connected to the recipient over IPv6, but the recipient’s domain or server accepts inbound mail only over IPv4. The full text is “Access denied, [contoso.com] does not accept email over IPv6,” and per Microsoft it means you tried to transmit over IPv6 to a recipient that does not accept it. This is not an authentication, reputation, or content problem — it is a transport-capability mismatch. Because the recipient controls whether they accept IPv6, the fix is on your side: send the message over IPv4 instead by preferring IPv4 on your outbound mail path.

Quick answer

An Outlook 5.7.510 bounce means the recipient's mail system does not accept email over IPv6. Your server connected to the recipient over IPv6, but the recipient's domain or server is configured to accept inbound mail only over IPv4. The full text is Access denied, [contoso.com] does not accept email over IPv6, and per Microsoft it specifically means the sender tried to transmit over IPv6 to a recipient that does not accept IPv6 messages. This is not an authentication, reputation, or content problem — it is a transport-capability mismatch. Because the recipient controls whether they accept IPv6, the practical fix is on your side: send the message over IPv4 instead by preferring IPv4 on your outbound mail path.

What the 5.7.510 code means

Microsoft's NDR table defines 550 5.7.510 Access denied, [contoso.com] does not accept email over IPv6 as "The sender is trying to transmit a message to the recipient over IPv6, but the recipient doesn't accept email messages over IPv6." The [contoso.com] placeholder is the recipient domain that refused the IPv6 connection.

The key point is whose problem this is. The connection happened over IPv6 because your outbound server resolved an IPv6 (AAAA) address for the recipient and connected to it, but the recipient's mail system is not set up to receive anonymous inbound email over IPv6. Many mail systems still accept IPv4 only. Microsoft lists the remediation for this code as "Not applicable," because the recipient — not you — controls whether they accept IPv6. Your lever as the sender is to fall back to IPv4.

It helps to place 5.7.510 next to its mirror image, 5.7.25, because they are both IPv6 transport issues with opposite causes and opposite fixes:

  • 5.7.510 — the recipient does not accept email over IPv6 at all. Fix: send over IPv4 instead.
  • 5.7.25 — your sending IPv6 address has no reverse-DNS (PTR) record. Fix: add a PTR record for your IPv6 address.

Both fire on an IPv6 connection, but 5.7.510 is about the recipient's capability while 5.7.25 is about your own DNS hygiene. See the 5.7.25 guide for the PTR side.

Why Outlook returns 5.7.510

Outlook returns 5.7.510 when your outbound server reaches the recipient over IPv6 and the recipient's mail system declines IPv6 mail. The common situations are:

  • The recipient publishes an AAAA record but does not accept inbound IPv6 mail. Your server sees the IPv6 address, prefers it, and connects over IPv6 — but the receiving side only accepts IPv4 for inbound email.
  • Your outbound path defaults to IPv6. Modern hosts and mail servers often prefer IPv6 when both an A and an AAAA record exist, so the IPv6 connection is attempted first by default.
  • A dual-stack relay or sending host that has IPv6 connectivity and routes outbound SMTP over IPv6 to recipients that are not ready for it.

Because the decision is made on the recipient's side and reflects their configuration, there is nothing to authenticate or delist. The connection simply has to happen over IPv4 instead.

How to diagnose a 5.7.510

Start by confirming from the NDR that delivery was attempted over IPv6 to a recipient that does not accept it. The diagnostic line names the code 5.7.510 and the recipient domain in the [contoso.com] slot, and the message Received: headers show the connection was made over an IPv6 address. That combination — an IPv6 source address plus the 5.7.510 text — is the signature of this code.

Next, identify your outbound path. Determine which host actually opened the SMTP connection: your own mail server, a smarthost, or a sending platform. When you send through a platform, the IPv6 connection is usually made by an address the platform owns, so the fix may belong to the platform's outbound configuration rather than your domain DNS.

Then confirm this is a transport issue and not an authentication one. A 5.7.510 is not an SPF, DKIM, or DMARC failure, so do not chase authentication records to clear it. Keeping SPF, DKIM, and DMARC aligned still matters for general deliverability once the message routes over IPv4, but it is not what this code is about.

One thing to keep in mind: you cannot change whether the recipient accepts IPv6. Their AAAA records and their inbound configuration are theirs to manage. Your diagnosis ends at confirming the IPv6 connection and locating the outbound path you control.

How to fix a 5.7.510

The fix is to send over IPv4 instead. Because the recipient controls IPv6 acceptance, your remediation is to stop offering the message over IPv6 and let it route over IPv4.

  1. Confirm the IPv6 transport from the NDR. Verify the 5.7.510 code and the recipient domain in the diagnostic line, and check the Received: headers to confirm the connection was made over an IPv6 address.
  2. Identify the outbound mail path that opened the connection — your mail server, smarthost, or sending platform — so you know where to change the IPv4 preference.
  3. Prefer or force IPv4 on the outbound path. Disable IPv6 for outbound SMTP, or set your mail server or host to prefer IPv4 when both A and AAAA records exist, so the next attempt connects over IPv4.
  4. Or route through an IPv4-capable relay or platform. If you cannot change the outbound stack directly, send through a relay or sending platform that connects to recipients over IPv4.
  5. Re-test delivery over IPv4. Send a small test to the same recipient and confirm the message now connects over IPv4 and is accepted, with no 5.7.510 in the result.
  6. Keep SPF, DKIM, and DMARC aligned for your visible From domain so the message authenticates cleanly once it routes over IPv4. This does not clear 5.7.510, but it protects general deliverability.

What this does not prove

Confirming the IPv6 transport and switching your outbound path to IPv4 resolves the 5.7.510 for recipients that accept IPv4 — which is most of them. It does not change the recipient's IPv6 configuration, and it cannot guarantee delivery if a separate authentication, reputation, or content problem also applies to the message once it routes over IPv4.

A public DNS and blacklist check confirms whether your sending IP is listed and whether your SPF, DKIM, and DMARC records are in order. It cannot read the recipient's inbound IPv6 configuration or confirm that a specific past message was refused for this exact reason. The 5.7.510 decision is made on the recipient's side based on whether they accept IPv6 at all.

Frequently asked questions

What does Outlook 5.7.510 does not accept email over IPv6 mean?

Per Microsoft, 550 5.7.510 "Access denied, [contoso.com] does not accept email over IPv6" means you tried to transmit a message to the recipient over IPv6, but the recipient doesn’t accept email over IPv6. Your server connected to the recipient over IPv6 while the recipient’s mail system accepts inbound mail only over IPv4. It is a transport-capability mismatch, not an authentication, reputation, or content failure, so SPF, DKIM, and DMARC can all pass while the message is still refused.

Whose problem is 5.7.510, the sender or the recipient?

The recipient controls whether they accept IPv6, and Microsoft lists the remediation for this code as "Not applicable" for that reason — you cannot change the recipient’s inbound IPv6 configuration. But the practical lever is on your side as the sender: send the message over IPv4 instead. Your outbound server connected over IPv6 because it resolved an AAAA address and preferred it, so making the next attempt connect over IPv4 resolves the bounce for recipients that accept IPv4.

How do I send over IPv4 instead of IPv6?

Change your outbound mail path so it connects over IPv4. Disable IPv6 for outbound SMTP, or configure your mail server or host to prefer IPv4 when both A and AAAA records exist, so the next attempt uses the IPv4 address. If you cannot change the outbound stack directly — for example when you send through a platform — route through a relay or sending platform that connects to recipients over IPv4, then re-test delivery to confirm the message routes over IPv4 and is accepted.

Is 5.7.510 the same as 5.7.25?

No — they are mirror images. 5.7.510 means the recipient does not accept email over IPv6 at all; the fix is on your side, to fall back to IPv4. 5.7.25 means your own sending IPv6 address has no reverse-DNS (PTR) record; the fix is to add a PTR record for your IPv6 address. Both fire on an IPv6 connection, but one is about the recipient’s capability and the other is about your DNS hygiene, with opposite causes and opposite fixes.

Can Relaymetry check whether a recipient accepts IPv6?

No. Whether a recipient accepts inbound email over IPv6 is part of their mail system’s configuration and is not exposed through any public lookup. Relaymetry checks public signals for your domain — your sending IP’s blocklist status and your SPF, DKIM, and DMARC records — which keeps general deliverability clean once the message routes over IPv4, but it cannot read or change the recipient’s IPv6 acceptance.

Other Outlook issues

References