Moving senders off the apex

After this lesson you can

Restructure an over-budget estate so each platform sends from its own subdomain.

Assumes you have read Counting, with the working shown.

The best answer to an over-budget record is usually not a clever encoding. It is noticing that eight platforms are competing for one domain’s ten lookups when they did not need to share a domain at all.

One budget per domain

The ten-lookup limit applies per evaluation, and an evaluation is scoped to the domain in the envelope sender. Move a platform onto its own subdomain and it gets its own ten.

before
  acme.com   v=spf1 include:A include:B include:C include:D
                    include:E include:F include:G include:H ~all
             8 includes competing for one budget

after
  acme.com        v=spf1 include:A include:B ~all          corporate mail
  mkt.acme.com    v=spf1 include:C ~all                    marketing platform
  txn.acme.com    v=spf1 include:D ~all                    transactional
  help.acme.com   v=spf1 include:E ~all                    support desk
             each with its own budget, and headroom everywhere

What has to change

SPF is evaluated against the envelope sender, so the platform must be configured to bounce from the subdomain. That is the same custom return-path setting you will meet in module 6, and it is the only change required — the visible From address can stay @acme.com.

	Envelope sender	Header From	Recipient sees
Before	bounce@platform.example	@acme.com	no change
After	bounce@mkt.acme.com	@acme.com	no change

Two things you get for free

Alignment. Under relaxed DMARC alignment, mkt.acme.com shares an organisational domain with acme.com, so the envelope now aligns where a vendor domain never could.

Legible reports. Aggregate reports arrive split by subdomain, so "marketing is failing" is something you can read directly instead of inferring from source addresses.

What it costs

Reputation is per-domain. Splitting is usually good — a marketing campaign can no longer damage transactional delivery — and it does mean each subdomain builds its own reputation from nothing. Expect a settling period.
More records to maintain. Each subdomain needs its own SPF, and its own DKIM if the platform signs.
DMARC needs thinking about. Subdomains inherit p= unless sp= says otherwise. A new sending subdomain lands under whatever policy is already in force, which is correct and worth confirming before you cut over.
The platform must support it. Most do; some charge for it; a few cannot, which is module 6.

Why this comes before flattening

Delegation removes lookups permanently and creates nothing that goes stale. Flattening removes lookups and creates a copy of someone else’s data that you must now maintain forever. Reach for delegation first; flatten only what delegation could not move.

Knowledge check

An estate is at 11 lookups across eight third-party platforms. Which remediation removes the most budget while creating the least ongoing work?

Move the highest-cost platforms onto their own sending subdomains, so each gets its own budget.
Flatten the two largest includes into literal ip4 ranges.
Change ~all to -all so receivers reject the excess.
Add a second SPF record so the terms are split across two.

Correct — Move the highest-cost platforms onto their own sending subdomains, so each gets its own budget. Delegation removes the lookups from the apex permanently and creates nothing that can go stale. It also improves alignment under relaxed mode and makes aggregate reports readable per-subdomain.

Not this — Flatten the two largest includes into literal ip4 ranges. It works today and hands you a standing obligation: those ranges are a copy of someone else’s data, they will change without notice, and the failure is silent. Reasonable after delegation, not before it.

Not this — Change ~all to -all so receivers reject the excess. The terminal qualifier has no effect on the lookup budget. At 11 lookups the record is permerror and no host passes regardless of how it ends.

Not this — Add a second SPF record so the terms are split across two. Two records beginning v=spf1 is itself a permerror. There is no defined way for a receiver to choose between them, which is why the standard forbids it.

Last reviewed 2026-09-15

Moving senders off the apex

One budget per domain

What has to change

What it costs

Why this comes before flattening

Try it on a real domain