What SPF record should I use for Gaggle?

Use the SPF include or return-path DNS values shown in your Gaggle account or onboarding instructions. Do not copy a public sample from another domain because Gaggle records can be tenant-specific.

Does Gaggle need DKIM if SPF already passes?

Yes. DKIM should pass for Gaggle because DKIM handles forwarding better than SPF and gives DMARC a reliable pass path when the signing domain matches your From domain.

Should I use p=none, quarantine, or reject for Gaggle?

Use p=none for a new DMARC rollout, keep quarantine or reject if your domain already uses enforcement, and move to reject only after Gaggle and all other approved senders pass consistently.

Which platform sends email with rDNS ending in gaggle.net?

Treat rDNS ending in gaggle.net as a likely Gaggle sending source, then confirm with the message headers, the DKIM selector, the return path, and your Gaggle delivery logs.

Why does Gaggle pass DKIM but fail DMARC?

The usual cause is a DKIM signing domain that does not match the visible From domain. Ask Gaggle to sign with your domain or the correct organizational domain, then retest.

Learn

DMARC

How to set up DMARC/DKIM/SPF for Gaggle

Matthew Whittaker

Co-founder & CTO, Suped

Published 30 Jun 2026

Updated 30 Jun 2026

9 min read

Summarize with

How to set up DMARC, DKIM, and SPF for Gaggle.

For Gaggle, set up SPF with the Gaggle-provided SPF include or return-path records, set up DKIM with the selector values Gaggle gives your district, then publish DMARC at _dmarc with reporting enabled. I would start with p=none unless your domain already uses p=quarantine or p=reject.

Gaggle DNS values are tenant-specific, so do not copy another district's SPF include, DKIM selector, or bounce domain. The reliable workflow is to copy the records from Gaggle, publish them in DNS, send a real Gaggle message, and confirm that SPF or DKIM passes with DMARC domain matching.

Add your domain

Add your school or district domain in Gaggle only when Gaggle sends mail using that domain, such as alerts, notifications, or parent-facing messages. If Gaggle only monitors accounts and never sends as your domain, keep Gaggle out of your SPF record and verify the mailbox provider instead.

Gaggle admin domain verification screen with DNS TXT record details.

Confirm scope: Check whether Gaggle is sending with your domain, only monitoring student accounts, or doing both.
Open settings: In Gaggle, go to the district admin area and open the domain, sender, or email authentication settings.
Add domain: Enter the domain used in the visible From address, such as example.com, not a mailbox address.
Publish TXT: Create the verification TXT record exactly as Gaggle shows it, including the host name and full value.
Verify: Use Gaggle's Verify action after DNS propagation, then leave the record in place unless Gaggle says it can be removed.

Gaggle monitors only

DNS change: Do not add a Gaggle SPF include when Gaggle does not send mail as your domain.
DMARC data: Expect normal reports for your mailbox provider, not Gaggle as a sending source.
Next step: Verify authentication for the systems that actually send your district mail.

Gaggle sends mail

DNS change: Add the SPF, DKIM, and return-path records provided inside your Gaggle setup.
DMARC data: Expect Gaggle to appear as an approved sender once mail volume starts.
Next step: Send a real alert or notification and inspect the authentication results.

Do not guess Gaggle records

Gaggle does not have one safe public SPF or DKIM record that every district can reuse. Use the values in your own Gaggle account or onboarding ticket.

Set up SPF

SPF for Gaggle has two parts: authorizing the sending hosts and making sure the envelope return path uses your domain when Gaggle offers it. Because Gaggle supports return-path alignment, configure the bounce or return-path DNS records Gaggle provides instead of relying only on DKIM.

Find SPF: Copy the SPF include or dedicated sending host from Gaggle's email authentication screen.
Edit root TXT: Update the existing SPF record at your root domain. A domain can have only one SPF TXT record.
Add return path: Create the CNAME, MX, or TXT records Gaggle gives you for the bounce domain.
Check lookups: Keep SPF under the 10 DNS lookup limit after adding Gaggle and your other approved senders.

SPF pattern, replace the Gaggle includedns

example.com.  TXT  "v=spf1 include:<gaggle-spf-host> ~all"

bounce.example.com.  CNAME  <gaggle-return-path-target>

SPF checker

Find SPF syntax issues, lookup limits, and weak records.

?/16tests passed

After publishing, check the live SPF record and confirm there is exactly one SPF TXT record. If the SPF checker reports too many DNS lookups, remove obsolete senders or move sender management into a hosted SPF workflow.

When SPF errors are acceptable

Some sending platforms cannot use your domain in the return path. In that case, SPF alignment errors are acceptable when DKIM passes and the DKIM signing domain matches the visible From domain. For Gaggle, use return-path alignment when the setup screen provides it.

Set up DKIM

DKIM is the authentication method I want passing for every Gaggle message because it survives forwarding better than SPF and it is the cleanest way to satisfy DMARC when the signing domain matches your From domain.

Gaggle DKIM setup screen showing selector and CNAME fields.

