Sending email from subdomains lets you separate different message streams without giving up your primary brand domain. To send email from subdomains reliably, you need more than a new From address: each sending identity needs a deliberate DNS, authentication, bounce-handling, and testing plan.

What it means to send from a subdomain

A subdomain is a DNS name beneath your main domain. If your company owns example.com, then notify.example.com, billing.example.com, and updates.example.com are subdomains.

When an email uses receipts@billing.example.com as its visible From address, recipients see the subdomain as part of the sender identity. That can make the purpose of the message clearer and can isolate operational mail streams from one another.

A common setup looks like this:

notify.example.com for product notifications and account alerts
receipts.example.com for invoices, payment confirmations, and order receipts
support.example.com for ticket updates and customer-service conversations
news.example.com for newsletters and promotional campaigns
status.example.com for incident notices and service-health updates

The visible From domain is only one email identity, however. A message may also have a separate SMTP envelope sender, a DKIM signing domain, a tracking domain, and a reply-to address. They can be related, but they do not automatically become the same merely because the From address uses a subdomain.

That distinction is the source of many failed subdomain launches. A team changes From: hello@example.com to From: hello@notify.example.com, then assumes existing SPF, DKIM, and DMARC records cover the new domain. Sometimes they do; often they do not, especially where strict alignment, delegated authentication, or third-party sending infrastructure is involved.

Why use sending subdomains

The main reason to use subdomains is controlled separation. A password-reset message and a weekly promotion do not have the same sending pattern, recipient expectation, complaint risk, or business importance. Sending both from the same domain makes it harder to manage those differences.

Separate message types without confusing recipients

A subdomain can communicate the nature of the mail before someone opens it. For example, security@alerts.example.com is more specific than security@example.com. That specificity can be valuable for customer trust, internal routing rules, and incident response.

It also gives engineering and marketing teams a clean naming convention. Instead of continually adding unrelated local parts such as billing-robot@, marketing-robot@, and system-robot@ to the same domain, each stream can use a stable domain boundary.

Limit the blast radius of operational mistakes

Subdomains are not a magic reputation firewall. Major mailbox providers evaluate many signals, including content, recipient engagement, authentication, IP reputation, sending behavior, and the relationship between domains. Still, separating mail streams makes it easier to identify which program is creating bounces, complaints, or authentication failures.

For example, if a marketing import creates high complaint rates, it is operationally easier to investigate news.example.com than to untangle the same campaign from critical login and receipt traffic under one shared identity. The lesson is not that a promotional subdomain can be treated carelessly; it is that each stream can have its own controls, reporting, and escalation path.

Make migrations and provider changes safer

A subdomain is also useful during an email-provider migration. You can move notifications.example.com to a new REST API or SMTP relay while other mail continues using the current provider. That narrows the scope of DNS changes and lets you compare delivery, authentication, and bounce behavior before moving every stream.

The same approach works for applications with separate environments. Production should normally use a real, authenticated production subdomain, while development and staging should use non-customer addresses or an isolated test domain. Never let a staging application accidentally send customer-facing messages from the production brand domain.

Choose a subdomain strategy before publishing DNS

Start by mapping every message type and every system that sends it. This prevents a common failure mode: several teams independently publish SPF or DKIM records for the same subdomain, then overwrite or conflict with one another later.

A practical initial inventory includes:

Message class: password reset, login verification, receipt, invoice, support reply, product alert, newsletter, or bulk campaign.
Application or sender: application server, CRM, support platform, billing system, or email service provider.
Visible From address: such as receipts@billing.example.com.
Envelope sender domain: the domain used in the SMTP MAIL FROM command and typically shown in a Return-Path header after delivery.
DKIM signing domain: the value of d= in the DKIM-Signature header.
Reply handling: a monitored mailbox, an inbound support processor, or a deliberately non-replyable address.
Expected volume and risk: low-volume transactional mail has different monitoring needs from a high-volume campaign stream.

Use purpose-based names, not provider-based names

Name a subdomain after the mail function rather than the vendor that happens to send it. notify.example.com remains meaningful if you change providers. A name such as vendorname.example.com ties your public sending identity to a tool choice and makes future migrations less tidy.

Purpose-based subdomains also make DMARC reports, message headers, and incident investigations easier to understand. Someone reviewing an authentication report should be able to infer what billing.example.com does without opening an internal architecture document.

