Scope and provider-specific configuration
Atlassian Statuspage separates a custom status-page web domain from a custom notification From address. A working website CNAME does not authenticate mail. The email workflow also has multiple delivery providers, so complete all displayed provider records rather than stopping at the first successful DKIM setup.
Go to Your page, Customize page and email, then Customize email. Set Send from email, optionally configure Reply to email, and save email customizations. Follow the new link or open Your page, DNS configuration. Capture the values in the notification From email section. The ownership TXT uses the format status-page-domain-verification=<ORGANIZATION_CODE>; the actual organization code must come from the account.
The current DNS guide requires SPF authorization including stspg-customer.com. Incorporate include:stspg-customer.com into the applicable existing policy, not a second SPF record. Its Mailgun example is illustrative and is not permission to add unrelated services. Publish the DKIM record for provider #1, Mailgun, and the three CNAME records for provider #2, SendGrid, using the account's current values. The guide has a separate migration path from older DKIM keys to CNAMEs; do not invalidate a working record unless intentionally carrying out that approved migration.
An important boundary is existing Mailgun use: Statuspage says it cannot add the same domain a second time when another service already uses Mailgun. Its recommended workaround is a dedicated From subdomain, such as notifications.example.com. This illustrative subdomain still needs its own displayed setup and appropriate DMARC evaluation.
Use Revalidate all records after publication. Atlassian says authenticated and signed sending begins within 24 hours after validation, and that records are checked hourly and must remain present. With only one provider configured, a system-wide failover can cause messages to use noreply@statuspage.io. Both provider configurations are therefore a continuity measure, not redundant clutter.
The decision that matters
Test provider readiness and branded-sender continuity; one configured delivery partner is not the full setup.
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.
Use a provider-by-provider continuity ledger
Written case SP-01 assumes custom From status@notifications.example.com, Mailgun configuration complete, and the SendGrid record set missing. A stipulated Mailgun-delivered sample has trusted DKIM pass d=notifications.example.com, s=demo1; SPF is unknown. That sample supplies exact DKIM alignment but does not establish branded continuity through SendGrid. The incident-communications owner must resolve the missing provider setup or explicitly accept the documented default-sender fallback risk before claiming continuity. Do not induce an outage or notify real subscribers to test this teaching case. Complete account validation and use an authorized controlled test where supported; an unobserved failover remains unobserved. No incident or failover was executed.
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.