ARMS SPF, DKIM and DMARC setup, step by step

Teamworks Compliance + Recruiting, formerly ARMS, uses a support-led email authentication process. Give Teamworks Support the staff email domains and subdomains you want to use, with your IT team's approval. Support configures its SendGrid service and supplies the specific SPF and DKIM DNS records. Your DNS administrator publishes them, then Teamworks checks the setup. Finish with a new message that shows a passing, aligned signature for your domain and dmarc=pass at a trusted receiver. There is no universal ARMS record set to copy. Current Teamworks instructions.

Confirm this is the Compliance + Recruiting sending path

Teamworks' rebrand announcement identifies ARMS as Teamworks Compliance + Recruiting. This guide covers institutional email sent by that product. It does not configure Teamworks Hub, Camps, Nutrition, another Teamworks application, or the unrelated Teamwork.com project-management service. Product continuity.

A staff member's university address in the From field does not mean their Microsoft 365 or Google mailbox sent the message. Establish which application submitted it and which domain recipients actually see. Compliance + Recruiting offers email from individual profiles, selected users in a list, and Quick Links. Treat another application or an automated workflow as a separate route until its authentication is verified. Documented email entry points.

Use a simple inventory before changing DNS:

For example, example.edu and athletics.example.edu should be listed separately in the support request. Do not assume authenticating one provisions the other.

Prepare access, approval and a recovery plan

Have an authorized Compliance administrator coordinate with the institution's DNS and email teams. Identify the authoritative DNS service rather than assuming the domain registrar hosts the records. If a subdomain or _domainkey namespace is delegated, identify the administrator of that delegated zone too.

Export or record the existing DNS values, TTLs, sender settings and effective DMARC policy. Preserve the institution's mailbox MX records, website records, other senders' DKIM selectors and existing SPF authorizations. Agree who can pause affected messages or restore the previous configuration if a change fails.

Reserve an approved test account and mailbox for the later acceptance check. A harmless administrative message is sufficient. Do not use a recruit list, student-athlete records, eligibility details or other personal information to test authentication. No real recipient data or private DKIM key is needed to prepare the DNS request.

Request the account-specific SPF and DKIM records

Use the current Teamworks Support route, selecting Compliance + Recruiting in your request. The documented inputs are staff domains, staff subdomains and confirmation that IT wants the SPF/DKIM setup. Teamworks then configures SendGrid and provides the DNS records. This is not a request to create your own SendGrid account or connect an unrelated one. Support-led implementation.

Ask for these details alongside the supplied record batch:

• The exact DNS type, complete owner name and value or target for each sending domain.
• Which record controls the envelope/bounce domain and which records publish DKIM keys.
• The expected MAIL FROM domain, DKIM signing domain and selectors after activation.
• Whether the configuration covers the specific manual and automated message paths in your inventory.
• Who verifies the records, confirms signing is active and manages future key rotation.

Do not reconstruct values from the old ARMS name, a SendGrid example, another institution's records or a previous tenant. A support response that only says “add SendGrid to SPF” is not enough to identify the owner being changed or the DKIM signing configuration. Request the complete domain-specific batch before proceeding.

Publish the supplied records without changing unrelated DNS

SendGrid supports different authentication arrangements. Its automated-security route uses CNAME aliases to provider-managed SPF and DKIM records; a manual arrangement uses generated MX/TXT records. Teamworks' supplied instructions determine which arrangement applies to your account. Do not switch modes in a separately owned SendGrid account. SendGrid authentication record formats.

For each supplied record:

1. Identify the authoritative zone containing its owner. A DNS edit in an inactive zone will not reach receivers.
2. Inspect that exact name for an existing record. A CNAME must not coexist with ordinary TXT, MX, A or other data at the same owner. If occupied, ask Support and the existing service owner to resolve the conflict rather than deleting it.
3. Enter the owner according to the DNS host's naming convention. Preserve _domainkey and the complete sending subdomain.
4. Copy the value exactly. CNAME targets are hostnames, not URLs. TXT values must retain the complete public record; never place a private key in DNS.
5. Keep authentication CNAMEs DNS only. Do not proxy them through a web CDN or enable flattening that removes the required alias response.
6. Publish every required row in the batch, then independently query the public result before asking Support to verify it.

Consider a structural example only: if Support issues SELECTOR._domainkey.athletics.example.edu, a DNS editor for example.edu that appends the zone needs SELECTOR._domainkey.athletics. An editor for a separately delegated athletics.example.edu zone needs SELECTOR._domainkey. If _domainkey.athletics.example.edu itself is delegated, its administrator enters the selector in that child zone. A full-name editor may instead require the complete owner. Check the resulting FQDN to catch duplicated suffixes.