Avoid unnecessary fragmentation

Do not create a unique subdomain for every tiny workflow. A company with reset.example.com, verify.example.com, login.example.com, 2fa.example.com, and alert.example.com may gain little over a well-governed notify.example.com stream.

Too many subdomains increase DNS maintenance, key rotation work, DMARC policy complexity, and the chance that one stream is left unauthenticated. Begin with a small set of meaningful boundaries, then split only when the operational or reputational differences justify it.

Configure the visible From address and envelope sender

Every email has a visible RFC 5322 From address, such as:

From: Example Billing <receipts@billing.example.com>

This is the identity recipients see in their mail client. It is also the domain DMARC evaluates for alignment.

The SMTP envelope sender is separate. During SMTP delivery, the sending system issues a command similar to:

MAIL FROM:<bounces+4fd91@bounce.billing.example.com>

After delivery, many recipients will show this identity in the Return-Path header. It is where non-delivery reports and some automated bounces are directed. Your sending provider may use its own default envelope domain unless you configure a custom return-path or MAIL FROM domain.

Why the envelope sender matters for SPF alignment

SPF evaluates the domain used by the SMTP envelope sender, not the visible From address. A message can pass SPF for bounce.billing.example.com while displaying receipts@billing.example.com in the From header.

For DMARC, that SPF pass contributes only if the authenticated SPF domain aligns with the visible From domain. Under relaxed alignment, a related subdomain can align; under strict alignment, the domains must match exactly. Because these rules can be subtle, many senders rely on aligned DKIM as the more durable path to DMARC compliance, particularly when a provider manages the bounce domain.

Keep recipient-facing addresses real when replies matter

A no-reply address is not a deliverability configuration. It is a product decision. If customers might reply to a billing, security, support, or account message, provide a monitored reply path or explain clearly where they should get help.

For transactional mail, a useful pattern is:

From: Example Support <support@notify.example.com>
Reply-To: help@example.com

That preserves a consistent sending identity while routing responses to the team or system that can handle them. If you use a different Reply-To domain, make sure it is intentional and tested in the mail clients your customers use.

Publish SPF for the sending subdomain

SPF is a DNS-based authorization policy for mail servers. An SPF record is published as a TXT record and begins with v=spf1. It describes which hosts or delegated policies are permitted to send mail for the domain being evaluated. SPF is standardized in RFC 7208. (datatracker.ietf.org)

If your SMTP envelope sender is bounce.billing.example.com, publish SPF for that exact domain or use an envelope domain your provider has already configured and authenticated for you. Do not assume an SPF record at example.com automatically authorizes mail from billing.example.com.

Example SPF record

Suppose your provider instructs you to authorize its SPF policy for billing.example.com. The DNS record might be:

Type: TXT
Host/Name: billing
Value: v=spf1 include:spf.email-provider.example -all
TTL: 3600

In a DNS interface that requires fully qualified names, the host may instead be entered as billing.example.com. DNS control panels differ, so verify whether the interface appends your zone automatically before saving the record.

The include: mechanism asks receivers to evaluate the referenced domain's SPF policy. The -all mechanism produces an SPF fail for senders that did not match a preceding authorized mechanism.

If you run an application server with a known fixed IPv4 address and also use a provider, the record could look like this:

Type: TXT
Host/Name: notify
Value: v=spf1 ip4:198.51.100.25 include:spf.email-provider.example -all

Use the documentation supplied by your sender for the correct include domain. Do not copy an include value from a blog post, a different account, or another vendor's setup instructions.

Publish one SPF record per name

A domain must not have multiple SPF TXT records that each begin with v=spf1. Multiple SPF records can produce an SPF permerror, which means receivers cannot reliably evaluate your policy.

This is particularly easy to break when two services both ask you to add an SPF record. Combine approved mechanisms into one record for the same hostname, instead of creating two separate v=spf1 TXT values.

Bad example:

billing.example.com TXT "v=spf1 include:spf.provider-one.example -all"
billing.example.com TXT "v=spf1 include:spf.provider-two.example -all"

Better example:

billing.example.com TXT "v=spf1 include:spf.provider-one.example include:spf.provider-two.example -all"

Only combine providers that genuinely send mail using that envelope domain. Every authorization expands the set of systems allowed to send for your domain.

