---
title: "Anycast Routing"
description: "Anycast routing sends a request to the nearest of several servers sharing the same IP address, commonly used to improve DNS performance and reliability."
url: "https://mailmum.io/glossary/anycast-routing/"
---

# Anycast Routing

Anycast routing is a technique in which the same IP address is announced from
several locations at once, and the routing system delivers each packet to
whichever of those locations is nearest in network terms. The sender addresses
one IP; which machine actually answers depends on where the sender is.

"Nearest" here means nearest according to BGP, not geographically. A user in
Vienna may well be served by a node in Frankfurt rather than one in Bratislava,
because the path through Frankfurt is shorter in AS hops.

## How does anycast work?

Several independent nodes announce the same prefix into BGP, each from its own
location and usually under the same
[ASN](https://mailmum.io/glossary/autonomous-system-number-asn/). Every router on the internet
then holds multiple candidate routes to that prefix and picks one by its normal
best-path selection.

The consequence is that failover is a property of the routing system rather than
of the service. When a node stops announcing the prefix — because it
failed, or because it was withdrawn for maintenance — routers converge on
the next-best path within seconds and traffic moves to another node without any
change to DNS or to the client.

## Where is anycast used in email infrastructure?

Anycast is everywhere in the systems email depends on, even though it is rarely
used for the mail servers themselves:

* **DNS resolution.** The root servers, most large authoritative DNS providers,
  and the public resolvers at `8.8.8.8` and `1.1.1.1` are all anycast. Every
  MX, SPF, DKIM and DMARC lookup your server makes is answered this way.
* **DNS blocklists.** DNSBL operators serve their zones from anycast nodes,
  because a blocklist lookup sits in the critical path of every inbound SMTP
  connection and a slow answer delays every message. See
  [IP blacklisting](https://mailmum.io/glossary/ip-blacklisting/) for how those queries work.
* **DDoS absorption.** Spreading a prefix across many locations spreads an
  attack across them too, which is why anycast is standard for infrastructure
  that must stay reachable.

## Why is anycast rare for SMTP itself?

SMTP is a long-lived TCP session, and mail delivery is stateful in a way DNS is
not. Two problems follow:

1. **Route changes mid-session.** If BGP reconverges while a message is being
   transferred, the remaining packets arrive at a different node with no
   knowledge of the session, and the connection dies. A DNS query is a single
   packet exchange and simply gets retried; a half-transferred 20 MB message
   does not.
2. **Queues are per-node.** Each node has its own mail queue and its own
   deferred messages. Retries for a message queued in Frankfurt may be routed to
   Singapore, where nothing is waiting.

Email solves the same problem a different way. Multiple `MX` records with
distinct priorities give a domain several independent, unicast mail servers, and
the sending server chooses between them — retrying the next one if the
first is unreachable. The redundancy lives in the protocol instead of in the
routing table.

## What does anycast mean for IP geolocation?

An anycast address has no single physical location, which breaks the assumption
behind IP geolocation databases. The same address genuinely is in Frankfurt, São
Paulo and Tokyo simultaneously, and any database that assigns it one city is
wrong for most of the world.

This is one of the reasons the [geofeed](https://mailmum.io/glossary/geofeed/) format exists: it
lets the network operator publish the intended location data themselves rather
than leaving third parties to infer it. For anycast prefixes, operators
typically either omit the location or mark the prefix explicitly, and consumers
of that data need to handle the absence rather than fall back to a guess.

## Does anycast affect deliverability?

Indirectly, and mostly through DNS. If the anycast DNS serving your domain is
slow or unreachable from a receiving network, that receiver cannot verify your
SPF record or fetch your DKIM key, and unverifiable authentication is treated
much like failed authentication.

The practical implication is that the resilience of your authoritative DNS
matters to your mail as much as the mail servers do — and for most
operators, that resilience comes from an anycast DNS provider.

## Related reading

The DNS side of an anycast deployment has its own operational obligations, such
as answering correctly under the EDNS rules tightened by
[DNS flag day](https://mailmum.io/posts/dns-flag-day-2020/). A blocklist served over anycast DNS
that fails those tests will time out for some resolvers and silently stop being
consulted — see [DNS blocklist (DNSBL /
RBL)](https://mailmum.io/glossary/dns-blocklist-dnsbl/).