Statuspage SPF, DKIM and DMARC setup, step by step

For Atlassian Statuspage notifications, configure your custom Send from email, publish the account’s ownership, SPF and DKIM records, and select Revalidate all records. Configure both delivery partners, Mailgun and SendGrid, so the branded sender is not dependent on one provider. Atlassian allows up to 24 hours after validation for authenticated and signed sending to begin. Statuspage authentication workflow

This guide covers incident and maintenance email notifications sent by Statuspage. It is separate from the status website’s custom-domain CNAME and from Jira or Confluence’s organization-level email setup. For the latter, use EmailAuth’s Atlassian Cloud notification guide.

No Statuspage account, customer DNS, notification or failover was changed or tested.

Plan the notification identity before editing DNS

Identify the page, intended From address, optional Reply-To address, account administrator and DNS owner. The From domain is the identity DMARC protects. Reply-To only directs responses and does not establish alignment.

Use a domain you control. Confirm that the account exposes custom notification sender settings and that your operator can change them. The cited authentication procedure does not establish one universal paid-plan or role requirement, so resolve missing controls with the account administrator or Atlassian before scheduling a change.

Check whether your proposed From domain is already registered with Mailgun through another service. Statuspage documents that it cannot add the same domain to Mailgun a second time and recommends a dedicated From subdomain in that situation, such as status@notifications.example.com. This is a supported way to avoid that conflict, not permission to move unrelated mail or DNS records. Mailgun domain limitation

Set the custom From address and retrieve the records

Open Your page > Customize page and email > Customize email. Set Send from email, optionally set Reply to email, then save the email customizations. Follow the displayed setup link or open Your page > DNS configuration. Copy the entries for the notification From email, not merely those for the status website. Account navigation

Record the complete owner, type and expected value for each item. Statuspage’s current DNS guide describes these distinct requirements:

• An ownership TXT value in the format status-page-domain-verification=ORGANIZATION_CODE, with the actual code supplied by your account.
• SPF authorization including include:stspg-customer.com.
• The generated DKIM record for provider #1, Mailgun.
• Three generated CNAME records for provider #2, SendGrid.

Use the account’s record types and targets. Do not assume all three SendGrid aliases are DKIM selectors or replace a CNAME with a TXT key. Publish only public keys or the supplied aliases; private signing keys do not belong in DNS. Statuspage’s record requirements

Until this custom email configuration is completed, the documented default sender is noreply@statuspage.io. A message from that default may authenticate successfully without proving your branded setup is finished.

Configure SPF at the correct owner

Statuspage explicitly requires the stspg-customer.com include. Incorporate it into the existing SPF policy at the owner specified for the sending domain. Do not publish a second v=spf1 record, replace existing senders or change the terminal qualifier just because an example uses -all.

For a brand-new owner whose only authorized sender is Statuspage, the documented pattern is:

v=spf1 include:stspg-customer.com -all

That is a conditional example, not a replacement for a shared domain’s policy. The official documentation’s longer example also contains include:mailgun.org; it demonstrates combining senders in one record. Add that additional include only when your actual account requirements or other authorized Mailgun use call for it, not because it appears in the example. SPF example and duplicate-policy warning

SPF is checked against the SMTP MAIL FROM domain and connecting IP, not automatically the visible From. With a null reverse path, SPF can use HELO. A parent-domain SPF record does not automatically apply to a child envelope domain. Check the actual smtp.mailfrom on the delivered notification rather than asserting a universal Statuspage envelope format. SPF protocol

Adding an include does not prove SPF alignment. The documented providers can use different envelope identities, and the guide does not guarantee one identical return path for every delivery. The delivered-message test must establish whether SPF passes and whether its identity aligns. Keep the complete SPF evaluation within the ten DNS-lookup-term limit, including nested includes and redirects. Do not flatten provider IP ranges into a static list without a supported maintenance process.

An SPF all mechanism makes redirect ignored, wherever the mechanism occurs. If the current policy delegates through redirect, preserve its legitimate sender authorizations and approved terminal semantics in a reviewed combined design rather than appending an include or all blindly. SPF all and redirect.

Complete both DKIM provider configurations

Mailgun and SendGrid are independent setup requirements. Retrieve the current Mailgun DKIM owner and public value or target, and the full three-record SendGrid set from the same page. Copy generated selectors and tenant-specific destinations exactly. A generic selector such as s1 in a tutorial is not a substitute for the values in your account.

The reason to complete both providers is operational continuity. Atlassian documents that, when only one is configured, mail normally uses that provider. A system-wide failover to the other provider can instead cause notifications to use noreply@statuspage.io when its custom-domain configuration is missing. Provider failover behavior

A valid DKIM signature is checked by the recipient using the public key associated with the signature’s d= domain and s= selector. DNS publication enables this check; it is not itself a message signature or evidence that a particular notification was signed. DKIM verification model

Handle an older DKIM-to-CNAME migration deliberately

