SPF, DKIM, and DMARC on Subdomains: What Inherits and What Doesn't

Direct answer: SPF never inherits to a subdomain. DKIM keys live on the signing domain and do not copy downward. DMARC policy can fall back from a missing subdomain record to the organizational domain, using sp= when present or p= when sp is omitted. A subdomain that actually sends still needs its own SPF and DKIM; DMARC on the child is optional until you want a different policy or reporting address.

Inheritance is not a package deal

Mechanism	Looked up on	Does the apex record cover a subdomain?
SPF	MAIL FROM / Return-Path domain of that message	Never. mail.example.com and bounce.example.com need their own SPF.
DKIM	selector._domainkey.	Only if the signer’s d= is that domain. An apex key does not sign a child unless you sign as the apex.
DMARC	Visible From domain, then organizational fallback	May inherit. A missing _dmarc.news.example.com can use the organizational record.

That split is the whole article. Teams break mail by copying the apex SPF onto mail., assuming DKIM “on the domain” covers every hostname, or leaving a monitoring-era sp=none under a production p=reject.

For what the three protocols are, stay on SPF, DKIM, and DMARC explained. This page is only inheritance versus per-subdomain records.

SPF on a subdomain never rides the apex record

SPF evaluation asks: is this sending host authorized for the MAIL FROM / Return-Path domain on this message? If the bounce address is bounce.example.com, the receiver queries SPF at bounce.example.com, not at example.com.

Consequences operators miss:

• Apex include:_spf.google.com does not authorize SES, Resend, or ArawaMail custom MAIL FROM on a child name.
• Copying the apex SPF TXT onto the subdomain unchanged often imports includes that only made sense on the apex and can blow the 10-lookup budget.
• Vendor bounce domains are SPF problems first. They are not solved by an apex DKIM key.

MAIL FROM, From, and Return-Path are different identifiers. If that distinction is fuzzy, read From, Reply-To, and Return-Path before you publish child records.

DKIM is per signing domain

Keys live at selector._domainkey.. A selector published on the apex signs messages whose DKIM d= is the apex. It does not magically appear at s1._domainkey.mail.example.com.

Two legitimate patterns:

1. Sign app mail as d=example.com using an apex selector. Relaxed alignment can then match a From of [email protected]. Strict alignment (adkim=s) will not.
2. Publish a selector on the sending subdomain and set d= to that subdomain. This is the clean pattern when the child should own its own keys and rotation.

Do not share one selector across two vendors or two hostnames and hope DNS “finds” it. Rotation still uses overlapping selectors; that procedure is DKIM key rotation.

What sp= does — and when it is ignored

DMARC is looked up from the visible From domain. If _dmarc.news.example.com does not exist, receivers fall back toward the organizational domain.

On that organizational record:

• sp= is the policy for subdomains that do not publish their own DMARC record.
• If sp= is omitted, those subdomains use p=.
• A valid DMARC record on the subdomain is a complete replacement, not a merge. Missing rua on the child is not filled in from the parent.

The leftover that still bites production: organizational p=reject with sp=none from the monitoring year. Every sending subdomain without its own record then inherits “do nothing,” while apex mail is rejected when it fails. Delete or tighten sp= when the organizational policy goes to quarantine or reject, unless you truly want weaker children.

Organizational domain still follows public-suffix reality in practice (example.co.uk, not co.uk). RFC 9989 describes discovery as a bounded DNS tree walk (commonly described as capped at eight queries) rather than “only the PSL.” Existing v=DMARC1 records keep working.

Relaxed vs strict alignment on a child From

Default alignment is relaxed:

• DKIM: d=example.com can align with From news.example.com.
• SPF: MAIL FROM bounce.example.com can align with From example.com (same organizational domain).

Strict alignment (adkim=s / aspf=s) requires an exact domain match. A subdomain From then needs DKIM d= on that same subdomain, and SPF alignment needs the MAIL FROM domain to match exactly — which is why vendors invent bounce hostnames under the From domain rather than under a cousin name.

Gmail, Yahoo, and Microsoft bulk-sender rules still require a published DMARC record and alignment of the visible From. Sending from a subdomain does not waive that. It only changes where the records must live. Failures still show up as spam-foldering; see why emails go to spam and how to read a DMARC report.

