MarchingOrder SPF, DKIM and DMARC setup, step by step

For current Tassel Hub email, formerly MarchingOrder, obtain your domain-specific DKIM TXT record from Tassel, publish it, and wait for Tassel to confirm verification. Add the recommended custom Return-Path CNAME, pm-bounces.<registered-sending-domain> to pm.mtasv.net. The standard Postmark-based setup does not require an SPF edit. Keep legacy records until your Implementation Manager confirms migration and identifies what can be removed. Tassel authentication guide.

No institution's account, DNS, migration or email delivery was changed or tested for this guide. Examples use reserved domains; replace placeholders with your institution's approved values.

Confirm the Hub, ceremony and sending domain

MarchingOrder became Tassel, and its administration product is the Tassel Hub. The name change alone does not establish an institution's delivery migration status. Tassel rebrand FAQ.

This guide covers institutional messages sent through the Hub's Communications workflow, including messages initiated from Graduates. It is not a prescription for a separate Postmark account, staff mailbox or another Tassel product.

Before requesting records, have the commencement team and central IT agree on:

• The institution, Hub account, ceremonies and production or test environment.
• Every intended From domain, including alumni or commencement subdomains.
• The templates, ad-hoc sends and scheduled communications that use those domains.
• The owner of DNS, the monitored reply address and the person approving a controlled test population.
• The next important ceremony send and a change window that leaves time to investigate failures.

Save the existing DNS and template settings in the institutional change record. Do not schedule a migration immediately before a class-wide announcement. A correct DNS change cannot repair a template that selects the wrong sender or recipient population.

Obtain and publish the domain-specific records

Send any new sending domains to your Implementation Manager. Each domain needs separate registration and verification; established customers should confirm Tassel's existing domain list. Tassel supplies the DKIM host and value. Domain registration and records.

Prepare a change worksheet with the full DNS owner, record type, exact value, authoritative zone, record owner and rollback value. The following is a shape, not a ready-to-paste DNS package:

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Purpose: Required domain-specific DKIM
Type: TXT
Owner: <Tassel-issued-selector>._domainkey.<registered-sending-domain>
Value: <complete public DKIM value supplied by Tassel>

Purpose: Recommended custom Return-Path
Type: CNAME
Owner: pm-bounces.<registered-sending-domain>
Target: pm.mtasv.net.

Publish the DKIM TXT record

1. Find the authoritative DNS zone. The registrar, Microsoft 365 tenant and authoritative DNS host can be different organizations.
2. Enter the issued host in the form your DNS console expects. For a zone named example.com, an owner such as issued-selector._domainkey.commencement.example.com might require the relative name issued-selector._domainkey.commencement. Do not assume the console accepts a full name without appending the zone.
3. Paste the complete public value. Never generate a replacement key or reuse a selector from a prior ceremony's instructions. Publish no private key.
4. Compare the saved record with the issued package. Multiple quoted character strings can form one TXT record; their concatenation must preserve the key without added spaces. Multiple separate TXT records are not a safe way to split one key. DKIM DNS representation.
5. If the requested owner is occupied, stop and establish which service owns it. Adding a new selector does not authorize replacing another application's selector or delegating the entire _domainkey namespace.

Publish the custom Return-Path CNAME

For a registered sending domain of commencement.example.com, the documented name becomes pm-bounces.commencement.example.com. Check the package before publication. Use the CNAME target as a hostname, without a URL scheme or path.

Do not place an SPF TXT, MX or address record alongside a CNAME at that same owner. Resolve an existing-record conflict with its owner instead of deleting it. A CNAME at a dedicated bounce name does not authorize changing the institution's root MX or mailbox-provider SPF. CNAME rules.

The Return-Path CNAME must be DNS-only and unflattened so the expected alias is returned. In Cloudflare, check that Flatten is off for this record and CNAME flattening for all CNAME records is off in the zone settings. DNS-only alone is not sufficient; when zone-wide flattening is enabled, the per-record setting cannot override it. Have the DNS owner assess other applications before changing a shared zone setting. If a child zone is delegated, publish at its actual authoritative provider and preserve that delegation; do not remove NS records merely to make verification pass. Cloudflare CNAME verification, flattening settings.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Postmark uses the Return-Path to process bounces. Its documentation explains the CNAME mechanism, but Tassel remains responsible for this Hub configuration. Do not create an independent Postmark domain or switch the alias without coordinating with Tassel. Postmark custom Return-Path.

Why the existing SPF policy stays in place