The DNS guide describes a separate migration from older keys to three CNAMEs, including Invalidate this record now, publication of the new aliases, then Revalidate all records. Do not click an invalidation control during ordinary setup merely because it is mentioned in a tutorial. First confirm that this is the migration your account needs, capture the prior state and agree the change window and recovery approach. Retain unrelated selectors and any keys still needed for queued or other legitimate mail. Official migration sequence

Map DNS owners without breaking the website or inbound mail

Confirm the authoritative zone and save its relevant existing records before changes. The following examples show how names map into common DNS editors. SELECTOR represents the current account’s actual selector.

• Apex From domain example.com: SPF and the ownership TXT can be at @ in the example.com zone when the account specifies that owner. DKIM SELECTOR._domainkey.example.com becomes relative host SELECTOR._domainkey.
• Child From domain notifications.example.com, managed in the parent zone: SPF at that child uses relative host notifications; its DKIM owner becomes SELECTOR._domainkey.notifications.
• Separately delegated notifications.example.com zone: The same child SPF owner is @, and its DKIM owner is SELECTOR._domainkey inside the child zone. Query the child’s authoritative nameservers.
• DMARC: _dmarc.notifications.example.com is _dmarc.notifications in the parent zone or _dmarc in the delegated child zone.

Statuspage permits its ownership TXT for a child sending domain on the child itself or at the apex and says it checks both. This ownership exception does not mean that child SPF or DKIM can be moved to the parent. Follow the exact generated owners for those authentication records. Ownership TXT placement

For a delegated _domainkey.notifications.example.com zone, the full owner SELECTOR._domainkey.notifications.example.com is relative host SELECTOR at that zone’s authoritative servers. If _domainkey.example.com is delegated instead for apex signing, SELECTOR._domainkey.example.com is likewise relative SELECTOR there. Preserve existing NS delegations and selectors; the parent-zone editor is not authoritative below a delegation. For apex DMARC, _dmarc.example.com is relative _dmarc in example.com. DNS zone authority.

Avoid a duplicated domain suffix, and keep supplied CNAME targets as hostnames without URL prefixes. Use DNS-only records rather than a web proxy for mail aliases. A CNAME cannot share its owner with unrelated TXT, A or AAAA data. Do not put an email TXT record on an owner already used by the status website’s CNAME; choose a supported email identity and resolve the collision with the administrators. CNAME conflicts

Keep authentication CNAMEs unflattened so a public CNAME query returns the required alias, not only address records. On Cloudflare, this requires DNS-only proxy status, the record’s Flatten setting off, and zone-wide CNAME flattening for all CNAME records off. Check both scopes. Cloudflare identifies either flattening setting as a cause of failed CNAME verification. Coordinate any shared zone-setting change with the DNS owner and assess its effect on other services before applying it; do not remove a legitimate child-zone delegation as a shortcut. Cloudflare’s CNAME verification guidance

Cloudflare also always flattens apex CNAMEs and CNAMEs whose target is in the same zone; the same-zone behavior can ignore the selected setting. Do not assume a per-record control exists for every plan or can override mandatory behavior. If the issued owner/target cannot retain the required literal CNAME answer, stop and coordinate a supported configuration with the DNS owner and Atlassian rather than inventing a switch, moving the record or globally changing unrelated services. Conditional and mandatory flattening.

Preserve the website CNAME, inbound MX and other senders’ TXT records. Multiple unrelated TXT records can coexist, but there must be only one SPF policy at an SPF owner and one DMARC policy at its owner.

Validate DNS, then wait for sending activation

Replace uppercase placeholders and illustrative domains with the actual setup values. These commands inspect DNS without changing it:

dig +short NS example.com
dig @AUTHORITATIVE_NS notifications.example.com TXT +noall +answer
dig @AUTHORITATIVE_NS MAILGUN_DKIM_OWNER TXT +noall +answer
dig @AUTHORITATIVE_NS SENDGRID_CNAME_OWNER CNAME +noall +answer
dig +short CNAME SENDGRID_CNAME_OWNER
dig +short TXT DKIM_CNAME_TARGET
dig +short TXT _dmarc.notifications.example.com
dig +short TXT _dmarc.example.com

Use the Mailgun query only if the generated record is TXT; query CNAME instead when the current account specifies an alias. Repeat for all three SendGrid owners and any additional account-required entry. Follow DKIM alias chains to their TXT public keys. Compare the complete logical TXT value even when DNS displays it as multiple quoted character strings.

The authoritative answer should match the current expected value. Compare a recursive resolver’s answer to identify caching differences. A DNS query for your eventual observed MAIL FROM domain is also required when investigating SPF. A successful lookup alone cannot show that the notification used that identity.

Select Revalidate all records in Statuspage after publishing. The authentication guide suggests allowing several minutes, up to ten in its example, before revalidation, then up to 24 hours after successful validation for signed sending. Existing TTLs and negative caches can require longer to refresh; do not turn an estimate into a guarantee. Atlassian’s DNS troubleshooting guide recommends low TTLs for changes, but lowering a TTL does not evict answers already cached under the previous value.