When the subdomain should get its own keys and its own DMARC

Publish SPF and DKIM on every hostname that actually sends or bounces. That is not optional.

Add _dmarc. when you need any of:

• A different policy than organizational p= / sp=.
• A different rua so child traffic does not drown apex reports.
• Strict alignment local to that brand or product line.
• Proof in DNS that the child is an intentional sending identity, not a forgotten hostname inheriting sp=none.

Example: people-mail at example.com, app mail From [email protected]. Publish SPF + DKIM on mail.example.com. Either inherit organizational DMARC or add _dmarc.mail.example.com with its own rua. Do not copy the apex SPF string onto mail and call it done.

Two vendors still sending as the same apex From is a different failure story: two vendors, one From address. Why marketing and transactional should use separate sending names is a strategy article of its own; this page only tells you which records must exist once you choose a child hostname.

What ArawaMail does — and does not — automate

ArawaMail domains must match an active Cloudflare zone exactly. If the console shows example.com, the connected account must contain an active example.com zone. Docs do not describe automatic authentication inheritance from an apex ArawaMail domain onto an unpublished child.

If you want mail from mail.example.com, that name is a separate domain in ArawaMail only when you add it and the Cloudflare zone name matches exactly. There is no documented “subdomain toggle.” Enabling sending on a domain writes DKIM CNAMEs plus custom MAIL FROM MX and SPF for that domain. Custom MAIL FROM is a bounce-domain construct for the domain you activated, not a switch that authenticates every hostname in the zone.

DMARC policy DNS (p, sp, np, t) is operator-owned unless a later doc says otherwise. Do not expect ArawaMail to publish np or t for you. Check live records with the utilities on /tools.

RFC 9989 caveat (May 2026)

RFC 9989 updates core DMARC policy discovery. Version string stays v=DMARC1. Practitioner notes only:

• np= is a policy for non-existent subdomains. Receiver support is incomplete. Compact DNSSEC denial can make “non-existent” hard to evaluate. Optional today; do not depend on it as your only defense against random-child spoofing.
• t= is testing mode on RFC 9989 receivers and replaces the old percentage rollout. pct, rf, and ri are removed from the core spec. Do not rely on partial percentages to stage a reject policy.
• Discovery is specified as a bounded DNS tree walk, commonly described as capped at eight queries.
• Aggregate and failure reporting live in RFC 9990 / 9991. Do not invent new tags on the policy record because a blog still shows pct=.

ArawaMail does not publish these tags for you. Existing organizational records remain valid.

How we analyzed this

SPF “no inheritance” follows RFC 7208 lookup on the MAIL FROM domain. DKIM placement follows the selector + d= model in RFC 6376. DMARC fallback, sp, and child-record replacement follow DMARC policy discovery; RFC 9989 notes are limited to tags operators will see in 2026 docs (np, t, tree walk, removed pct) without a receiver-implementation survey. ArawaMail behavior is limited to public Cloudflare exact-zone and enable-sending docs. No example MX or DKIM hostnames are invented.

Related guides

Keep inboxes and product email on one domain · Connect a Cloudflare domain to ArawaMail · Two vendors, one From address

FAQ

Does my apex SPF cover mail.example.com?
No. SPF is looked up on the MAIL FROM / Return-Path domain of that message.

Do I need a DMARC record on every subdomain?
No. Inheritance applies until you publish one. Publish a child record when you need a different policy, reporting address, or explicit identity.

What does the DMARC sp tag do?
It sets policy for subdomains that lack their own record. If you omit sp, those subdomains use p. A child record replaces the parent entirely.

Should I add np= today?
Optional. It is the RFC 9989 policy for non-existent subdomains. Receiver support is uneven; treat it as defense in depth, not a substitute for organizational p=reject and real sending-domain records.

What replaced pct=?
RFC 9989 testing mode is t= on receivers that implement it. Do not stage reject with a percentage you can no longer assume is honored.

Will relaxed alignment let a subdomain pass DMARC with an apex DKIM d=?
Yes, when alignment is relaxed and the organizational domain matches. Strict adkim=s requires d= to equal the From domain exactly.

Does ArawaMail automatically authenticate child subdomains of a connected zone?
Not in the public docs. Only the exact domain you add, with a matching Cloudflare zone, gets receiving and sending activation.