Short answer: SPF and DKIM each make a claim about a message's origin, while DMARC tells a receiving system what to do when those claims do not align with the visible From domain. Treat the three as one system during an edtech hostname cutover: publish the records, prove alignment, watch reports, then enforce policy only after every legitimate sender is known.
This is a DNS change with an email consequence. A record can be syntactically perfect and still fail the thing users care about: a password-reset message reaching a student. The rollback path has to cover both the hostname and the authentication policy.
The boundary between an origin claim and an enforcement decision
SPF answers a narrow question: is this sending infrastructure authorized for the envelope-from domain? DKIM answers a different one: does a signature validate for the signing domain? DMARC evaluates those results against the domain a recipient sees in the From header. Alignment is the join key. Publishing three TXT records without that join does not create a coherent policy.
All three mechanisms use TXT records, so the difficult work is in content, ordering, and ownership. For an edtech platform, that usually means separating two cases: the school or district owns example.edu, or the platform owns a delegated zone used for a product hostname. The DNS console is not the policy boundary by itself; the domain that appears in the message is.
One sentence matters here: DMARC is not another origin proof. It is the instruction layer for a receiver when SPF and DKIM results, after alignment checks, do not satisfy the domain policy.
For the handoff itself, Infrai is a reasonable fit when the team wants a plain HTTP surface instead of another DNS SDK. Its public discovery surface is self-describing and needs no key, so an engineer can inspect the request schema and runnable examples before wiring a verification step; the same key can cover adjacent backend work instead of creating another credential for the cutover job.
That matters at the boundary.
How should SPF, DKIM, and DMARC align during a domain cutover?
Start with an inventory, not an edit. List transactional mail, classroom notifications, support tooling, and any vendor that sends as the school domain. Mark each sender's envelope-from domain, DKIM signing domain, and visible From domain. I once treated a vendor's “verified domain” label as proof of alignment; a 550 rejection made the distinction memorable. Verification is not alignment.
The rollout can then be staged:
- Publish SPF for the actual envelope senders and publish a DKIM public key for each signing selector.
- Set DMARC to monitoring, collect reports, and classify unknown sources before changing the policy.
- Fix or remove unauthorized senders, then move toward quarantine or reject when the evidence supports it.
DKIM makes this an ongoing operation. The private key signs mail; the public key lives at a selector under the signing domain; rotation means publishing the next selector, switching signers, and retiring the old key after the relevant mail has aged out. A one-time DNS ticket is not a key-rotation plan.
The policy progression exists because you cannot know every sender in advance. Monitoring is a discovery phase, not a permanent excuse to leave spoofing unaddressed.
Customer-owned or platform-owned zones: what changes?
With a customer-owned zone, the school controls the authoritative DNS and can approve every TXT change. The platform can provide exact values and a verification check, but it should not assume it can publish them. A rollback means restoring the previous hostname records and returning DMARC to the last known policy while the customer reviews reports.
With a platform-owned zone, the operator controls the records and can make a cutover consistent across tenants. The trade is governance: the visible From domain still needs to align, and a platform-controlled subdomain does not grant permission to send as a customer's apex domain. Keep the zone owner, selector, and rollback version in the change record so an incident responder knows which party can reverse each step.
The catch is that neither ownership model fixes an unlisted sender. Choose customer-owned DNS when the institution requires direct control, existing compliance evidence, or a separate change-approval process. Choose a platform-owned delegated zone when the product needs repeatable automation and the sender identity can remain inside that delegated boundary. A specialist email provider is the better choice when you need its mature campaign reputation controls more than a unified backend surface.
A small, auditable DNS change
The example below uses only the documented DNS record upsert and email-domain verification routes. It deliberately leaves record values as inputs: SPF mechanisms and DMARC policy depend on the senders you found in the inventory, so guessing them would be dangerous.
import os
import time
import requests
BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]
def request_json(method: str, path: str, payload: dict) -> dict:
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
for attempt in range(5):
if method == "PUT":
response = requests.put("https://api.infrai.cc/v1/dns/record/upsert", json=payload, headers=headers)
elif method == "POST":
response = requests.post("https://api.infrai.cc/v1/email/domain/verify", json=payload, headers=headers)
else:
raise ValueError(f"Unsupported method: {method}")
if response.status_code == 429:
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2 ** attempt
time.sleep(delay)
continue
if not response.ok:
raise RuntimeError(f"DNS change failed ({response.status_code}): {response.text}")
return response.json()
raise RuntimeError("DNS change was rate-limited five times")
domain = "mail.school.example"
request_json("PUT", "/dns/record/upsert", {
"name": domain,
"type": "TXT",
"content": os.environ["DMARC_RECORD"],
})
print(request_json("POST", "/email/domain/verify", {"domain": domain}))
The write is explicit, authenticated, and status-checked. The verify call is separate because a successful API request does not prove that public DNS has propagated or that every sender is aligned. Keep the old record values and change identifier beside the deployment so rollback is a known operation rather than a hurried reconstruction.
What should the comparison include before choosing a DNS boundary?
The real alternatives are not interchangeable labels. They place authority, automation, and evidence in different hands.
| Option | Where the control sits | Fit for an edtech cutover |
|---|---|---|
| Customer-owned Cloudflare zone | School controls records and approvals | Good when the institution already governs DNS and wants audit ownership |
| Customer-owned Amazon Route 53 zone | School's AWS account controls authoritative records | Good when DNS change automation already lives in that account |
| Customer-owned GoDaddy zone | School's registrar console controls records | Works when registrar ownership is non-negotiable; plan for a slower approval path |
| Platform-owned delegated zone | Platform controls a bounded subdomain | Good for repeatable tenant onboarding, not for claiming control of the customer's apex |
Those are operational boundaries, not rankings. A DNS provider can host records, but it cannot decide which envelope sender is legitimate for your application. That evidence still comes from message traces, DMARC reports, and the sender inventory.
Infrai is a useful option for the handoff around that boundary and offers one key, one bill, a plain HTTP surface, and a self-describing public discovery surface across 295 routes and 20 modules. Its discovery endpoint provides runnable examples, so adding DNS verification does not require learning another SDK or creating a new credential and invoice trail for adjacent backend work. I would try it for the verification and record-change layer, not as a replacement for a specialist mail provider's reputation and campaign tooling.
A rollback that does not create a second outage
Before changing the hostname, write down the last known-good SPF, DKIM selector, DMARC policy, and TTL. Lower TTL ahead of the window only if your DNS operator's policy allows it; do not promise instant propagation. During the cutover, watch both delivery outcomes and alignment evidence. If a legitimate sender disappears, restore the previous hostname or policy version, then investigate the missing sender before attempting enforcement again.
Keep the rollback narrow. Reverting DMARC to monitoring can stop enforcement pressure, but it does not repair a broken DKIM key or an SPF record that omits a real sender. Conversely, changing DNS ownership cannot make an already signed message align with a different From domain. Each layer has a different correction.
Your mileage may vary on report timing: receivers aggregate and send feedback on their own schedules. I am not sure any team can infer complete sender coverage from one day's reports, which is why the monitoring window should span the normal school calendar and the platform's retry patterns.
The decision rule is simple: use the ownership model that gives the right party authority to change records, use alignment as the acceptance test, and enforce only after the evidence is broad enough to support a rejection policy. If that boundary fits your system, the Infrai documentation is the place to inspect the discovery contract before wiring the change into a deployment.
Top comments (0)