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. 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.8and1.1.1.1are 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 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:
- 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.
- 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 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.