The bounce/envelope record may belong to a different zone from the DKIM selector. Resolve its ownership independently. Do not create a new delegation merely to follow an example. DNS aliases and zone boundaries.

Where literal CNAME answers are required, the end state is a DNS-only alias returning the exact issued target, without HTTP proxying or flattening hiding it. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings preserve those aliases. On Cloudflare, 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 conditional DNS-host behaviors, not assumed controls in every panel. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.

Handle SPF at the actual envelope domain

SPF authorizes the sending IP against the SMTP MAIL FROM domain. It does not authenticate the visible From address directly, and a root-domain SPF record is not inherited by subdomains. SPF identity and evaluation rules.

If Teamworks supplies a bounce-domain CNAME, publish that alias as instructed. Do not add an SPF TXT record at the same owner or assume a separate root include:sendgrid.net is necessary. If Support supplies a TXT-based SPF instruction, confirm the exact envelope owner before merging it.

There must be one v=spf1 policy per owner, containing all approved senders for that owner. Add an authorized mechanism before the existing terminal all, preserving other mechanisms and the established qualifier. Do not paste a second complete SPF policy alongside the first, remove unrelated authorizations, or replace the existing policy with an example.

If the existing SPF policy uses redirect=, reconcile its authorizations with the DNS owner before changing it. An all mechanism makes redirect ineffective regardless of their order; do not append all as an automatic merge step. SPF qualifiers express authentication results, not a guaranteed receiver delivery or rejection decision. SPF all and redirect processing.

SPF permits at most ten evaluated DNS-querying terms across nested include, a, mx, ptr, exists and redirect. This is not simply ten top-level includes or ten DNS packets. ip4, ip6 and all do not consume that term budget. Separate MX-address and void-lookup limits also apply; RFC 7208 recommends limiting void lookups to two. Evaluate the real sending IP and MAIL FROM path, including dependencies, before accepting an SPF change. Do not manually flatten provider records into a one-time IP list.

A passing SPF result for a provider-owned envelope domain can still be unaligned with the institution's From domain. Adding an include to the institution's root cannot change that identity. Resolve it through the supported sender configuration or use the aligned DKIM path described next.

Retain DMARC policy and check both alignment paths

DMARC passes when at least one of these is true: SPF passes and its envelope domain aligns with From, or DKIM passes and its d= domain aligns with From. An unrelated SendGrid signature passing on its own does not authenticate the institution's From domain for DMARC. Current DMARC standard, RFC 9989.

Under relaxed alignment, compared identities share an organizational domain as determined by DMARC policy discovery. Under strict aspf=s or adkim=s, the corresponding domains must match exactly. For From athletics.example.edu, d=athletics.example.edu meets either DKIM mode; d=example.edu meets relaxed alignment only. These are explanatory examples, not a promise of Teamworks' output.

Inspect _dmarc at the exact From domain and applicable parent-domain policy discovery. Absence of a record at a subdomain does not prove it has no policy. Preserve existing p, sp, np, alignment settings and approved reporting destinations. Do not weaken an inherited policy by adding a child p=none record as a delivery workaround.

Only if no effective policy applies, all relevant senders have been considered and the domain owner approves monitored deployment, a first record may have this shape:

Owner: _dmarc.FROM_DOMAIN
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:APPROVED_REPORT_ADDRESS

For From athletics.example.edu, the policy owner is _dmarc.athletics.example.edu: enter _dmarc.athletics in an appending example.edu zone, or _dmarc in the delegated athletics.example.edu zone. For root From example.edu, enter _dmarc in that root zone. A full-name editor instead uses the complete owner. Replace the placeholders, verify that the reporting mailbox is operational and publish one policy at the correct owner. For reports sent outside the policy domain's Organizational Domain, the reporting service must publish the required external-destination authorization in its DNS. The report-generating receiver must verify that authorization. A destination within the same Organizational Domain as the domain where the policy was found is excepted; a different hostname alone is not an external destination. This check is separate from the institution's approval to share report data. RFC 9990 section 4. Its usual owner is POLICY_DOMAIN._report._dmarc.REPORT_DESTINATION_HOST, containing v=DMARC1; a permitted wildcard authorization may cover the destination. Obtain the service's exact instructions. Adding an authorization record in the sending zone is not a substitute. Reports can expose sending infrastructure and other data, so use an approved destination and do not enable message-level failure reports casually. Aggregate-report authorization and privacy.

p=none requests no DMARC enforcement; it does not guarantee delivery. RFC 9989 replaces RFC 7489 and removes pct, so do not promise percentage-based enforcement rollout. Before changing policy, account for forwarding and mailing lists. Section 7.4 requires valid DKIM for domains publishing p=reject and cautions against reject policies for general-purpose email. This single application setup is not an institution-wide enforcement assessment.

