A domain alias changes how an address can be used or received within a service. It does not, by itself, define the domain placed in an outbound DKIM signature. Before using an alias for customer mail, examine a message sent through the intended route and determine which identity the service signs.
Alias is also an overloaded product term. It can describe an alternative mailbox address, a domain attached to a tenant, or an application-level sender identity. This workflow applies to the resulting message and DNS evidence. Consult the current documentation for the particular alias feature before assuming it supports sending or custom-domain DKIM.
Separate receiving configuration from sending identity
First establish what the alias is meant to do. An address that receives messages into an existing mailbox may never be authorized for outbound use. If sending is supported, determine whether the service retains the alias in From, rewrites it to the primary address or routes it through a different sender.
Record the visible From address after delivery, not only the address selected in the compose window. Also record any Sender field and envelope identity, but do not confuse them with DKIM's d domain. RFC 6376 §3.5 defines the d signing domain, distinct from the message author's address. RFC 9989 §4.4 uses the Author Domain and authenticated identifiers for alignment.
Read every signature on a controlled message
Send a test from the alias using the same client, API or delegated mailbox route as production. Export the received message without editing it. Identify each DKIM-Signature, its d and s values, and the trusted receiver's result. A service can add both a provider signature and a customer-domain signature; the first one displayed by a tool may not be the one relevant to DMARC.
For each passing signature, assess alignment with the received From domain. Strict mode needs an exact domain match under RFC 9989 §3.2.10. Relaxed mode permits the same organizational domain under RFC 9989 §4.10.2. Two distinct registered domains do not align simply because one is an alias of the other in an administration portal.
Use a small identity worksheet
Illustrative case, assuming distinct Organizational Domains and an applicable DMARC policy: the primary address is person@company.example, while the outgoing alias is person@newbrand.example. The receiver sees From at newbrand.example and a passing signature with d=company.example. That signature does not align with newbrand.example. If another passing signature uses d=newbrand.example, that second signature supplies an aligned DKIM path.
Record both outcomes rather than calling the entire message unsigned or saying that DKIM is broken. A valid signature under the primary domain is still valid DKIM. The missing property is alignment for the alias. Evaluate SPF separately before assigning the overall DMARC result. This worksheet is a synthetic example, not evidence of any service's alias behavior.
Request the supported remedy
Ask whether the provider can sign alias mail with the alias domain, and whether that requires adding the domain as a distinct sending identity. Obtain its current DNS record names, record types and values. Verify who controls the DNS zone and whether the proposed change conflicts with an existing selector.
Do not manually copy a primary-domain public key and assume the service will start using a new d value. DNS publication cannot instruct an arbitrary signer to change identity. The sending configuration and the published verification material must agree.
Keep the alias in lifecycle reviews
Repeat the test for replies, mobile clients and application-generated messages when those routes are used. Keep a selector-to-provider map with the alias's business owner and a dated sample. On migration or retirement, confirm whether other identities still rely on the same provider before removing delegated records.
The closure statement should say which alias and route were tested, which d domain passed and whether it aligned. If a product cannot supply the required identity, document that limitation and choose a supported sending design rather than reporting the alias as authenticated without qualification.
Record the next decision
Use one row per actual route: requested alias, received From, each d/s pair, trusted result, alignment mode and remaining gap. A primary-domain pass with an unrelated alias From is valid DKIM but not aligned DKIM. Do not call the entire message a DMARC failure until SPF and the applicable policy are evaluated. No provider-specific alias capability or live result is asserted here.