Respect SPF DNS lookup limits

SPF processing has a limit of 10 DNS terms that cause lookups, including mechanisms such as include, a, mx, exists, redirect, and some ptr use. A complex chain of includes can exceed the limit and produce a permanent SPF error. (datatracker.ietf.org)

This matters when a company adds a transactional provider, a helpdesk, a payroll platform, a CRM, and an internal mail server to one shared SPF record. Using purpose-specific envelope subdomains can reduce that pressure. Each subdomain can have a smaller, clearer authorization policy.

Configure DKIM for each sending identity

DKIM adds a cryptographic signature to the message. The sending system signs selected message content with a private key, and recipients retrieve the corresponding public key from DNS. A DKIM signature identifies both a signing domain through d= and a selector through s=. (rfc-editor.org)

For a subdomain sender, aim for a DKIM signing domain that aligns with the visible From domain. If you send as receipts@billing.example.com, a DKIM signature using d=billing.example.com is straightforward under both relaxed and strict alignment.

Typical DKIM TXT record syntax

A DKIM public key is usually published at:

<selector>._domainkey.<domain>

For selector s2026 and signing domain billing.example.com, the hostname is:

s2026._domainkey.billing.example.com

A simplified DNS record can look like:

Type: TXT
Host/Name: s2026._domainkey.billing
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
TTL: 3600

The p= value is a base64-encoded public key supplied by the system that signs your mail. Do not modify, wrap manually, or truncate the value. DNS providers may display long TXT values in quoted chunks; that is normally acceptable when the resulting DNS record resolves to the same concatenated value.

Some providers use CNAME records rather than exposing a raw DKIM TXT key. A provider may give you a record similar to:

Type: CNAME
Host/Name: s2026._domainkey.billing
Value: s2026.billing.example.dkim.provider.example
TTL: 3600

Use the exact record type, hostname, and target the provider specifies. A CNAME and a TXT record are not interchangeable at the same DNS name.

Selectors make key rotation manageable

The selector is a version label, not a secret. It lets you publish a new key while old signed mail can still be verified using the previous selector.

A safe key-rotation sequence is:

Generate or request a new selector, such as s2027.
Publish s2027._domainkey.billing.example.com in DNS.
Configure the sending system to sign new messages with s2027.
Confirm recipient headers show dkim=pass for the new selector.
Keep the old key available for an appropriate overlap period.
Remove the old selector only after it is no longer needed.

Do not delete an old DKIM record before all systems have switched. A forgotten background worker, legacy SMTP application, or fallback provider may still sign with the old selector.

Do not treat provider DKIM as automatically aligned

A message can have valid DKIM and still fail DMARC alignment. For example, d=provider.example may pass cryptographic validation but does not align with From: receipts@billing.example.com.

Many transactional email platforms support custom DKIM through DNS delegation or CNAME records. Confirm the actual d= value in a delivered message, rather than assuming that publishing a record changed the signing identity. The most useful evidence is the recipient's raw headers, especially Authentication-Results and DKIM-Signature.

For implementation details in a platform that supports REST API and SMTP relay sending, consult its email API reference and setup guides, then verify the final delivered message independently.

Set up DMARC for parent domains and subdomains

DMARC tells receiving systems how to evaluate alignment between the visible From domain and authenticated SPF and DKIM identities. It also provides a reporting mechanism through aggregate report addresses. Gmail requires all senders to use SPF or DKIM, and requires bulk senders to use SPF, DKIM, and DMARC for their sending domains. (support.google.com)

A basic DMARC record is a TXT record at _dmarc.<domain>. For billing.example.com, that means:

Type: TXT
Host/Name: _dmarc.billing
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
TTL: 3600

This starts in monitoring mode with p=none. It asks receivers to generate reports without requesting quarantine or rejection of mail that fails DMARC.

Understand inherited subdomain policy

DMARC policy discovery considers the exact From domain first. If a subdomain does not publish its own DMARC record, receivers can apply policy inherited from the organizational domain. The parent-domain record can also use the sp= tag to declare a policy specifically for subdomains. (datatracker.ietf.org)

For example, this parent-domain policy requests a stricter policy for subdomains:

Type: TXT
Host/Name: _dmarc
Value: v=DMARC1; p=none; sp=quarantine; rua=mailto:dmarc-reports@example.com

