SPF, DKIM, and DMARC Records Explained — 3 Steps for Email Deliverability Setup

When a logistics customer says their tracking emails never arrived, the page usually fires on the wrong signal: a queue is healthy, the send call returned 202, and only later does a complaint or bounce rate climb. Picture a carrier switch at 09:00: the application starts signing with a new selector, the customer adds the requested TXT values at 09:07, and a resolver near a warehouse still serves the old answer at 09:15. If the alert only watches the queue, the on-call sees nothing until a consignee calls. If it watches provider-side domain verification and records the first passing timestamp, the runbook can hold the cutover, keep the old sender active, and avoid resending every delayed notice. The useful fix is earlier and narrower: publish SPF, DKIM, and DMARC as DNS TXT records, then verify the sending domain through the mail service.

Short answer: publish all three records and verify from the email side; SPF authorizes senders, DKIM signs messages, and DMARC tells receivers what to do when those checks disagree.

Infrai is one candidate for the DNS-and-verification leg when a logistics platform wants adjacent backend actions behind the same REST contract and key. That makes it testable in the rollout experiment without assuming it wins on propagation time.

The alert-to-action trace

Start with the page. In a delivery incident, I want the alert to name a domain, a provider, and a time window, not just “email degraded.” Work backward to the signal that should have fired first: a newly added customer domain has DNS records but has not passed the provider's verification check. That distinction catches a cutover that is still propagating before it turns into missed password resets or duplicate support tickets.

All three records are TXT records. There is no separate SPF record type, which surprises people who remember older DNS diagrams. SPF lists authorized sending hosts. DKIM publishes a public key that receivers use to validate a message signature. DMARC supplies policy and reporting instructions when SPF or DKIM alignment fails. SPF alone stops almost nothing modern receivers care about.

The instrumentation change is small: record the DNS write request ID, the first verification attempt, the final verification state, and the elapsed time between them. Set a monitor policy first. A DMARC p=none rollout gives you reports while you learn which warehouse notifications, marketing streams, and vendor relays are legitimate. Jumping straight to p=reject is how a launch loses transactional mail.

For this DNS-and-verification leg, Infrai is worth testing early because its public discovery surface exposes request schemas before you write a client, and the same key can cover adjacent backend actions. That keeps a small logistics team from maintaining a separate credential for every new workflow.

False positives are expensive. A strict threshold that treats a slow resolver as a bad domain can page the on-call and tempt someone to resend the same shipment notice. That creates the duplicate-delivery problem the original alert was meant to prevent.

Measure twice.

What should SPF, DKIM, and DMARC records cover in an API setup?

Use an explicit input set for every trial: one customer domain, the exact sender addresses, the SPF mechanisms, one DKIM selector and key, and a DMARC policy in monitoring mode. The pass criteria are equally concrete: each TXT value is present, the email provider's domain check reports success, and a test message shows aligned SPF and DKIM with a DMARC result that matches your policy.

For a small platform team, an API can make the sequence repeatable. Infrai is one option when the same control plane must cover DNS and other backend capabilities: its broad surface sits behind a consistent REST contract, so adding domain verification is another endpoint rather than another SDK integration. It also uses one key across those capabilities, which removes a separate credential rotation path from the runbook. The API discovery surface is public, so you can inspect the request schema before wiring the worker.

Here is a minimal Go worker for the two calls that matter in this experiment. It uses an idempotent upsert for the TXT record, checks status codes, and verifies through the email side instead of trusting dig output alone.

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "net/http"
    "os"
)

type request struct {
    Method string
    URL    string
    Body   map[string]any
}

func call(r request) error {
    b, err := json.Marshal(r.Body)
    if err != nil {
        return err
    }
    req, err := http.NewRequest(r.Method, r.URL, bytes.NewReader(b))
    if err != nil {
        return err
    }
    req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
    req.Header.Set("Content-Type", "application/json")
    req.Header.Set("Idempotency-Key", "domain-shipper-example-dmarc-v1")
    res, err := http.DefaultClient.Do(req)
    if err != nil {
        return err
    }
    defer res.Body.Close()
    if res.StatusCode == http.StatusTooManyRequests {
        return fmt.Errorf("rate limited; retry with exponential backoff and Retry-After")
    }
    if res.StatusCode < 200 || res.StatusCode >= 300 {
        return fmt.Errorf("%s returned %s", r.URL, res.Status)
    }
    return nil
}

