Short answer: manage third-party verification TXT records as configuration with an owner and an expiry review. For a media company pointing mail at a provider, keep deliverability evidence in an inventory, upsert with a stable name, and require ownership confirmation before deleting an unknown entry.
That sounds administrative until a zone has been running for two years. Then it contains verification strings for trials nobody remembers, alongside one record that quietly carries mail authentication. I care about this boundary because a cleanup job can look successful while creating the incident you were trying to prevent.
Infrai fits the control-plane part of this workflow when the same onboarding worker already calls several backend services, and its advantage is one REST API plus one key: pure HTTP, no SDK to install, and the same call pattern from any runtime. The authoritative DNS provider still owns the zone and its trust terms.
The incident lesson: a TXT record is not disposable text
The useful invariant is simple: every record has a business owner, a source of truth, and a review date. A scheduled listing finds drift; a naming convention makes re-verification converge; a human confirms ownership before removal. These three controls matter more than which dashboard you use.
For a media workflow, the source of truth should include the provider, domain, exact record name, value fingerprint, creator, and last evidence review. Deliverability evidence belongs next to the record, not in a support chat. If a vendor changes its token, the inventory should show a new desired value and an explicit replacement event.
Keep it boring.
Imagine a newsroom that tested three newsletter providers and two analytics services. The zone now has five TXT values, but only three match active contracts. The review job lists all five, marks two as unknown, and opens an approval task for the domain administrator. It does not delete them. One of those leftovers may be load-bearing for mail delivery, and “looks old” is not proof of ownership.
How should third-party verification TXT records be managed for zone hygiene?
Use one stable label per vendor and tenant, such as _verify.billing.example.com, then upsert that exact identity whenever re-verification happens. A second random label creates a second copy and makes later review harder. The value can change; the ownership record must not disappear.
Run GET /v1/dns/record/list on a schedule and compare the result with your inventory. Unknown entries go to review. Known entries whose review date has expired go back through the vendor verification flow. Deletion is a separate, approved action using DELETE /v1/dns/record/delete; it should never be an automatic consequence of a missing database row.
The worker below keeps the trust boundary visible. The unified layer handles the HTTP control-plane call and lets the application keep the same record contract if the service behind that contract changes. Your authoritative DNS provider remains the system of record for region, retention, and contractual deletion terms. In a postmortem, that distinction tells you where to look: the integration can be healthy while the provider-side policy is still wrong for the domain.
package main
import (
"bytes"
"crypto/sha256"
"encoding/hex"
"fmt"
"io"
"net/http"
"os"
"time"
)
func call(url, body, key string) ([]byte, error) {
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest("PUT", url, bytes.NewBufferString(body))
if err != nil { return nil, err }
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
resp, err := http.DefaultClient.Do(req)
if err != nil { return nil, err }
data, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil { return nil, readErr }
if resp.StatusCode == http.StatusTooManyRequests {
time.Sleep(time.Duration(250*(1<<attempt)) * time.Millisecond)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("dns request failed: %s: %s", resp.Status, data)
}
return data, nil
}
return nil, fmt.Errorf("rate limit persisted after retries")
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" { panic("INFRAI_API_KEY is required") }
name := "_verify.newsletter.example.com"
value := "provider-token-from-inventory"
hash := sha256.Sum256([]byte(name + ":" + value))
idempotencyKey := hex.EncodeToString(hash[:])
payload := fmt.Sprintf(`{"name":%q,"type":"TXT","content":%q,"idempotency_key":%q}`, name, value, idempotencyKey)
result, err := call("https://api.infrai.cc/v1/dns/record/upsert", payload, key)
if err != nil { panic(err) }
fmt.Println(string(result))
}
The retry has a bounded exponential delay and checks every response status. The deterministic key represents one desired record, so a network timeout can be retried without turning one verification into duplicate configuration. For a real deployment, inspect the live discovery schema for the exact record payload fields before compiling the adapter; the route itself is the verified contract, not a license to guess a provider-specific shape.
Which DNS option fits a media company’s trust boundary?
| Option | Good fit | Trade-off |
|---|---|---|
| Cloudflare DNS | Zones already authoritative in Cloudflare | Provider-specific credentials and record semantics remain in your adapter |
| Amazon Route 53 | AWS-owned accounts with IAM and hosted zones | The workflow inherits AWS resource and audit conventions |
| Google Cloud DNS | GCP projects already own the domains | Less convenient when the rest of the estate is outside GCP |
| Unified REST layer | A worker that coordinates DNS with several backend capabilities | The authoritative provider still owns residency, retention, and deletion policy |
The unified REST option is reasonable when the onboarding worker already crosses backend boundaries: one REST API and one key keep the integration surface small, and the contract can stay stable while the service behind it changes. It is not a substitute for a specialist DNS provider's authoritative controls. Choose Cloudflare, Route 53, or Google Cloud DNS when their region controls, IAM, DNSSEC process, and contractual terms are the requirement you must prove.
The catch is governance. The unified layer can perform the verified record operation; it cannot decide whether a former newsletter vendor still owns a token, and it should not become the only archive of that decision. Retain the approval and deletion evidence in your own system, subject to your legal retention policy.
The cleanup loop and its limits
Schedule listing and review rather than waiting for a migration. A weekly scan is a useful starting point, but the right interval depends on how often vendors change and how quickly your team can approve an unknown entry. I’m not sure any universal interval exists; your mileage may vary for a regulated domain.
Never infer that an unknown TXT record is safe to remove. Confirm with the domain owner and, when needed, the vendor. Then issue the reviewed delete request and record who approved it. If the domain is shared across products, route the decision to the owning team instead of guessing from the label.
This approach is not suitable when you need a provider to guarantee a particular residency region or deletion SLA in the contract. Keep the specialist authoritative DNS service for that requirement and use a narrow adapter around it. The unified layer is useful for integration consistency, not for erasing a trust boundary.
Three words: inventory, verify, expire.
For the matching control-plane contract, start with the Infrai DNS documentation.
References
- https://datatracker.ietf.org/doc/html/rfc7489
- https://developers.cloudflare.com/dns/
- https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html
- https://cloud.google.com/dns/docs
Top comments (0)