That may be appropriate only after you have inventoried every legitimate sending subdomain. A broad sp=reject policy can protect against spoofing, but it can also expose forgotten systems that are sending unauthenticated mail.

Relaxed versus strict alignment

The adkim and aspf tags control DKIM and SPF alignment modes:

r means relaxed alignment.
s means strict alignment.

With relaxed alignment, related domains can align. For example, d=billing.example.com can align with From: receipts@billing.example.com. With strict alignment, the domains must match exactly.

Strict alignment can be useful where a company wants highly precise identity controls. But it increases the chance of a legitimate message failing DMARC after a provider migration, bounce-domain change, or routing adjustment. Start with a documented reason for strict mode, not a vague belief that stricter is always better.

Move from monitoring to enforcement deliberately

A practical rollout is:

Publish p=none and collect aggregate reports.
Identify every authorized sender and every unexpected source.
Fix SPF/DKIM alignment for legitimate traffic.
Move to p=quarantine with a low percentage if appropriate.
Monitor failures and forwarding behavior.
Move toward p=reject only when reports show the domain is ready.

DMARC reports can be XML files and may arrive in significant volume. Use a DMARC reporting service, parser, or internal workflow that turns them into readable source, volume, alignment, and failure data. Do not publish rua= to a mailbox that nobody monitors.

Add custom return-path and tracking domains carefully

Sending subdomains often need related infrastructure domains. These are not always the same as the visible From domain, and that is normal.

Return-path or bounce subdomain

A custom bounce domain might be:

bounce.billing.example.com

Your provider may ask you to add an MX record, a TXT verification record, a CNAME, or a combination of these. The exact values are provider-specific, so use the values generated for your account.

The purpose is typically to let the provider receive bounces for an envelope sender such as:

bounces+message-id@bounce.billing.example.com

Do not create an MX record that points to an invented hostname. If a provider supplies an MX priority and destination, reproduce both exactly. A typical DNS interface may represent the concept as:

Type: MX
Host/Name: bounce.billing
Priority: 10
Value: mx.email-provider.example

That example is illustrative only; it is not a universal provider value.

Link and open tracking subdomain

If you use click tracking, a provider may ask you to delegate a hostname such as links.news.example.com through CNAME. That allows tracked URLs to use your branded domain rather than a shared provider domain.

For example:

Type: CNAME
Host/Name: links.news
Value: tracking.provider.example

Click tracking is not required for transactional mail. In fact, removing unnecessary tracking from password resets, invoices, and security alerts can reduce complexity and make messages easier for recipients to evaluate. Use it only where you need measurable link events and where the added redirect is appropriate.

Do not put unrelated records at a CNAME name

A hostname with a CNAME generally cannot coexist with other record types such as MX or TXT at the same name. This is a DNS rule that frequently causes failed provider verification.

For example, do not publish both a CNAME for links.news.example.com and a TXT verification record at that exact hostname unless the provider explicitly supports a different verification label. Choose distinct names such as provider-verify.news.example.com when needed.

Send through SMTP or an HTTP email API

Once DNS is in place, your application can send by SMTP relay or an HTTP-based email API. The authentication model is the same from the recipient's perspective: the resulting message must have correct envelope details, headers, DKIM signatures, and domain alignment.

SMTP relay example

A generic SMTP submission flow looks like this:

EHLO app.example.com
STARTTLS
AUTH <mechanism>
MAIL FROM:<bounces+123@bounce.billing.example.com>
RCPT TO:<customer@example.net>
DATA
From: Example Billing <receipts@billing.example.com>
To: Customer <customer@example.net>
Subject: Your receipt

Thank you for your order.
.
QUIT

In production, use the submission hostname, port, TLS requirements, and authentication mechanism documented by your provider. Do not hard-code credentials into source control or client-side code. Store them in a secret manager or protected environment variables, and rotate them when access changes.

HTTP API example

The same conceptual message over an API includes a From address, recipient, subject, content, and sometimes a configured sending domain or stream identifier. A generic JSON payload might be:

{
  "from": "Example Billing <receipts@billing.example.com>",
  "to": ["customer@example.net"],
  "subject": "Your receipt",
  "text": "Thank you for your order.",
  "html": "<p>Thank you for your order.</p>"
}

