Scope and provider-specific configuration
StatusHub has documentation for different mail-provider routes. This guide follows its Email sender - Postmark - New article; the retained older Mailgun article must not be mixed into that setup. Confirm that your Hub displays the matching route before publishing. A migration or older tenant can require different records.
Open Hub Config, Notification Settings, Email sender. The documented default is do-not-reply@statushub.io. Enter the intended custom sender and let the page refresh to show its DNS instructions. The Postmark route requires a DKIM TXT record and a Return path CNAME. Copy the name and value directly from the control panel, rather than using the example public key in the help article.
The return-path owner is typically a pm-bounces subdomain, but the actual requested name controls. Never put this CNAME at the domain apex merely because that is the domain in the visible From address. StatusHub specifically warns that an apex CNAME can conflict with other records and impair unrelated systems, including incoming mail. Keep mailbox MX records separate from this return-path delegation.
After publishing both records, use Recheck DNS records in StatusHub. A fully verified custom sending domain permits the specified From address. When a custom sender remains unverified, StatusHub documents fallback to do-not-reply@statushub.io in From while placing the custom address in Reply-To. That distinction is useful during diagnosis: a reply reaching your team does not prove customers saw your branded sender.
The help article discusses escaped and unescaped semicolons for DKIM TXT values. Apply the syntax needed by the DNS editor, then inspect the published value; do not insert backslashes into the key as a blanket fix. A new record may validate quickly, but the article notes provider and TTL differences. Diagnose the exact owner, type and value before attributing all failures to propagation.
The decision that matters
Confirm both the active mail-provider route and whether fallback has moved the custom identity to Reply-To.
Verify the published records and the real sending path
Record the change owner, sending product, domain, approved maintenance window and prior DNS answers before editing. Obtain the current record values from the named account or documented provider workflow. Separate values supplied by the provider from choices your organization controls, such as DMARC policy and reporting recipients. Existing mailbox MX, unrelated verification TXT records and active DKIM selectors are not cleanup candidates merely because a new service is being added.
Query the authoritative name servers for each exact owner and record type after publication. Record the query time, responding server and complete answer. Compare TXT strings as one logical value where the DNS response splits them into character strings. Check CNAME targets as well as the starting alias. Then compare a recursive-resolver answer to identify caching differences. A successful provider validation is useful evidence of configuration, but it does not establish what an actual recipient received.
Send only an authorized test to a controlled recipient using the intended product route. Retain the raw message and the trusted receiving system's Authentication-Results. Record the visible From domain, SMTP MAIL FROM or observed Return-Path domain, every DKIM d= and s= value, SPF and DKIM outcomes, and the receiver's DMARC result. A passing SPF or DKIM check supports DMARC only when its authenticated domain aligns with the visible From domain under the applicable policy. Reply-To and a branded display name are not alignment identities. RFC 7208, RFC 6376 and RFC 9989 provide the protocol basis for these distinctions.
Acceptance worksheet, recovery and evidence limits
This is an original acceptance worksheet, not a report of live testing. Mark each gate pending until evidence exists: account scope confirmed; previous DNS captured; exact new owner/type/value published; provider verification complete; intended route exercised; received identities recorded; aligned authentication confirmed; other senders unaffected. Assign a person and evidence file to every gate. A red gate blocks rollout even when the provider dashboard is green.
If a test fails, first distinguish missing publication, stale cached data, inactive provider configuration, wrong outbound route and nonaligned authentication. Correct the smallest demonstrated defect and test again. Do not weaken DMARC or delete other senders' records simply to make one test pass. If a change harms existing mail, use the approved recovery plan and the captured pre-change configuration, coordinating any provider-side sender change as well as DNS. Retain old keys while queued messages or an approved overlap still require them.
No customer tenant, authoritative before/after change or real received message was available for this manuscript. The retained sources support the documentary workflow; they do not satisfy the commissioned live-evidence gate. Independent checker review and human SME approval remain pending. Do not describe this guide as field-validated or publish it as having passed those gates.
Interpret fallback as a different identity outcome
Written case SH-01 assumes the intended sender is status@example.com but the Postmark-route domain remains unverified. The illustrative notification therefore uses the documented default From do-not-reply@statushub.io and Reply-To status@example.com. All SPF/DKIM results are unknown. A reply reaching the custom address would establish neither custom From use nor aligned authentication for example.com. The Hub owner must verify the active provider route, correct the precise generated DKIM and Return-Path owners, recheck the status and inspect a controlled notification. Do not move the Return-Path CNAME to the root or import old Mailgun instructions. No incident, subscriber notice, DNS query or configuration change occurred.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.