Copy selector: Use the exact selector Gaggle assigns, such as a tenant or district-specific selector.
Create DNS: Publish the DKIM TXT or CNAME record at the host shown by Gaggle.
Keep host exact: Do not add the root domain twice if your DNS provider appends it automatically.
Verify in Gaggle: Click Verify DKIM after DNS propagation, then send a live message to confirm the signature.

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 is the main pass condition

A Gaggle message can pass DMARC when DKIM passes and the DKIM signing domain matches the From domain. That is why I verify DKIM before tightening DMARC.

Set up DMARC

DMARC belongs on your domain, not inside Gaggle. Publish it at _dmarc.example.com so receivers can report whether Gaggle and every other approved sender passes SPF or DKIM with domain matching.

Starter DMARC recorddns

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Start safe: Use v=DMARC1; p=none; rua=mailto:dmarc@example.com for a new policy.
Keep enforcement: If your domain already uses p=quarantine or p=reject, do not downgrade it for Gaggle.
Generate record: Use the DMARC record generator when you want a clean record with reporting addresses and policy tags.
Point reports: Send aggregate reports to a mailbox or platform that can parse XML and show source-level failures.

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 syntactically valid DMARC record does not prove Gaggle passes yet, so the next step is a real message test.

Do not publish two DMARC records

Receivers ignore DMARC when more than one TXT record exists at _dmarc. Edit the existing record instead of adding another one.

Verify and troubleshoot

Verification needs a real Gaggle message, not only DNS lookups. Send the exact type of Gaggle email you care about, then check the headers for SPF, DKIM, DMARC, and the domains used by each result.

Gaggle email delivery test screen showing sender and authentication details.

Header From: The visible From domain should be your school or district domain.
Return path: The bounce domain should be your domain or a subdomain delegated to Gaggle.
DKIM domain: The d= value should match the From domain or an allowed organizational domain.
DMARC result: A pass means SPF or DKIM passed and the relevant domain matched the visible From domain.

Passing header patterntext

From: District Alerts <alerts@example.com>
Return-Path: <bounces@bounce.example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
Authentication-Results: spf=pass smtp.mailfrom=bounce.example.com;
Authentication-Results: dkim=pass header.d=example.com;
Authentication-Results: dmarc=pass header.from=example.com;

Email tester

Send a real email to this address. Suped opens the report when the test is ready.

?/43tests passed

Preparing test address...

Signal	Pass value	Fix
SPF	Pass	SPF include
DKIM	Pass	Selector
DMARC	Pass	Domain match
Policy	p=none	Stage policy

Use this table after a Gaggle test message lands.

If DKIM passes but DMARC fails, the signing domain does not match the From domain. If SPF passes but DMARC fails, the return path is not using your domain. If both fail, go back to the Gaggle DNS screen and compare every host and value character by character.

Get alerted when it breaks

Gaggle authentication can break after a DNS cleanup, domain migration, new sender setting, or expired selector. Suped's DMARC monitoring turns the raw reports into sender-level issues, so you can see when Gaggle starts failing before you move to enforcement or before a school notification is rejected.

Watch sources: Track whether Gaggle appears as a verified source and whether its volume changes unexpectedly.
Catch failures: Alert on SPF, DKIM, and DMARC failure spikes instead of waiting for a user complaint.
Fix faster: Use issue detection and steps to fix when records are missing, duplicated, or over SPF limits.
Check reputation: Monitor blocklist and blacklist signals beside authentication results for the same domain.

Where Suped fits

Suped brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring, real-time alerts, and MSP multi-tenancy into one workflow. That matters for Gaggle because school domains often have many approved senders and many people touching DNS.

Manual checks

Timing: You find problems only when someone checks DNS or reads message headers.
Scope: You see one message at a time and miss source-wide failure patterns.
Ownership: DNS, security, and school operations teams have to coordinate manually.

Suped workflow

Timing: Real-time alerts flag authentication changes as soon as report data shows them.
Scope: Source breakdown shows whether Gaggle, other systems, or unknown senders are failing.
Ownership: Actionable issues give the record owner the exact DNS change to make.

Secure your domain with p=reject

Move to p=reject only after Gaggle and every approved sender passes DMARC consistently. I treat rejection as the finish line for a protected school domain, not the starting point.

DMARC enforcement path

Use report data to decide when each policy level is safe.

Observe

p=none

Collect at least two school weeks of normal mail, including Gaggle alerts.

Limit risk

p=quarantine

Use quarantine only after approved senders pass and unknown traffic is understood.

Block abuse

p=reject

Use reject when legitimate mail is passing and owners can handle new sender requests.

Inventory senders: List Gaggle, mailbox systems, student platforms, finance systems, and notification tools that send as the domain.
Fix failures: Resolve every recurring legitimate SPF or DKIM failure before changing policy.
Stage policy: Move to quarantine first if you still have uncertainty about low-volume senders.
Reject last: Publish reject when the approved-source pass rate is stable and new sender intake has an owner.

Final enforcement recorddns

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Why Suped helps with enforcement

Suped is strongest when a domain has many senders and a real enforcement goal. Hosted DMARC helps stage policy changes without repeated DNS edits, while hosted SPF and SPF flattening help keep SPF valid as senders change.