The endpoint path and authentication header are vendor-specific. Follow your provider's official documentation for its API syntax, but keep the domain architecture provider-neutral: your application should know which message type maps to which approved From domain.

Interpret acceptance correctly

An API 202 Accepted response commonly means the provider accepted the request for processing. It does not necessarily mean the recipient mailbox accepted or displayed the message.

Likewise, SMTP 250 indicates successful acceptance at that stage of the SMTP conversation, not a guarantee of inbox placement. SMTP uses three-digit reply codes: 2xx indicates success, 4xx indicates a temporary failure, and 5xx indicates a permanent failure class. RFC 5321 defines the SMTP reply-code framework. (rfc-editor.org)

Examples you may see include:

250 2.0.0: message accepted by the server.
421 4.7.0: service or connection temporarily unavailable; retry according to your provider's guidance.
450 4.2.0: temporary mailbox or recipient-side issue; retry may succeed later.
550 5.1.1: recipient mailbox does not exist or is not deliverable.
550 5.7.1: policy or authentication-related rejection, depending on the receiving server's text.

Capture the full enhanced status code and server response in logs. The human-readable portion often identifies whether the issue is recipient validity, authentication, content, rate limiting, or reputation.

Verify DNS and test real delivered messages

A green verification indicator in a provider dashboard is useful, but it is not the final test. DNS can be syntactically valid while the delivered email still uses an unexpected envelope domain, DKIM signer, or From address.

Check DNS directly

Use command-line tools such as dig or nslookup to inspect public DNS:

dig +short TXT billing.example.com
dig +short TXT s2026._domainkey.billing.example.com
dig +short TXT _dmarc.billing.example.com
dig +short MX bounce.billing.example.com

You can also use DNS lookup tools from MXToolbox to inspect SPF, DKIM, DMARC, and MX records. Compare the public results with the exact records you intended to publish, including selectors, hostnames, target dots, and record type.

Remember that DNS changes are governed by TTL and resolver caching. A record can be correct at your authoritative provider while some recursive resolvers still return an older answer. Check more than one resolver if a change appears inconsistent.

Inspect headers at a recipient mailbox

Send test messages to Gmail, Outlook.com, Yahoo Mail, and a mailbox hosted on a separate domain if possible. Open the raw message source and look for headers similar to:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounce.billing.example.com;
       dkim=pass header.d=billing.example.com;
       dmarc=pass header.from=billing.example.com

The exact formatting varies by recipient, but the essential checks are clear:

Does the visible From address use the intended subdomain?
Does SPF pass for the actual envelope sender?
Does DKIM pass using the expected d= signing domain?
Does DMARC pass and align with the From domain?
Does the message show a custom return-path or provider-owned one?
Do links use the intended tracking domain, if tracking is enabled?

A service such as mail-tester.com can provide a useful preflight view of authentication, message construction, and common spam signals. Treat its score as a diagnostic input, not as a promise of inbox placement at every mailbox provider.

Troubleshoot common subdomain failures

Subdomain issues often look like DNS problems but originate in the application or sender configuration. Start from a real message header and work backward through each identity.

SPF passes, but DMARC fails

This usually means the SPF-authenticated envelope domain does not align with the visible From domain, and no aligned DKIM signature passed.

For example:

From: receipts@billing.example.com
spf=pass smtp.mailfrom=provider-bounces.example
dkim=pass header.d=provider.example
dmarc=fail

Both SPF and DKIM can be technically valid while neither aligns with billing.example.com. Configure custom DKIM for your sending domain, a custom envelope domain, or both, depending on your provider's capabilities and your chosen alignment policy.

DKIM record exists, but DKIM fails

Check the d= and s= values in the actual DKIM-Signature header. Then query exactly:

<s-value>._domainkey.<d-value>

Common causes include publishing the record under the wrong domain, copying only part of a long public key, accidentally using a TXT record where a CNAME was required, and leaving the sender configured with an old selector.

Provider verification fails after adding DNS

First, confirm the DNS interface did not append the zone name twice. If you entered s2026._domainkey.billing.example.com into a field that automatically appends example.com, the resulting record may become s2026._domainkey.billing.example.com.example.com.

