Choose the communication identity before editing DNS
A school announcement has two distinct operational needs: recipients must recognize the sender, and the sending route must authenticate correctly. Decide whether broadcasts should display an address on the school’s domain or a provider-managed identity. Then identify the actual SchoolMessenger product and account. This guide covers the Communicate administrative options documented by PowerSchool, not every service sharing the SchoolMessenger name.
The PowerSchool sending-options guide, introduction presents two arrangements and asks customers to coordinate their choice and DNS completion with SchoolMessenger Solutions Support. Plan that coordination as part of the change. Merely adding records does not establish which arrangement the provider is using for your broadcasts.
Select a routine test window with the communications owner. Do not combine initial authentication work with a weather closure, safety alert or other urgent announcement. Preserve the organization’s existing emergency communications procedure; this guide does not authorize a broad broadcast or claim that email authentication guarantees delivery.
Keep the provider-domain option unresolved where the source conflicts
Option 1 describes provider-managed identities and no customer DNS changes. However, its configuration lists broadcasts@schoolmessengermail.com while its drawbacks text names broadcasts@schoolmessenger.com. It also lists a signing domain under schoolmessenger.com. These are materially different domains, so the article cannot safely promise alignment for the literal combination as printed.
Do not silently choose the version that makes the diagram work. Ask support to confirm the visible From domain, envelope domain and DKIM signing domain for the actual account and selected option. Capture a controlled received message and compare those identities with the answer. Keep the discrepancy in the worksheet until it is resolved.
A school-controlled Reply-To address can route replies back to the school without making the message authenticate as the school’s domain. This may or may not meet the communications team’s branding requirement. State that tradeoff clearly before accepting a provider-domain route. Changing a display name does not change the domain used by DMARC.
Review the custom-domain option and its DNS requirements
Option 2 describes the customer’s domain for From, the envelope and DKIM. Its “DNS Changes Required” section names include:customerspf.schoolmessenger.com and a spe1 selector CNAME pointing to spe1._domainkey.spe.schoolmessenger.com. Its stated limitation is that the platform does not process out-of-band bounces after handoff to a recipient system. Confirm applicability with support rather than treating the published example as account activation.
Option 2 explicitly copies Header From into Reply-To. Choose a monitored From mailbox and confirm that this documented reply behavior fits the school’s workflow; do not promise an independent Reply-To override.
Obtain the approved domain list, support case and expected activation time. If more than one school or administrative unit uses a different From domain, identify each one explicitly. Do not assume that configuring the district’s main domain covers unrelated domains or that a subdomain uses exactly the same account-side settings without confirmation.
Export the existing DNS records before making a proposed change. Check whether the spe1 selector name is already occupied and who owns it. If there is a collision, ask support for a supported resolution. Do not replace another sender’s key or create both a CNAME and conflicting data at the same owner. Do not invent an alternate selector: it must match what the service signs with.
The exact owner in the customer zone depends on the approved domain and the DNS interface. A form may accept a relative name while another expects a fully qualified one. Verify the resulting public owner rather than relying on a screenshot of the input fields. The provider target is public verification infrastructure, not a private key to be copied into a ticket.
Merge SPF without removing other school senders
Identify the policy at the domain actually used for the envelope. RFC 7208, section 2.3 defines SPF’s MAIL FROM identity; it is not simply whatever address appears beside the school’s display name. In the supported custom-domain arrangement, the expected and observed identities should agree, but record them separately so a configuration mismatch is visible.
Retain authorization for other legitimate systems, including the school’s mailbox service and any independently approved application senders. Add only the required SchoolMessenger authorization to the existing reviewed policy. Creating another v=spf1 record at the same owner does not combine policies and can make the result invalid.
Review nested lookups against RFC 7208 section 4.6.4. A short include can reference further policies, so count the evaluation cost rather than the number of words visible in DNS. Do not copy an entire example over the existing policy, casually change its terminal qualifier, or delete unfamiliar services to fit the limit. Escalate a policy conflict to the mail administrator.
After publication, compare authoritative answers with the approved before-and-after record. Retain the observation time and allow for caching. If a resolver still reports an old answer, distinguish that from an incorrect authoritative record. Repeatedly editing a correct record can make diagnosis harder.
Make bounce ownership part of the launch decision
Ordinary replies and delivery errors serve different purposes. Decide where replies should reach school staff, then separately establish how administrators will learn about failures. For the documented custom-domain route, the out-of-band bounce limitation is an operational issue even when authentication passes.
Ask support what evidence is available for synchronous rejections, delayed failures and invalid recipient addresses. Determine whether the school’s mail team must monitor a mailbox or another supported mechanism. Do not assume that typing a bounces address in an example creates a mailbox, that every failure appears in the campaign report, or that lack of a bounce proves delivery.
Test the approved failure-handling arrangement without using a student’s real account or distributing private family information. Use only test destinations that the administrators control and an agreed procedure. Record who will reconcile delivery failures with contact-data maintenance and how they will avoid sending unnecessary follow-ups to the wrong audience.
Inspect a controlled broadcast from the final receiver
Send harmless content through the actual Communicate route to controlled external recipients. Keep the broadcast identifier, Message-ID and UTC time. If staff can choose several sender domains or reply addresses, test the combinations that materially change the identity. Do not send a real school-wide announcement merely to obtain headers.
Capture visible From, Reply-To, Return-Path or receiver-reported envelope identity, every DKIM d= and s= pair, and trusted receiver results. RFC 6376, section 3.5 explains the domain and selector fields used for the key lookup. Check that the observed selector resolves through the intended public record and that the resulting signature verifies.
Apply RFC 9989, section 4.4, “Identifier Alignment Explained”. DMARC needs an aligned passing SPF or DKIM result. Record which mechanism supplies it and which alignment mode applies. A technically valid signature under an unrelated provider domain cannot authenticate the school’s visible domain by itself.
Keep delivery, authentication and reply routing as separate results. Inbox placement is not proof of correct alignment, and an internal gateway exception can conceal a problem that external families still encounter. A test passing through a forwarding service may also differ from direct external delivery; label the route rather than combining those results.
Use the sending-option acceptance worksheet
Create a separate review record for the SchoolMessenger option and bounce worksheet using the fields below. It records the product, support-confirmed option, exact identities, source discrepancy, DNS evidence, bounce owner and controlled-message results. The explicit Option 1 uncertainty field prevents a later reviewer from treating inconsistent published examples as verified account facts.
Require signoff from both the mail administrator and the communications owner. The administrator verifies DNS and authentication. The communications owner verifies the visible sender, monitored reply destination and the recovery plan. Keep a separate owner for bounce handling if that responsibility does not sit with either person.
Fictional worked example: authentication passes but the workflow is incomplete
Fictional written case only: SMC-01 stipulates Option 2 From notices@district.example and a passing signature d=district.example, s=spe1. The exact envelope result is unknown; the stipulated signature exactly aligns. However, no one owns delayed failures under the documented bounce limitation. The communications owner and mail administrator must confirm monitored reply handling and a supported delayed-failure process before approving operational launch. These are teaching assumptions, not evidence from a school account or broadcast.
Recover and recheck without lowering the school’s policy
If the new identity fails, pause the planned identity change and coordinate a return to the last approved sending arrangement with support. Keep emergency communications on the established operational process. Do not weaken the whole domain’s DMARC policy or add broad allowlists simply to hide one unverified route.
Retain public verification records for messages still in flight until the mail owner and provider agree they can be retired. Recheck after domain changes, support-side option changes, mailbox migrations and new sender workflows. The Option 1 identity conflict, exact account activation, live DNS, real-message evidence and bounce behavior remain pending. This is an unpublished draft awaiting visual review and human SME approval.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.