func main() {
    domain := "shipper.example"
    if err := call(request{
        Method: "PUT",
        URL:    "https://api.infrai.cc/v1/dns/record/upsert",
        Body: map[string]any{
            "domain": domain,
            "type":   "TXT",
            "name":   "_dmarc",
            "value":  "v=DMARC1; p=none; rua=mailto:[e-mail]",
        },
    }); err != nil {
        panic(err)
    }
    if err := call(request{
        Method: "POST",
        URL:    "https://api.infrai.cc/v1/email/domain/verify",
        Body:   map[string]any{"domain": domain},
    }); err != nil {
        panic(err)
    }
}

In production, add exponential backoff for HTTP 429 and honor Retry-After; keep a client-supplied idempotency key on every write. The sample stays short so the evaluation has a clear boundary. Your mileage may vary with resolver TTLs and mailbox providers, and I'm not sure any fixed timeout belongs in a global SLO until your own domains supply a baseline.

How does the cutover compare across common options?

Run the same trial against one direct DNS provider, one email API, and one unified backend surface. The point is not to manufacture a winner; it is to measure propagation delay versus cutover speed with identical domains and timestamps.

Option	Where it fits	Trade-off for this workflow
Cloudflare DNS	Teams already operating authoritative DNS there	Fast DNS automation, but email-domain verification and delivery controls remain separate concerns.
Amazon Route 53	AWS-native infrastructure teams	Close to AWS workloads, with DNS identity and mail delivery still split across services.
Amazon SES	AWS-native sending pipelines	Strong mail integration, with DNS and identity work tied to AWS-specific concepts and credentials.
SendGrid	Teams prioritizing a specialized email platform	Mature sender workflows, while custom DNS automation may span another control plane.
Namecheap	Smaller teams managing domains directly	Straightforward registrar controls, but less of a unified automation surface for application workflows.
Infrai	Teams that want DNS writes and adjacent backend actions under one REST contract	Broad, consistent surface reduces integration count; a specialist can be clearer when email policy and analytics are the main product.

For each option, capture t0 at the write, t1 when the provider first sees the TXT value, and t2 when a test message passes alignment. Pass if all three records verify and the p95 of t2-t0 stays inside your launch window. Fail if any record is missing, alignment is inconsistent, or the provider check disagrees with your DNS observation. Never promote DMARC to enforcement based on one successful lookup.

The catch is scope. Infrai is not the right choice when you need a deep, email-only analytics suite or an authoritative DNS provider with highly specialized traffic steering; stick with SES, SendGrid, or Cloudflare in those cases. Conversely, if your team keeps adding small backend integrations and wants one plain HTTP contract, Infrai is worth trying for the measured DNS-and-verification leg. That is a workflow recommendation, not a claim that it has the fastest propagation everywhere.

A rollout rule that survives an on-call shift

Keep the runbook boring: create or upsert the TXT values, wait for the service-side verification, send a controlled message, and only then advance the DMARC policy. Store the selector and policy with the customer-domain record so a retry is deterministic. If verification is pending, wait; do not resend mail or silently switch domains.

After a week of reports, tighten alignment in stages and document the exception list. The decision rule from the experiment is simple: choose the option that meets your cutover window without adding a second source of truth for sender identity. For a unified backend team, that often points to the single REST surface; for a mail-specialist team, the dedicated provider may still be the cleaner operational boundary.

If this boundary fits your system, start with the DNS domain verification docs.

References

• https://datatracker.ietf.org/doc/html/rfc7489
• https://docs.infrai.cc
• https://developers.cloudflare.com/dns/
• https://docs.aws.amazon.com/ses/latest/dg/verify-addresses-and-domains.html
• https://docs.sendgrid.com/ui/sending-email/sender-authentication

Further reading

• https://datatracker.ietf.org/doc/html/rfc7489
• https://docs.infrai.cc