How to set up DMARC/DKIM/SPF for Gaggle
Published 30 Jun 2026
Updated 2 Nov 2026
12 min read
Summarize with
Updated on 2 Nov 2026: We clarified Gaggle's account-specific DNS setup, added alert-delivery checks, and revised DMARC enforcement guidance for RFC 9989.
For Gaggle, first confirm whether it sends with your school or district domain. If it does, publish the SPF, DKIM, or return-path records supplied for your account, then publish DMARC at _dmarc with aggregate reporting enabled. Start with p=none unless your domain already uses p=quarantine or p=reject.
When Gaggle supplies custom-domain DNS values, treat them as account-specific. Do not copy another district's SPF include, DKIM selector, or bounce domain. Copy your assigned records, publish them in DNS, send a real Gaggle message, and confirm that SPF or DKIM passes with DMARC domain alignment.
Confirm whether Gaggle sends with your domain
Add your school or district domain only when your Gaggle service sends mail using that domain, such as alerts or notifications. If Gaggle only monitors accounts in your existing school email system, do not add Gaggle to SPF. Request the authentication values and supported custom-domain options for your service through Gaggle onboarding or support.
Illustrative Gaggle domain verification screen with a DNS TXT record.
- Confirm scope: Check whether Gaggle sends with your domain, only monitors student accounts, or does both. Receiving Gaggle alerts at a district address does not mean Gaggle sends as your domain.
- Get assigned values: Request the required DNS records through Gaggle onboarding or support. Use account settings only when your service actually provides them.
- Confirm the From domain: Inspect the visible From address of a real notification. The recipient address, display name, and Reply-To address do not determine the domain DMARC evaluates.
- Publish DNS: Create each verification or authentication record exactly as supplied, including its host name, record type, and full value.
- Verify sending: After DNS propagation, use any verification action provided and confirm the result with a delivered Gaggle message.
Gaggle monitors only
- DNS change: Do not add a Gaggle SPF include when Gaggle does not send mail as your domain.
- DMARC data: Expect reports for the systems that send your district mail, not Gaggle as a sending source.
- Next step: Verify authentication for the systems that actually use your district domain in the From address.
Gaggle sends mail
- DNS change: Publish only the SPF, DKIM, or return-path records provided for your Gaggle account.
- DMARC data: Look for Gaggle-originated traffic after messages using your domain begin reaching receivers that send reports.
- Next step: Send a real alert or notification and inspect its authentication results and domains.
Do not guess Gaggle records
Do not assume a universal Gaggle SPF include or DKIM selector. Ask Gaggle support at support@gaggle.net which records apply to your service and which domain each record authenticates. The screen illustrations do not establish that your account has those settings.
Set up SPF
SPF authenticates the domain in the envelope sender, commonly shown as the Return-Path, rather than the visible From address. If Gaggle provides a custom return path, publish its DNS records so the SPF-authenticated domain can have DMARC alignment with your From domain.
- Find the SPF value: Copy the exact SPF include, IP authorization, or delegated return-path value supplied for your account.
- Use the correct host: Publish or merge SPF at the exact MAIL FROM domain. Add Gaggle to the root SPF record only when the supplied instructions require it.
- Keep one SPF record: Each hostname can have only one SPF TXT record. Insert new authorization before the existing all mechanism and preserve the other approved senders and the intended ending policy.
- Check lookups: SPF allows at most 10 DNS-querying mechanisms and modifiers per evaluation, including nested includes and redirects. Exceeding that limit produces permerror; it is not a limit of 10 authorized senders.
SPF and return-path patterns, not publishable recordsdns
# Use only the host and record type assigned by Gaggle. <assigned-mail-from-domain>. TXT "v=spf1 include:<assigned-spf-host> ~all" # Alternative: publish CNAME delegation only if Gaggle supplies it. <assigned-bounce-host>. CNAME <assigned-return-path-target>
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
After publishing, check the live SPF record at every hostname Gaggle uses. A hostname delegated by CNAME must not also have an SPF TXT record. If the SPF check exceeds the lookup limit, remove obsolete senders or use Suped's hosted SPF workflow to keep the record valid.
When SPF is unaligned
An SPF pass does not satisfy DMARC when the authenticated MAIL FROM domain lacks alignment with the visible From domain. DMARC can still pass through a valid DKIM signature with domain alignment, but configure Gaggle's custom return path when one is supplied.
Set up DKIM
Aim for an aligned DKIM pass on every Gaggle message. DKIM commonly survives forwarding better than SPF and gives DMARC a reliable pass path when the signing domain has alignment with the visible From domain.
Illustrative Gaggle DKIM setup screen with selector and CNAME record fields.
- Copy the selector: If your Gaggle service supports custom-domain DKIM, use the exact selector assigned to your account.
- Create DNS: Publish the DKIM TXT or CNAME record at the host shown in your setup details. Gaggle retains the private signing key; publish only the public key or CNAME it supplies.
- Keep the host exact: Do not add the root domain twice if your DNS provider appends it automatically. For a CNAME, use DNS-only resolution and disable flattening when the verification process requires the CNAME itself.
- Verify with a message: After DNS propagation, use any available verification action, confirm signing is enabled with Gaggle, and send a live message to check its signature and signing domain.
DKIM pattern, replace selector and targetdns
<selector>._domainkey.example.com. CNAME <gaggle-dkim-target> # If Gaggle gives TXT instead, publish the full TXT value it provides.
DKIM gives a resilient DMARC path
A Gaggle message passes DMARC through DKIM when the signature validates and its signing domain has DMARC alignment with the visible From domain. Verify both the DKIM result and the domain relationship before tightening policy.
Set up DMARC
DMARC belongs in your domain's DNS, not inside Gaggle. Publish it at _dmarc.example.com so receivers can report whether Gaggle and every other sender passes SPF or DKIM with domain alignment. RFC 9989 is the current DMARC standard, but the record version remains v=DMARC1. If the visible From domain is alerts.example.com, check _dmarc.alerts.example.com and any inherited policy before publishing a separate record.
Starter DMARC recorddns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
- Start safely: Use v=DMARC1; p=none; rua=mailto:dmarc@example.com for a new monitoring rollout. Replace the example address with a working report destination.
- Keep enforcement: If your domain already uses p=quarantine or p=reject, do not downgrade it just to onboard Gaggle. Fix Gaggle's authentication before sending production mail.
- Generate the record: Use the DMARC record generator to build a record with the intended policy and reporting address.
- Prepare reporting: Use a dedicated address or Suped report destination that can receive and parse aggregate XML. If the rua address uses another domain, confirm that domain authorizes the external report destination in DNS.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Run the check after DNS propagation and confirm the policy, reporting address, and syntax are valid. A valid DMARC record does not prove Gaggle passes, so follow it with a real message test.
Do not publish two DMARC records
Multiple DMARC TXT records at the same hostname are invalid. RFC 9989 discards them during policy discovery. Edit the existing record instead of adding another one.
Use current DMARC rollout tags
RFC 9989 replaced RFC 7489 in 2026. It removed the pct tag and added t for policy testing. RFC 9990 now defines aggregate reporting, while RFC 9991 defines message-specific failure reporting.
|
|
|
|---|---|---|
p | Current | Set none, quarantine, or reject as the domain owner's handling preference. |
t | Current | Use y to request that receivers not apply an enforcement policy. This is not percentage sampling. |
pct | Historic | Do not use it for a new rollout because RFC 9989 removed percentage sampling. |
rua | Current | Request aggregate reports under the format defined by RFC 9990. |
Use current tags and account for receiver compatibility.
Testing request, receivers that ignore t=y can enforce quarantinedns
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"
Do not rely on t=y to prevent enforcement
A receiver that ignores t=y can enforce the published p=quarantine policy. Use p=none when your rollout depends on requesting no DMARC enforcement.
Verify and troubleshoot Gaggle authentication
Verification needs a real Gaggle message, not only DNS lookups. Send the exact type of Gaggle email you care about, then check the receiving mail system's trusted Authentication-Results header for SPF, DKIM, DMARC, and the domains used by each result.
Illustrative Gaggle notification test screen with sender and delivery details.
- Header From: Confirm the actual sending domain. If it is Gaggle's own domain, your district's DMARC policy is not evaluated for that message.
- Return-Path: For relaxed SPF alignment, its domain must share the same organizational domain as the visible From domain. Strict alignment requires an exact match.
- DKIM domain: The d= domain must share the same organizational domain under relaxed alignment, or match the From domain exactly under strict alignment.
- DMARC result: A pass means at least one authenticated SPF or DKIM domain also has the required alignment with the visible From domain. Relaxed alignment is the default; aspf=s and adkim=s request strict checks for SPF and DKIM respectively.
Passing Authentication-Results header patterntext
From: District Alerts <alerts@example.com> Return-Path: <bounces@bounce.example.com> Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com header.s=selector1; dmarc=pass header.from=example.com
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
|
|
|
|---|---|---|
SPF | Pass plus MAIL FROM alignment | Check the SPF host, authorization value, and return path. |
DKIM | Pass plus d= alignment | Check the selector record, signature, and signing domain. |
DMARC | Pass through SPF or DKIM | Compare the authenticated domains with the visible From domain. |
Policy | Matches the planned rollout stage | Change policy only after approved sources pass consistently. |
Use this table after a Gaggle test message lands.
If DKIM passes but DMARC fails, the passing signature's domain lacks alignment with the visible From domain. If SPF passes but DMARC fails, the MAIL FROM domain lacks alignment. If both fail, compare the supplied DNS values with the live records and check for forwarding or message changes before assuming DNS is the cause.
Check DNS at the authoritative provider and allow cached answers to expire according to their TTL before retesting. Use these lookups with your actual domain and selector; a CNAME-based DKIM setup also needs its target to resolve to a valid key.
Check published authentication recordsbash
dig TXT example.com +short dig CNAME selector1._domainkey.example.com +short dig TXT selector1._domainkey.example.com +short dig TXT _dmarc.example.com +short
Test Gaggle alerts through district mail routing
Authentication passing does not guarantee inbox delivery. Gaggle's service agreement requires districts to keep designated emergency contacts current and reachable. Test the route those contacts actually use, including any distribution group or forwarding address.
- Arrange a test notification with Gaggle onboarding or support, and confirm the intended district recipients before sending it.
- Check both a direct staff mailbox and the distribution group or forwarded destination used for alerts. Forwarding can break SPF, and message changes can invalidate DKIM.
- If delivery fails, trace the Message-ID and send time through your receiving mail system. Inspect the SMTP response or quarantine reason to distinguish authentication failures from routing or filtering problems.
- Send Gaggle support the failed message's headers and delivery error. If it uses Gaggle's own From domain, ask Gaggle to correct its authentication rather than adding its servers to your district SPF record.
Repeat this test after changing alert recipients or mail routing. Keep the working delivery result with the district's authentication records so the next DNS owner can repeat the same check.
Monitor Gaggle authentication failures
Gaggle authentication can break after a DNS cleanup, domain migration, sender setting change, or DKIM selector rotation. Suped, our DMARC reporting and email authentication platform, provides DMARC monitoring to group aggregate reports by sending source and flag authentication changes before you tighten enforcement.
- Watch sources: Match suspected Gaggle traffic to test-message headers and support-provided sending details. Shared sending infrastructure does not identify Gaggle by itself.
- Catch failures: Alert on authentication failure increases, then inspect whether an authenticated domain still matches the visible From domain.
- Fix DNS: Trace failures to missing records, duplicate SPF records, lookup-limit errors, or domain-matching problems.
- Retest after changes: Send another Gaggle notification after a DNS edit or selector rotation and compare it with the next aggregate reports.
Aggregate reports are delayed
Suped's report-based alerts depend on fresh receiver data. Aggregate reports are generally daily, and not every receiver sends them. Use message tracing for an individual missing alert; report counts are not delivery confirmations.
Choose a DMARC enforcement policy
Choose enforcement after Gaggle and every approved sender pass DMARC consistently. RFC 9989 advises against p=reject for general-purpose email domains because legitimate indirect mail can fail DMARC. Test forwarding and mailing lists before changing a district-wide policy.
DMARC policy choices
Use representative report data and delivery tests to choose a policy appropriate to the domain.
Observe
p=none
Collect a complete normal sending cycle, including Gaggle alerts and low-volume school systems.
Quarantine
p=quarantine
Use after approved senders pass and indirect delivery routes have been tested.
Reject
p=reject
Consider for controlled sending domains after testing indirect delivery routes.
- Inventory senders: List Gaggle and every school system that uses the domain in its visible From address.
- Fix failures: Ensure each approved sender has at least one passing SPF or DKIM result with DMARC domain alignment. One failing method does not cause a DMARC failure when the other provides a valid pass path.
- Test enforcement: Validate low-volume senders and forwarded alerts before changing policy. Do not rely on t=y to prevent delivery failures at receivers that ignore it.
- Choose scope: Consider a dedicated alert subdomain when supported by Gaggle, with a policy chosen for that sending use. Keep an owner responsible for new sender requests.
Optional reject policy for a tested alert subdomaindns
_dmarc.alerts.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
How Suped supports enforcement
In Suped, hosted DMARC lets the domain owner change policy after the initial DNS setup. Use aggregate reports to check approved senders before and after each change.
FAQ
Use only the SPF or return-path DNS values assigned to your Gaggle account. Publish them at the specified hostname. Merge SPF authorization into the existing SPF record; if Gaggle instead supplies a CNAME delegation, do not add an SPF TXT record at the same hostname.
Use DKIM whenever Gaggle provides it. DKIM commonly survives forwarding better than SPF and gives DMARC another pass path when the signing domain has alignment with the visible From domain.
Start a new rollout with p=none. Keep existing enforcement while fixing Gaggle's authentication. RFC 9989 advises against p=reject on general-purpose email domains; test indirect delivery before choosing enforcement.
No Gaggle SPF or DKIM authorization is needed when it only monitors accounts and does not send using your domain. Authenticate the systems that actually use your domain in the visible From address.
The passing DKIM signature usually uses a signing domain without DMARC alignment to the visible From domain. Compare the header.d value with the From domain under your relaxed or strict alignment setting, then correct the custom-domain setup.
No. RFC 9989 removed pct and introduced t=y for policy testing. A receiver that ignores t=y can enforce the published policy, so use p=none when you need to request monitoring without enforcement.