Verify public DNS, then obtain Teamworks confirmation

Run these checks with your actual issued names. They are reader-run examples; no customer DNS was queried for this guide.

dig +short NS AUTHORITATIVE_ZONE
dig @AUTHORITATIVE_NAMESERVER DKIM_OWNER_FQDN CNAME +noall +answer
dig @1.1.1.1 DKIM_OWNER_FQDN CNAME +noall +answer
dig @1.1.1.1 DKIM_OWNER_FQDN TXT +noall +answer
dig @1.1.1.1 MAIL_FROM_DOMAIN TXT +noall +answer
dig @1.1.1.1 _dmarc.FROM_DOMAIN TXT +noall +answer

If Support's approved batch uses the manual MX/TXT arrangement, also check its issued envelope MX owner:

dig @AUTHORITATIVE_NAMESERVER ISSUED_ENVELOPE_MX_OWNER MX +noall +answer
dig @1.1.1.1 ISSUED_ENVELOPE_MX_OWNER MX +noall +answer

Require the complete approved MX set at that exact owner, including each numeric priority and target hostname. These are not instructions to replace the institution's corporate mailbox MX records. Stop if the supplied owner overlaps an existing mail-receiving service until Support and its owner resolve the conflict. Skip this conditional check when the issued batch has no MX records.

Publishing an envelope MX record assigns inbound routing at that specific owner. Before publication, compare its exact priority/target set with the institution's approved bounce-routing plan, not just with a screenshot or packet format. Do not activate an unapproved destination or overwrite an existing mailbox route merely because Support supplied syntactically valid records.

Substitute the authoritative nameserver for each actual zone, not necessarily the same server for every name. Repeat for every DKIM selector and for the envelope record's issued type. Query applicable parent DMARC owners too. A recursive TXT query at a DKIM alias should follow the CNAME chain to a usable public key; an authoritative-only query may return just the alias. Do not paste that provider-managed key back into your zone.

Expected observations are exact owner/target matches, consistent authoritative and public-resolver responses, no CNAME conflicts or duplicate SPF policies, and an intact existing DMARC policy. DNS publication alone does not establish that Teamworks is signing.

Teamworks allows up to 48 hours for DNS propagation and documents a final support testing/confirmation step. Notify Support after publication and request confirmation for every supplied domain. A missing authoritative record is a configuration problem, not something to fix by waiting 48 hours. Teamworks verification process.

Accept the setup only after a delivered-message check

After Support confirms readiness, an authorized administrator should send a harmless message to a controlled test recipient through the exact Compliance + Recruiting path. Repeat for each From domain and material route. Do not trigger a bulk message or a real student workflow solely to test DNS.

Obtain the raw message through the receiving service, then use receiver-controlled authentication diagnostics or a mail trace that identifies the receiver's own results. Alternatively, have the receiving-mail administrator establish the trusted boundary and show how externally supplied Authentication-Results are removed or distinguished from locally generated results. Match the documented authserv-id within that established boundary. Neither the first header nor a familiar string such as mx.google.com proves provenance. If the receiver's result cannot be distinguished from sender-supplied text, do not accept it as commissioning evidence. RFC 8601 section 7.1, forged authentication results.

Accept each route only when the evidence shows:

• The intended visible From domain, with no unexpected rewrite.
• dkim=pass for the intended institutional d= identity and an issued selector, aligned under the effective adkim mode.
• dmarc=pass for the intended From domain.
• The actual smtp.mailfrom identity and SPF result, with every SPF failure or error explained and repaired where applicable.
• Recipient receipt and product behavior confirmed separately from authentication.

A passing aligned SPF result can satisfy DMARC even if DKIM fails, but that does not complete commissioning of a newly requested branded DKIM setup. Likewise, a green application status is not a substitute for a receiver result. Test direct delivery first; then assess forwarding or lists separately. Keep sanitized findings and check subsequent aggregate reports where available. Reports are useful supporting evidence, not a complete census of all recipients.

Troubleshoot and recover safely

If a change disrupts mail, pause only the affected path with the product owner. Restore the recorded prior DNS or sender configuration when that remains valid, coordinating with Support so the signing key and DNS stay matched. Keep old public DKIM records while they are still required for queued or in-flight mail. Do not disable DMARC, blanket-allow all SendGrid traffic or delete other services' records as a shortcut. Retest the repaired path before resuming normal volume.

Documentation and verification boundary

This guide is based on current Teamworks, SendGrid, DNS-provider and protocol documentation. No customer account was configured, DNS changed, message sent, delivered header inspected or live implementation tested in preparing it. Authentication reduces impersonation risk but does not guarantee inbox placement.