SPF normally evaluates the SMTP MAIL FROM domain, which appears in the delivered Return-Path, not the visible From address. Postmark's default envelope domain has its own SPF authorization; a custom Return-Path provides the branded envelope path through the CNAME. Adding a Postmark include to an unrelated root-domain policy does not configure that path. Postmark SPF behavior.

Consequently, leave the institution's existing mailbox and other application authorizations intact. Do not paste a second v=spf1 policy into the same owner. If an independently justified SPF change is needed, amend the single existing policy at the actual evaluated owner, preserving its other senders and intended final qualifier.

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.

SPF permits at most ten evaluated DNS-dependent terms, including nested evaluations: include, a, mx, ptr and exists mechanisms, plus the redirect modifier. This is not simply a count of visible includes or DNS packets. Exceeding the limit produces permerror; ip4, ip6 and all do not consume that term budget. RFC 7208, DNS lookup limits.

Distinguish an unaligned SPF pass from an actual SPF failure. A provider-domain pass can be legitimate yet not help DMARC for an institutional From address. fail, softfail, neutral, none, temperror and permerror need their own diagnosis against the observed envelope identity and connecting IP. Do not dismiss a genuine SPF error merely because DKIM rescued DMARC.

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.

Complete Tassel verification and update templates

Notify the Implementation Manager after publication. Tassel checks the records and confirms readiness; allow up to 48 hours. Only verified institutional domains can be used, and generic Tassel sender addresses are no longer supported. Update templates accordingly. Verification and permitted sender addresses.

Treat provider verification as one acceptance step, not the end of the job. Record its date and the exact domain. Then review every in-scope template and any scheduled message before the next send. Loading a Hub template fills the Sender Email, Subject and Message fields, so inspect the sender after loading it. Hub sending workflow.

Keep separate evidence for DNS publication, provider verification, delivered-message authentication and legacy-route retirement. One green status cannot substitute for the other three.

Verify public DNS from outside the institution

These are reader-operated checks, not results obtained for your domain. Use the exact issued selector. example.com and issued-selector below are illustrative. For a delegated child zone, query that child's authoritative nameservers rather than assuming the parent hosts it.

dig +short NS example.com
dig @<authoritative-nameserver> TXT issued-selector._domainkey.commencement.example.com
dig @<authoritative-nameserver> CNAME pm-bounces.commencement.example.com
dig @1.1.1.1 +short TXT issued-selector._domainkey.commencement.example.com
dig @1.1.1.1 +short CNAME pm-bounces.commencement.example.com
dig @1.1.1.1 +short TXT pm-bounces.commencement.example.com
dig @1.1.1.1 +short TXT _dmarc.commencement.example.com
dig @1.1.1.1 +short TXT _dmarc.example.com

Expected observations:

• The authoritative and public answers identify the intended owner. Reassembled DKIM text exactly matches the public key Tassel issued.
• The bounce owner returns pm.mtasv.net. as its CNAME. A recursive TXT lookup can follow that alias to the provider's SPF policy; it does not mean a local TXT record should be added at the CNAME owner.
• The policy owner and effective DMARC policy are understood. No direct child record does not necessarily mean no DMARC policy applies. The two example DMARC lookups are useful inspection points, not a complete implementation of RFC 9989 policy discovery.

If authoritative and recursive answers differ, record the TTLs and query times. A timeout or SERVFAIL is not evidence that a record does not exist. A blank answer warrants checking the owner, delegation and authoritative zone before waiting indefinitely.

Test the actual ceremony workflow and DMARC alignment

Use approved test records and controlled external mailboxes. Do not select a real graduating class as a DNS test. In Communications, select the test population, load the intended template, verify its sender, and use Review Recipient Total before the authorized send. If staff initiate mail from Graduates, repeat that route for the correct ceremony. Communications instructions, Graduates instructions.

Match the received message to the Hub activity using a harmless unique subject, timestamp and message reference. Preserve the original message in restricted storage. Use View Sent Emails and Details for application activity and bounces, while checking the receiving mailbox separately. Do not publish student names, addresses, message IDs or content in public header analyzers.

Use receiver-controlled security diagnostics, or have the receiving mail administrator establish which Authentication-Results fields come from its trusted infrastructure and how the inbound boundary removes or disregards externally supplied results. An authserv-id matching the receiver or a plausible header position is not sufficient proof: a sender can forge those details. If provenance cannot be established, do not accept the setup from that header alone. Obtain the receiving administrator's verified result for the same message. Authentication-Results trust boundary, forged-header protections.

Record one row for every tested ceremony, workflow and From domain:

