Treat MarchingOrder as a current Tassel implementation
MarchingOrder has been renamed Tassel; its first-party rebrand FAQ identifies the current administration site as the Tassel Hub. This is a product-identity bridge, not permission to reuse every historical MarchingOrder DNS recipe. Establish which institution, ceremony, Hub account and communication workflow are in scope before changing the institution's domain. Tassel Rebrand FAQ.
The retained authentication guide, updated September 2, 2026, states that Tassel moved email delivery to Postmark. Every sending domain must be registered and verified. Standard setup no longer needs the old Elastic Email SPF addition, and generic tassel.com sender addresses are no longer available. Current email authentication guide.
This matters during a ceremony deadline. An old setup document may be internally consistent yet describe a route that the institution is leaving. Ask the Implementation Manager to confirm the migration state of the exact institution. Do not infer completion from the rebrand, from a DNS record that still exists, or from an old message that was delivered before the change. Keep the historical route and target route separately identified until the transition is approved.
Assign responsibility before the ceremony deadline
Give the commencement team ownership of message purpose and recipient selection, central IT ownership of DNS, and a mail-security reviewer ownership of identity evidence. Record the next important send date and the earliest safe test window. This is an original operational recommendation intended to keep a deliverability change from becoming an accidental announcement to the graduating class.
Inventory active templates and ad-hoc sender choices by ceremony. Record the exact From domain, who monitors replies, and which templates were inherited from a prior year. A university domain and an alumni subdomain are different configuration targets. Also note any scheduled communications outside the immediate ceremony so the change does not unexpectedly interrupt another team. Retain the previous records and template settings in a restricted change log before editing anything.
Request and publish the domain-specific record set
Provide the intended domains to the Implementation Manager and obtain Tassel's generated records. Publish the required DKIM TXT host and public value exactly as supplied. Do not copy a selector or key from another institution or an older configuration. Notify the manager after publication and wait for provider verification; the guide allows up to 48 hours. Tassel domain-verification process.
The change request should have a separate row for each DNS owner, type, value, zone and responsible administrator. Confirm that the DNS console has not appended the zone twice. Compare the complete public key after saving it rather than trusting a truncated visual preview. If the requested owner already exists, investigate which service uses it before replacing anything. An unexplained conflict is a reason to stop that record change, not a reason to overwrite institutional mail settings.
Tassel strongly recommends its custom return-path: pm-bounces.<registered-sending-domain> as a CNAME to pm.mtasv.net. Confirm the supplied host for the institution. Keep previous Tassel records until the Implementation Manager confirms transition and advises what can be removed. Current Tassel setup and migration instructions.
Understand why the return-path differs from the From address
Postmark's infrastructure documentation explains that the return-path collects bounces and delivery feedback. Its customer-domain CNAME preserves that processing while enabling a customer envelope identity. This supports the mechanism described by Tassel; it does not imply that the institution should create a separate Postmark account or bypass its Implementation Manager. Postmark custom return-path explanation.
A CNAME owner cannot also be populated with an independent SPF TXT record in an ordinary configuration. Postmark specifically says that its custom return-path CNAME handles the relevant SPF path, so adding a root-domain include is not an equivalent replacement. Its documented subdomain arrangement provides relaxed SPF alignment, not exact strict equality with a parent From domain. Keep the institution's existing policy and evaluate aligned DKIM when strict SPF alignment cannot be met. Postmark SPF setup and alignment.
Do not interpret the provider's green verification as a universal delivery guarantee. SPF authenticates the envelope identity, DKIM authenticates the signature's d= identity, and DMARC compares a passing identity with the visible From domain. A policy can remain valid while an individual message is unaligned. Review the receiver's result under the actual domain policy. SPF, DKIM and DMARC.
Test the Hub workflow with a controlled population
The Communications module provides the Send Email workflow: choose a population, load a template, review the recipient total and send. Loading a template populates Sender Email, Subject and Message. Check those fields after loading the template, not only before it. The View Sent Emails area and Details expose message activity and bounces. Sending an Email.
For acceptance, use an institution-approved test record or controlled test population. Before activating Send Now, verify the actual count and addresses with the commencement owner. Never select the real class merely to test DNS. Put a distinctive harmless identifier in the subject so an operator can match the application entry to the received message without exposing graduate records. Confirm the reply destination separately; a valid signature will not route a graduate's question to the right office.
If staff send from the Graduates module, test that entry point too. Its documented sequence includes selecting the ceremony and population before handing the message into Communications. A previously successful send from another ceremony does not prove that the currently selected template has the right sender. Sending from the Graduates module.
Diagnose the exact failure before retrying
Separate three conditions in the incident log: the Hub did not submit the message, the remote system rejected it, or the controlled mailbox received it with an authentication failure. Start with the approved domain mapping and provider verification state for a no-send condition. For a received failure, preserve the original message before asking anyone to alter the route. A screenshot of an empty inbox cannot tell these cases apart.
For a return-path verification problem, compare the publicly returned CNAME with the assigned host and destination. Postmark's troubleshooting guidance identifies duplicated domain suffixes, malformed destination values and a proxied Cloudflare CNAME as possible causes. Give central IT the observed answer and the provider's expected value; do not change unrelated security controls. Escalate unresolved publication or verification problems through Tassel rather than guessing at a replacement domain. Return-path verification troubleshooting.
If an urgent ceremony email cannot be sent, have the business owner choose an already approved alternative communication channel. Do not silently substitute a generic provider address or retry the whole class after a partial send. Reconcile the sent population first, then authorize a limited retry of the failed group. Preserve the institution's DMARC enforcement and avoid broad allowlisting as a substitute for fixing identity.
Retain an original acceptance table and migration decision
No live acceptance test was performed for this manuscript. The original received-message identity table must contain institution and account reference, ceremony, workflow, template, timestamp, visible From, Reply-To, Return-Path, trusted receiver SPF domain/result, every DKIM d=/s= and result, DMARC result, policy alignment modes and the restricted original-message location. Add a separate functional result for reply delivery and correct recipient selection.
Keep provider verification, DNS publication, original-message evidence and migration completion as distinct approvals. Retire old trust only after confirming that no active route still relies on it and receiving the provider's transition guidance. Record what was removed and why, then repeat a controlled send after the cleanup. This gives the next ceremony team a usable record rather than a copied historical key.
The product transition is documented, but this institution's account, live DNS, actual migration state and received identities remain unverified. Exact-route confirmation, the completed original identity table and human SME approval remain required. This unpublished candidate must not be presented as proof that any current or legacy MarchingOrder tenant has passed.
Preserve a ceremony-specific release decision
The proposed acceptance record has four separate approvals: the provider confirms the institution’s migration and domain state; IT verifies the issued records; the communications owner confirms template sender and controlled population; the mail reviewer checks the received identity row. If any approval is missing, use only an already approved business continuity option chosen by the owner. A neighboring ceremony’s success cannot fill the missing row.