For SchoolMessenger Communicate's custom-domain option, coordinate activation with SchoolMessenger Solutions Support, add include:customerspf.schoolmessenger.com to the existing SPF policy, and publish the spe1 DKIM CNAME for the approved sending domain. Then verify a controlled broadcast's branded DKIM signature and DMARC alignment. Before launch, assign responsibility for delayed bounces: the documented custom-domain option does not process out-of-band bounces after recipient-system handoff. PowerSchool's Communicate sending options.
No SchoolMessenger account, customer DNS or delivered message was tested. This guide covers Communicate, not every SchoolMessenger-branded service or PowerSchool application. DNS values for another module must not be assumed equivalent.
Choose the communication identity before changing DNS
Make three decisions with the communications and mail-administration owners:
- Must recipients see a school-controlled From address, or is a provider-controlled identity acceptable?
- Which exact account and domain will originate each type of broadcast?
- Who will monitor ordinary replies and delivery failures?
Arrange a routine test window. Do not make an urgent closure or safety announcement the first test of new authentication settings. Keep the existing emergency-communications procedure available; email authentication cannot guarantee timely receipt.
PowerSchool documents two Communicate arrangements. Support must confirm which one applies and be notified when customer DNS work is complete. Merely adding records does not activate a sending option. Official configuration options.
Option 1: provider-managed identity has an unresolved documentation conflict
The official table lists From broadcasts@schoolmessengermail.com, whereas the explanatory prose names broadcasts@schoolmessenger.com. It lists the envelope and DKIM signing domain under spe.schoolmessenger.com. These are not interchangeable domains. Do not infer a passing DMARC result for the literal table combination.
Ask Support for the current account's exact From, MAIL FROM and DKIM d= domains, then check an actual message. Keep this route unaccepted until that discrepancy is resolved. A school-controlled Reply-To and recognizable display name can route replies and help recognition, but neither authenticates the message as the school's domain. The documented option requires no customer DNS changes. Option 1 details.
Option 2: school-domain identity includes a bounce tradeoff
The custom option uses the customer domain for From, envelope and DKIM, with selector spe1; Reply-To copies From. Support should confirm the exact domain and activation. Do not promise an independent Reply-To override or assume that configuring the district apex covers every child or unrelated school domain. Option 2 details.
A school-domain address may satisfy the branding requirement while still leaving an incomplete operational workflow. Choose a monitored sender mailbox and document where delivery-error information will be reviewed. Do not treat a successful authentication result as evidence that those responsibilities have been assigned.
Prepare the exact domain, DNS owner and rollback record
Use a change worksheet with the approved From domain, expected envelope domain, Support case, selected option, existing SPF policy, DKIM owner, DNS authority and rollback owner. Include every materially different sending account or domain.
Export current records before editing. Preserve corporate mailbox authorization, student-information systems and other legitimate applications. Do not remove an unfamiliar include simply to make a proposed SPF record shorter; identify its owner first.
Identify the authoritative zone. For a fictional sending domain notice.example.org:
SPF full owner: notice.example.org
Relative owner in example.org zone: notice
Relative owner in delegated notice.example.org zone: @
DKIM full owner: spe1._domainkey.notice.example.org
Relative owner in example.org zone: spe1._domainkey.notice
Relative owner in delegated notice.example.org zone: spe1._domainkey
Some DNS editors expect the complete name; others append the zone. Inspect the resulting owner so it does not become notice.example.org.example.org. If a child domain is delegated, update its authoritative zone rather than an ineffective copy in the parent.
At an existing delegated _domainkey.notice.example.org authority, full owner spe1._domainkey.notice.example.org maps to relative spe1. Preserve NS delegation and other selectors, and publish the supported CNAME at that authority rather than bypassing delegation. Relative names.
For an apex sender such as example.org, the SPF owner is that apex, often entered as @, and the DKIM relative owner is spe1._domainkey. Do not add notice unless that child is actually approved and configured as the sending domain.
Add SPF without replacing other senders
SPF authorizes the IP sending with the SMTP MAIL FROM identity. That envelope identity is distinct from the visible From and from Reply-To. Under Option 2, confirm that the actual envelope matches the customer domain Support configured. SPF identity and record selection.
The provider-published authorization is:
include:customerspf.schoolmessenger.com
Insert it into the one existing v=spf1 policy at the relevant owner, before the terminal all mechanism. Retain the existing mechanisms and final qualifier. Do not publish an additional SPF TXT record or replace the whole policy with a SchoolMessenger-only example. If no policy exists, have the mail administrator construct one from the complete authorized-sender inventory rather than treating this include fragment as a complete record.
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
The following is a merge illustration, not deployable DNS. EXISTING_AUTHORIZATIONS and EXISTING_ALL must be replaced with the reviewed existing terms:
Before: v=spf1 EXISTING_AUTHORIZATIONS EXISTING_ALL
After: v=spf1 EXISTING_AUTHORIZATIONS include:customerspf.schoolmessenger.com EXISTING_ALL
Evaluate nested includes, redirects and other DNS-querying terms against SPF's ten-term limit. A single visible include may require several underlying lookups. Preserve a working policy until the full proposed policy has been reviewed. SPF DNS lookup limits.
SPF does not inherit from the apex to a child domain. Nor does adding authorization to the school domain force a provider-owned MAIL FROM to become school-aligned. Resolve an unexpected envelope with Support rather than adding the include at unrelated owners.
Publish the supported DKIM CNAME and arrange activation
For a confirmed Option 2 sender example.org, the published mapping is:
Owner: spe1._domainkey.example.org
Type: CNAME
Target: spe1._domainkey.spe.schoolmessenger.com
Replace only the customer domain with the Support-confirmed domain. The provider target remains the documented target unless Support supplies a current account-specific replacement. Notify Support when publication is complete. Current Communicate DNS requirements.
Check whether the owner is already occupied. A CNAME cannot coexist with another ordinary record at the same name. Do not overwrite another sender's TXT key, create both TXT and CNAME there, or invent spe2 to avoid a conflict. The selector must match the signature the service emits. Obtain a supported resolution first.
Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.
The CNAME delegates public-key lookup. Do not copy the provider's current key into a local TXT record or generate a private/public pair independently: that would not make SchoolMessenger sign with the matching private key. Never put a private key in DNS or a diagnostic ticket. DKIM selectors and key retrieval.
Assign delayed-bounce and reply ownership
An ordinary reply follows Reply-To. A delivery-status notification can instead return to the envelope address. Distinguish an immediate SMTP rejection from a delayed failure generated after a remote system accepted the message.
Before approving the custom-domain route, record:
- The team responsible for reviewing delayed delivery failures.
- The intended envelope address and where those failures should be received or investigated.
- How the team will reconcile a failure with the broadcast and update contact quality safely.
- A monitored sender mailbox for ordinary replies.
- A review frequency and escalation process appropriate to routine and urgent communications.
Confirm the details with Support and the school's mail administrator. Do not change the school's MX records or create a bounce mailbox merely from an address shown in documentation. Agree on the supported handling first.
A controlled acceptance exercise should prove both reply continuity and visibility of the delivery-error workflow, using only addresses the organization controls. Never test with real student or parent data in public header analyzers. A missing bounce observation remains an open item even when DNS and DMARC pass.
Validate public DNS and a real controlled broadcast
These read-only commands use fictional names. Replace the authoritative server and domain with the actual zone's values:
dig +short NS example.org
dig +short NS notice.example.org
dig @ns1.example.net TXT notice.example.org +noall +answer
dig @ns1.example.net CNAME spe1._domainkey.notice.example.org +noall +answer
dig TXT notice.example.org +noall +answer
dig CNAME spe1._domainkey.notice.example.org +noall +answer
dig TXT spe1._domainkey.spe.schoolmessenger.com +noall +answer
dig TXT _dmarc.notice.example.org +noall +answer
dig TXT _dmarc.example.org +noall +answer
Expect one SPF policy containing the authorized include and the exact CNAME with a resolvable public key behind it. Check authoritative answers before blaming cache delay. NXDOMAIN, wrong suffixes, unresolved targets and SERVFAIL are not successful publication. An empty NS answer for a nondelegated child is not itself an error.
After Support confirms the chosen option is active, send harmless content through the actual Communicate broadcast route to controlled recipients. Obtain the receiving system's original source, not only a screenshot of the sender name.
For each material route, record From, Reply-To, MAIL FROM/Return-Path, sending IP, trusted receiver Authentication-Results, each DKIM d= and s=, policy mode and timestamp. Also record the option Support confirmed, reply outcome and delayed-bounce owner.
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
For the custom-domain route, require the intended school-domain DKIM signature to pass and align with From, a DMARC pass and the expected branded identity. An unrelated provider signature or aligned SPF alone must not conceal missing custom DKIM. DMARC itself permits a pass through either aligned SPF or aligned DKIM; the branded-signature requirement is this guide's commissioning criterion. DMARC identifier alignment.
The expected direct Option 2 envelope should also pass SPF. Investigate fail, softfail, none, temperror or permerror, even if DKIM rescues DMARC. A valid but nonaligned provider envelope is a different observation: it suggests the configured route or option needs checking, not necessarily malformed SPF. For forwarded mail, compare direct delivery before authorizing the forwarder's IP.
Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.
Preserve DMARC and use reporting responsibly
Do not lower an established policy or create a duplicate DMARC record to accommodate this sender. Determine the effective policy for the actual From domain, including parent-domain policy and subdomain controls. aspf=s and adkim=s require exact matches for their mechanisms; relaxed modes use Organizational Domain alignment. p=reject does not by itself request strict alignment.
If neither a direct nor an inherited policy exists and the domain owner approves monitored rollout, the following is an example only:
For the apex example.org, the full DMARC owner is _dmarc.example.org, usually entered as _dmarc in that zone. For a From domain of notice.example.org, the full owner is _dmarc.notice.example.org: enter _dmarc.notice in the parent example.org zone, or _dmarc in a separately delegated notice.example.org zone. Use the full owner instead where the editor requires it, and never create a new child policy merely to override an inherited policy without the domain owner's approval.
Owner: _dmarc.example.org
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.org
Use a real, approved reporting destination and retain any established recipients. External reporting services may require their own authorization record. Review aggregate reports for the exact sending domains and unexplained sources; report delays and receiver coverage mean they are not a complete delivery log. Aggregate-report authorization.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
Do not move a whole school domain to enforcement after one passing broadcast. Account for mailbox sending, other applications, forwarding and all legitimate routes. RFC 9989 additionally discusses valid DKIM and interoperability when publishing a reject policy. DMARC deployment considerations.
Troubleshooting and safe recovery
- DKIM record exists but no school-domain signature appears: confirm Option 2 activation, domain and account with Support. DNS publication alone cannot switch the option.
spe1already belongs to another sender: stop the conflicting change and get a supported selector plan. Do not silently overwrite it.- SPF
permerror: check multiple policies, syntax and nested lookup limits at the actual envelope owner. - DKIM passes but DMARC fails: inspect the passing signature's
d=and the visible From, plus the effective alignment mode. A provider-domain pass may not align. - The From address is unexpectedly provider-owned: compare the selected option and Support confirmation before editing the school DNS again.
- Authentication passes but replies or delayed failures disappear: treat this as an operational acceptance failure, not an authentication failure. Review mailbox ownership and the agreed bounce process.
Fictional example: a broadcast from notice.example.org has aligned DKIM and SPF, but nobody owns delayed-bounce review. Authentication is working; release is still incomplete. Assign the owner and prove the notification path before relying on it for important messages.
For rollback, restore only the approved changed records and supported account configuration. Preserve the school's DMARC policy and unrelated senders. Keep selectors needed for in-flight messages, and obtain Support confirmation before switching options. Do not use a broad recipient allow-list exception to conceal an unresolved authentication defect.
Related route guidance
For a separate forwarded-mail investigation, use the Google Workspace groups and forwarding route guide. Its group and forwarding checks complement a direct Communicate test; they do not activate SchoolMessenger authentication.