• Visible From, Reply-To and Return-Path.
• Trusted SPF result, smtp.mailfrom domain and connecting IP.
• Every DKIM signature's d= signing domain, s= selector and verified result.
• Trusted DMARC result and header.from domain.
• Effective adkim and aspf modes, plus correct recipient selection, replies and bounce handling.

Accept the setup only when the intended institutional DKIM signature passes and aligns, and the trusted receiver reports dmarc=pass for the intended From domain. An unrelated provider signature, a DNS key alone or a DMARC pass supplied only by SPF does not prove this DKIM setup works. A missing or failing DMARC result remains unresolved even when your manual domain comparison appears aligned.

DMARC needs at least one passing, aligned mechanism. Relaxed alignment compares Organizational Domains; strict alignment requires exact domain equality. Omitting adkim or aspf means relaxed alignment for that mechanism. With From commencement.example.com and envelope pm-bounces.commencement.example.com, the documented subdomain design supports relaxed SPF alignment, not strict equality. Confirm the actual policy and receiver result rather than changing aspf=s simply to obtain a green check. An exactly matching, valid institutional DKIM signature can satisfy strict DKIM alignment. Current DMARC standard, Postmark alignment limits.

Repeat across the real template and workflow combinations. A pass for one ceremony does not certify the others, and successful authentication does not guarantee inbox placement.

Preserve DMARC policy, reporting and migration safety

Keep the institution's established policy and reporting destinations. Do not replace p=reject with p=none to work around a failing ceremony send, add a duplicate DMARC record, or create a child policy merely to override inherited enforcement. Locate the effective policy first. A new monitored policy is a separate domain-owner decision only when no established applicable policy exists.

Only when no direct or applicable inherited policy exists and the domain owner approves initial monitoring, an illustrative first record is TXT with value v=DMARC1; p=none. This requests no reports by itself; add rua only for a provisioned, approved destination after checking the reporting rule below. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

Reports should go only to an approved mailbox or reporting service. An external aggregate-report destination requires authorization at the destination under the current reporting specification. Do not copy a demonstration rua address or enable message-level failure reports without reviewing their privacy implications. RFC 9990, external destinations, DMARC privacy considerations.

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.

For universities, alumni forwarding and mailing lists deserve particular attention. RFC 9989 warns about indirect-mail interoperability and requires domains publishing p=reject to apply valid DKIM rather than relying solely on SPF. One successful direct test is not a domain-wide enforcement recommendation. DMARC interoperability considerations.

Retain former-provider records through the transition. After Tassel confirms migration, reconcile all ceremonies and scheduled sends, obtain record-owner approval, and remove only records confirmed unused. An Elastic Email authorization may also serve another application. Recheck the affected routes after approved cleanup, and keep the previous values available for a coordinated rollback. Removing the new DKIM record is not a safe general rollback while new-route mail is active.

Troubleshooting and recovery

The Hub does not send at all

Check the loaded template's From domain and Tassel's verification state. A stale template may select an unverified domain or an unsupported generic address. Distinguish a message that was never submitted from one accepted by the outbound system but rejected downstream. Obtain the exact application error before changing DNS.

DKIM remains unverified

Compare the full owner and key against Tassel's package. Look for a duplicated domain suffix, truncation, unexpected whitespace, the wrong authoritative zone or a selector belonging to an older route. Preserve an unexplained existing selector rather than overwriting it. Escalate the expected and observed answers to Tassel support.

The Return-Path does not verify

Check both sides of the CNAME. A destination such as pm.mtasv.net.example.com is wrong. Use a fully qualified target in the form the DNS host requires. Postmark also identifies a proxied Cloudflare record as a verification problem; this mail-authentication CNAME must resolve as DNS, not through a web proxy. Return-Path troubleshooting.

DNS looks correct but the message fails

If the intended signature is absent, check activation and the actual template/route with Tassel. If it is present but fails, investigate key mismatch, stale DNS or changes to signed content. If DKIM passes but is unaligned, compare d= with From and the effective adkim mode. For genuine SPF errors, examine the actual envelope policy separately. Preserve the original receiver evidence and exact rejection, then retest the same route after correction.

Some recipients received the message before a failure

Reconcile the sent and failed populations before retrying. Do not resend the whole class automatically. The communications owner should authorize any limited retry or already approved alternative channel. Do not bypass authentication through broad allowlisting or weaken institutional policy to meet the ceremony deadline.

Related setup guidance

If you administer a separate Postmark account, use the Postmark SPF and DKIM guide for that route. For a still-active independent legacy sender, consult the Elastic Email guide. Neither replaces Tassel's migration confirmation.