Also check for conflicting records. A CNAME cannot normally share the same name with a TXT, MX, or A record. Finally, compare the requested record byte-for-byte with the published public result, paying attention to underscores, selector names, and trailing dots in fully qualified CNAME targets.

Mail is accepted but lands in spam

Authentication is necessary but not sufficient. Review the message stream itself:

Send only to recipients who expect the message.
Remove invalid or inactive addresses promptly.
Keep complaint-prone marketing separate from essential transactional mail.
Use a recognizable From name and a clear reason for the email.
Include a working unsubscribe mechanism for promotional mail.
Avoid misleading subjects, excessive link redirects, and sudden unexplained volume spikes.
Monitor bounces, complaints, deferrals, and engagement by subdomain.

Google's sender guidelines also call for valid forward and reverse DNS for sending domains or IPs, TLS in transit, and stronger authentication requirements for high-volume Gmail senders. (support.google.com) If your provider operates the sending IPs, it normally manages IP-level reverse DNS; if you run your own SMTP infrastructure, reverse DNS is your responsibility.

Operate subdomains as long-lived infrastructure

Creating a sending subdomain is not a one-time DNS task. Treat it as production infrastructure with ownership, change management, alerts, and periodic review.

Maintain a simple register for every sending subdomain. Record its business purpose, owner, approved providers, SPF record, DKIM selectors, DMARC policy, return-path domain, tracking domain, expected volume, and last successful test date.

Review that register whenever you:

add a new SaaS tool that sends on your behalf;
change DNS providers or move zones;
rotate API keys, SMTP credentials, or DKIM keys;
launch a new high-volume campaign;
change the visible From domain;
tighten DMARC policy; or
retire an application or provider.

Also remove old authorizations. An obsolete SPF include, active DKIM delegation, or forgotten SMTP credential can leave an unnecessary path for mail to be sent under your brand. Domain hygiene is both a deliverability practice and a security practice.

A practical launch checklist

Before enabling production traffic from a new subdomain, verify the following:

The subdomain name has a documented purpose and owner.
The application uses the intended visible From address.
The envelope sender or custom return-path domain is known and configured.
There is one valid SPF record for each SPF-evaluated sending domain.
SPF includes only authorized systems and remains within lookup limits.
DKIM is enabled, and the delivered message uses the intended signing domain and selector.
DMARC exists at the relevant parent or exact subdomain and has a deliberate policy.
SPF or DKIM achieves DMARC alignment with the visible From domain.
Bounce processing is active and hard bounces are suppressed appropriately.
Tracking domains are configured only if needed and resolve correctly.
Test messages show authentication passes in raw headers.
You have tested a real recipient flow, including replies, links, and password-reset or receipt content.
Logs capture provider request IDs, SMTP responses, and delivery events where available.
A rollback plan exists if DNS or sending configuration causes failures.

The key principle is simple: a subdomain should represent a coherent mail stream with an explicit identity. When the visible From address, SPF domain, DKIM domain, DMARC policy, and bounce handling are designed together, the setup is easier to operate and easier for receiving systems to trust.

FAQ

Do I need separate SPF, DKIM, and DMARC records for every subdomain?

Not always, but you must evaluate each identity separately. SPF is checked against the SMTP envelope domain, DKIM against the signing domain, and DMARC against the visible From domain. A parent DMARC policy can apply to subdomains, but a subdomain may still need its own SPF record and DKIM delegation.

Can I send from `notify.example.com` if my website is on `www.example.com`?

Yes. Website hosting and email sending are separate DNS concerns. You can use notify.example.com for email authentication and sending even if it has no website or A record.

Should transactional and marketing email use different subdomains?

Usually, yes, when their audiences, volume, content, and complaint risk differ materially. A common pattern is notify.example.com for transactional mail and news.example.com for campaigns. Maintain good sending practices for both; separation is not permission to send unwanted mail.

Does a `250` SMTP response mean the email reached the inbox?

No. It means the SMTP server accepted the message at that point in delivery. The message can still be deferred, filtered, quarantined, or placed in spam later. Review delivery events and recipient mailbox headers for the full outcome.

Can I use a provider's default DKIM domain?

You can, and the signature may pass DKIM validation. But it may not align with your visible From subdomain for DMARC. Custom DKIM that signs with your own domain is generally the clearer and more controllable setup when the provider supports it.

How to Send Email From Subdomains: DNS Setup and Deliverability