After an IPv4 transfer completes: the record updates to make before you announce
The wire cleared, the registry processed the paperwork, and the block now carries your name. That is step zero, not the finish line. The block will not behave like yours until the records around it say what the registry now says, and the expensive mistakes in this phase are ordering mistakes: announcing before the RPKI record exists, mailing before reverse DNS exists, chasing a geolocation fix before anyone was told where the block went. How transfers work covers everything up to the registry's approval; this is the runbook for what comes after, in the order the mechanics reward.
What died with the transfer, and what did not
Completion is not just a name change; it tears records down. At RIPE NCC, a transfer changes the organisation behind the resource certificate, so the certificate changes and the ROAs on the moved space are removed as part of that change; when space leaves the RIPE region entirely, every associated RIPE Database object goes with it, domain objects included, and reverse delegation drops out of DNS immediately. ARIN removes transferred resources from the seller's certificate along with the ROAs associated with them, and its transfer guidance tells sellers to strip transferring prefixes out of multi prefix ROAs before completion. APNIC is the outlier of the three: since 2022 it has documented a two week window in which the seller's ROAs and the buyer's new ones can coexist after a live transfer, which APNIC says causes no routing problems. LACNIC and AFRINIC run their own variations that this post does not cover; every registry claim here is about these three.
What this means for your first announcement comes down to two RPKI states that sound alike and behave nothing alike. NotFound means no ROA covers the prefix at all; such routes are still accepted by validating networks, just unprotected. Invalid means a ROA covers the prefix and none matches your announcement, and networks that validate drop or heavily depreference Invalid routes; RFC 7115 goes further, recommending they not be used at all and warning that depreference alone still leaks traffic to a more specific Invalid route. Because the seller's ROAs on the moved space die at completion at RIPE and ARIN, a standalone block usually starts out NotFound. The trap is the covering ROA that outlives the move. If you bought a /20 cut from a /16, the registries' automation does shrink the seller's certificate so a ROA spanning your space stops validating or is removed with it, but validator caches can serve the old covering ROA for a while, APNIC keeps a seller's ROAs live for up to two weeks, and space that never actually changed registry hands, leased or sub allocated, keeps the lessor's covering ROA indefinitely. In every one of those windows your more specific announcement is Invalid until your own ROA exists, and that is why the checklist starts where it starts.
First: the ROA, because invalid is the one hard failure
Everything else in this list fails where you can see it; RPKI is the step that can turn the block off inside networks you will never talk to, and a missing route object can be just as hard a stop at an upstream that builds its prefix filters from the IRR. Create ROAs for exactly the prefixes you will announce, from the origin AS that will announce them, before the first announcement leaves. Of the three registries this post covers, none mandates that order, but all three put ROA creation on the buyer at completion, and RIPE NCC notes that for space arriving in its region it issues the new certificate within a few minutes when the resources are certifiable, so there is rarely a reason to wait. A route that enters the table already Valid never spends a day being dropped by validating networks, and what happens when a prefix goes RPKI invalid is the post to read if you want the failure spelled out. Check your work with RIPEstat's RPKI validation lookup: your prefix plus your origin AS should return Valid. An invalid_asn answer means a ROA still authorises somebody else's network, and unknown means no ROA covers the route yet.
Second: route objects, created and flushed
The IRR needs the same two motions, creation and cleanup: create your own route object, and find out what stale paper still covers the space. The registries only clean their own databases. RIPE deletes the database objects when space leaves its region, and APNIC deletes route, domain and sub assignment objects on outbound inter RIR transfers, but objects in RADB, ALTDB or another third party registry, and proxy objects an old upstream registered on the seller's behalf, survive the transfer until somebody deletes them or a validator suppresses them. Enumerate everything with IRR explorer at irrexplorer.nlnog.net, which shows route objects across the IRR databases beside the ROAs, their validation status, and what the routing table actually carries for the prefix.
Your new ROA does cleanup work here too, on a delay. Since January 2020, RIPE NCC deletes RIPE-NONAUTH route objects that stay in conflict with a published ROA for 14 consecutive days, after notifying the object's contacts. RADb refuses to create route objects that are RPKI Invalid and suppresses existing ones from query output. So stale objects in RIPE-NONAUTH and RADb that contradict your ROA age out or drop from view within weeks; objects in registries that do no RPKI filtering, ALTDB among them, stay put whoever they conflict with, and those you chase by hand along with the ones no ROA contradicts. IRR route objects explained covers the mechanics of the objects themselves.
Third: contacts, assignments and the registry's own rules
The registry record now names you, so the contact chain hanging off it has to reach you. The shapes differ by registry. At ARIN you maintain the Org ID and its point of contact records, and ARIN validates Tech, Admin, NOC and Abuse POCs annually, with 60 days to confirm before a POC is flagged invalid. At RIPE the block cannot sit in the database without a working abuse-c chain, and since 2019 RIPE NCC validates abuse mailboxes at least annually, so an inherited dead address will surface on its own. At APNIC the abuse mechanism is the IRT object that every network object must reference. Once you carve the space up for customers, the registration duties start: ARIN requires reassignments of a /29 or more to be registered and visible within seven calendar days, and RIPE requires assignments in the database, with a single AGGREGATED-BY-LIR object standing in for many same purpose assignments since proposal 2023-04 was implemented in 2024. SWIP and reassignment records covers why those entries matter downstream.
Two more pieces of registry reality belong in the plan. If a different AS will announce the space, expect the upstream to ask for a letter of authorization; that is provider practice rather than registry rule, and carriers increasingly verify the IRR and RPKI records alongside the letter. And completion is not the registry's last look: of the three registries examined here, none schedules a recurring needs recheck, but ARIN keeps a standing right to review any holder's utilization without cause, at most once every two years, and RIPE region space carries a 24 month holding period before it can be transferred again.
Fourth: reverse DNS and the geofeed
Reverse DNS comes before the first mail leaves the range, because large receivers check it: Gmail's sender guidelines require the sending address to have a PTR record whose hostname resolves back to the same address. At RIPE, delegation means creating a domain object carrying your nameservers, authorised against the covering block's maintainer, with broken setups rejected by RIPE's DNS checks and up to a day before the delegation is live. At ARIN you set nameservers per delegation in ARIN Online or through its API. Remember that on an inter RIR move the old delegation was deleted at completion, so there is a gap to close, not just a record to update. Reverse DNS for a subnet walks through the zone mechanics.
Geolocation is the same publish then wait pattern with less certainty. Publish an RFC 8805 geofeed, a plain CSV of prefix, country, region, city and an optional postal code, in which only the prefix column is mandatory, and point the registry at it per RFC 9632: RIPE and APNIC both support a geofeed attribute on the network object, while at ARIN the practice as of late August 2026 is still a Geofeed URL line in the public comments, with the RDAP extension standardised as RFC 9877 in October 2025 but not yet shipped there. Provider intake varies and mostly refuses day counts: MaxMind documents that it consumes geofeeds and reviews them each business day with changes landing in the next database release, IPinfo publishes no turnaround, and Google's correction form warns that updates may take more than a month. Treat any firmer timeline you hear as folklore, and read why geolocation stays wrong after a transfer before promising dates to anyone.
Announce, verify, and read the block back
Now announce, and verify from outside your own network. RIPEstat's routing status shows what the RIS collectors see, and RouteViews at the University of Oregon gives an independent set of vantage points. What verification will not show is a clean slate, because nothing in a transfer resets reputation: newly bought ranges arrive already blocklisted often enough that it should be assumed, not discovered. On the Spamhaus side, know which kind of listing you are looking at before escalating: automated CSS listings normally expire about three days after the last detection, while investigator issued SBL records sit until the network owner reports the change and requests removal. Spamhaus handles hijack related records with extra suspicion: removal requests are only accepted from the registered owner, removals are entirely at its discretion, and a buyer of space with a hijack in its history should expect to prove a legitimate chain of custody before any delisting conversation moves.
Finally, read the block back the way a stranger will. Look it up on the front page: the Type and Status rows print the registry's current strings for the block, and the Organisation row names the holder, so you can see whether the record now describes you; the abuse contact the report resolves should be an address you control, and since the report resolves the contact upward through the registry hierarchy, an old upstream's address there means the chain still points at somebody else. Once the announcement is out and the RIS collectors have seen it, the origin history grows a new row with your AS and a fresh first seen date, sitting at the top of the table with the block's whole past beneath it, and reading a prefix's routing history is the guide to what that past will say about you. The tag vocabulary has a name for the failure state this checklist exists to prevent: stale-registration, records still describing the seller months after the money moved.
Run the block through the front page twice: once before you announce, to see what gatekeepers will see, from the registry strings to the routing record the space carries from its past life, and once after the cleanup, to confirm the report reads back as yours: your holder on the block, an abuse contact you control, your AS in the origin history with a fresh first seen date. The gap between those two reports is this checklist.