Records must remain published. Statuspage documents automatic re-verification every hour. Keep both partner sets in your DNS inventory and recheck after hosting changes rather than waiting for the hourly pass. Ongoing checks

Preserve DMARC and set up useful reporting

Inspect the policy for the actual From domain and applicable parent policy before editing. For status@notifications.example.com, check _dmarc.notifications.example.com as well as the applicable parent policy at _dmarc.example.com. Keep existing protection, alignment modes, subdomain scope and approved report destinations.

DMARC requires at least one passing and aligned SPF or DKIM identity. Relaxed alignment allows a shared organizational domain; strict alignment requires the authenticated domain to match From exactly. A valid d=example.com signature can align with notifications.example.com in relaxed mode but not with adkim=s. DMARC alignment and policy discovery

Only where no effective policy exists and the owner approves monitoring first, an initial policy could be:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Publish it as TXT at the chosen _dmarc owner and use a monitored, approved recipient. Do not add it beside an existing policy or replace enforcement with it. Compare the Organizational Domain of the report destination URI host with the Organizational Domain of the domain where the DMARC policy was found. A different Organizational Domain requires the report-generating receiver to check the destination’s DNS authorization; the same Organizational Domain is excepted. This protocol authorization does not replace the owner’s approval to share report data with that recipient. Aggregate-report authorization and same-domain exception.

Use reports to identify notification traffic, actual SPF/DKIM identities and changes after migrations. Reports are not inbox-placement receipts and are not guaranteed from every recipient. RFC 9989 removed pct; do not build a new rollout around that older tag. Its Section 7.4 requires valid DKIM for p=reject rather than reliance on SPF alone. Assess the domain’s other senders and indirect-mail routes before changing enforcement.

Verify a delivered notification and record failover limits

An authorized page operator should use a controlled recipient and a safe, approved notification route. Do not create a false public incident or notify the production subscriber list solely to test DNS. If a test-only method is unavailable, arrange an approved validation opportunity instead of improvising a public event.

Inspect the received raw message and the trusted receiver’s Authentication-Results. Authentication-Results trust boundary Record the notification type, page, timestamp, intended and actual From, observed smtp.mailfrom, Return-Path, sending IP, all DKIM d= and s= values, and the receiver’s SPF, DKIM and DMARC verdicts.

Establish the actual receiving service’s known processing boundary and its documented handling of externally supplied Authentication-Results, such as removal or explicit exclusion from trusted evaluation. Use receiver-controlled diagnostics or an administrator-confirmed trace when raw headers cannot establish that boundary. Matching authserv-id text or header position alone is not proof; ignore attacker-supplied or otherwise untrusted results. Forged results and receiver trust.

Accept the observed route only when:

1. The notification uses the intended branded From address, not the default Statuspage sender.
2. Its intended branded DKIM signature passes and aligns under the effective policy. Neither a provider-owned DKIM pass nor an SPF-only DMARC pass completes this requirement.
3. SPF is checked at the actual envelope identity. An unaligned provider-owned pass differs from fail, softfail, none, permerror or temperror. Investigate actual failures and errors even when DKIM permits DMARC to pass.
4. The receiver reports dmarc=pass for the intended From domain.
5. Both delivery partners show complete account/DNS configuration, and unrelated senders remain intact.

Keep separate evidence fields for provider configuration and observed delivery. A Mailgun-delivered sample proves nothing about an unobserved SendGrid message. Do not induce a provider outage or claim failover was exercised. Record the unobserved partner as untested while retaining its validated DNS setup.

Troubleshooting common Statuspage problems

The page loads, but custom email still fails: The website’s CNAME and notification authentication are separate. Inspect the notification From section in DNS configuration.

Mailgun will not accept the domain: Check existing Mailgun use. Apply Statuspage’s documented dedicated-From-subdomain approach if appropriate, then retrieve that subdomain’s own record set. Do not remove another service’s Mailgun domain to force setup.

Mail suddenly comes from noreply@statuspage.io: Inspect both provider configurations and recent DNS changes. The documented failover behavior makes the unconfigured partner relevant even when yesterday’s normal provider worked.

Revalidation fails: Check the owner, record type, duplicated suffix, proxy status, CNAME conflict and authoritative answer before waiting longer. Repeatedly invalidating a valid key is not a cache fix.

SPF returns a permanent error: Check duplicate SPF policies, syntax and lookup limits at the observed envelope owner. Correct the demonstrated error without replacing all other sender authorizations.

At the observed envelope owner, fail or softfail means the actual connecting sender was not authorized by the evaluated policy; check the real route and authorized sender inventory. temperror indicates a transient evaluation or DNS availability failure, not a permanent syntax defect. Diagnose these separately from permerror and repeat the appropriate test even when aligned DKIM gives DMARC a pass. SPF result meanings.

DNS validates but DKIM is absent or fails: Allow the documented activation window, then compare the actual d= and s= with the intended partner’s current records. Confirm that the message was generated after activation and was not altered by a downstream gateway.