How to set up DMARC/DKIM/SPF for FACTS
FACTS email authentication is mostly a DKIM job: add your school sender domain in FACTS, ask FACTS for custom DKIM DNS values, keep SPF clean for your other mail systems, then publish DMARC so reports prove whether FACTS mail passes. I treat FACTS as a DKIM-first source because it does not support Return-Path domain matching for your own domain, so SPF alignment errors are expected when DKIM passes for the visible From domain.
I could not find a public FACTS article that publishes universal SPF includes, DKIM selectors, or DKIM targets for school-owned sender domains. Treat the DNS values as account-specific. FACTS support needs to provide the exact DKIM selector and record target for your tenant.
|
|
|
|
|---|---|---|---|
Domain | Set sender | None | Known From domain |
SPF | Do not guess | Merge only | No duplicate SPF |
DKIM | Request values | Publish key | DMARC pass |
DMARC | Send tests | Add record | Reports |
FACTS email authentication setup map
Add your domain
Start inside FACTS by confirming the exact domain used in the visible From address. DMARC checks the domain families see in the inbox, not the brand name on the message.
- Access: Sign in to FACTS SIS as a school administrator with permission to manage communication settings and school profile settings.
- Sender: Find the school email sender used for attendance, grade, admissions, billing, alert, and family communication messages.
- Domain: Use a real mailbox or monitored alias on your domain, such as noreply@example.com or office@example.com.
- Support: Ask FACTS support to enable custom DKIM signing for that From domain and to send the selector, host name, record type, and target value.
- Test: Send a real FACTS message to a mailbox you control, then save the full headers before you change DNS.
FACTS SIS sender email settings for a school domain.
Do not start by changing DMARC to reject. First prove that FACTS signs with your domain through DKIM, then tighten policy after reports show consistent passing mail.
- Keep: Keep any existing quarantine or reject policy if your domain already has it.
- Avoid: Avoid relaxing your domain policy only because one FACTS source has not been configured yet.
Set up SPF
For FACTS, I do not add guessed SPF includes. FACTS does not support Return-Path domain matching for your domain, so SPF is not the authentication path that gets FACTS through DMARC. DKIM has to carry DMARC for FACTS mail.
- Inspect: Open your current SPF TXT record at the root of the sender domain.
- Preserve: Keep existing approved senders for staff mail, admissions mail, finance mail, and any other platform that uses your Return-Path domain.
- Merge: If FACTS support gives you an SPF include or IP range, merge it into the one existing SPF record instead of creating a second SPF TXT record.
- Limit: Keep SPF under 10 DNS lookups after every include, redirect, exists, mx, and a mechanism is counted.
- Expect: Expect SPF alignment errors for FACTS in DMARC reports. That is acceptable when DKIM passes for your From domain.
SPF pattern onlyDNS
example.com. TXT "v=spf1 include:mail.example.net ~all"
A second SPF record causes SPF permerror at receivers. If your DNS already has SPF, edit that record. Do not add another one for FACTS.
- Bad: Two separate TXT records that both start with v=spf1.
- Good: One SPF TXT record that contains every approved sender that belongs in SPF.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
After the SPF check passes, keep going. SPF being valid does not prove FACTS passes DMARC, because the FACTS Return-Path domain will not match your visible From domain.
Set up DKIM
DKIM is the key FACTS requirement. The DKIM signature has to use your school domain, or a subdomain that has the same organizational domain as the visible From address.
- Request: Ask FACTS support for custom DKIM signing for the exact From domain used in FACTS messages.
- Collect: Get the selector, host name, record type, target, and any required verification step.
- Publish: Add the DKIM record exactly as FACTS provides it in your DNS host.
- Wait: Wait for DNS propagation, then ask FACTS to validate or activate DKIM signing.
- Confirm: Send a FACTS message and confirm DKIM passes with a d= value that matches your From domain.
DKIM placeholder patternDNS
facts1._domainkey.example.com. CNAME facts1.example.vendor.net.
Do not publish the placeholder above. It only shows the shape of a typical DKIM CNAME. FACTS has to give the real selector and target for your school account.
Working DKIM
- Signature: The message has a DKIM signature.
- Domain: The d= domain matches the visible From domain.
- Result: DMARC passes even when SPF alignment fails.
Broken DKIM
- Missing: No DKIM signature exists on the FACTS message.
- Mismatch: The d= domain is a FACTS-owned domain instead of your domain.
- Result: DMARC fails for that FACTS source.
FACTS SIS custom DKIM setup request for a school domain.
Set up DMARC
DMARC belongs in your DNS, not inside FACTS. Start with monitoring if the domain has no DMARC policy yet. If the domain already uses quarantine or reject, keep that stronger policy and fix FACTS DKIM rather than stepping backward.
- Host: Create a TXT record at _dmarc.example.com, replacing example.com with your sender domain.
- Policy: Use p=none while FACTS DKIM is being verified, unless your domain already runs quarantine or reject.
- Reports: Point rua to a mailbox or reporting endpoint that parses aggregate reports.
- Generate: Use the DMARC record generator if you want a clean record without hand-editing tags.
- Check: Verify the record after DNS propagation and confirm there is only one DMARC TXT record.
Starter DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
DMARC p=none does not block mail. It gives you the source data needed to prove FACTS, staff mail, and every other sender are passing before enforcement.
Verify and troubleshoot
Verification means testing a real FACTS message, not only checking that DNS exists. I use the headers and DMARC reports together because DNS can be correct while FACTS is still signing with the wrong domain.
- Send: Trigger a real FACTS email, such as an alert, attendance notice, or family communication.
- Inspect: Open the full message headers and find Authentication-Results.
- DKIM: Confirm DKIM says pass and the d= domain belongs to your sender domain.
- DMARC: Confirm DMARC says pass. If SPF fails but DKIM passes, FACTS is still in the expected state.
- Health: Run a full domain health checker review after DNS changes.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
The email tester is the fast check: send it one FACTS-generated email and use the report to confirm SPF, DKIM, DMARC, headers, DNS, and inbox-facing issues in one place.
|
|
|
|---|---|---|
DKIM fail | Wrong DNS | Republish |
No DKIM | Not enabled | Ask FACTS |
SPF fail | Return-Path | Check DKIM |
DMARC fail | No match | Fix DKIM |
FACTS troubleshooting checklist
FACTS SIS communication log used to verify an authenticated test email.
Get alerted when it breaks
FACTS authentication can break after a domain change, DNS migration, selector rotation, or sender setting update. Suped's product is built for this workflow: it monitors DMARC results by source, detects authentication failures, and alerts you before a school office hears about missing family communications.
- Alerts: Real-Time Alerts flag sudden FACTS DKIM failures, new unverified sources, and policy-impacting changes.
- Issues: Automated issue detection gives exact fix steps instead of leaving raw XML reports for someone to decode.
- Sources: The source breakdown separates FACTS from staff mail, admissions tools, finance systems, and unknown senders.
- Reputation: Blocklist (blacklist) monitoring connects authentication failures with domain and IP reputation changes.
- Scale: The MSP and multi-tenancy dashboard keeps separate schools and domains in one operational view.
Suped is the stronger practical choice for most teams because it ties DMARC, SPF, DKIM, hosted records, SPF flattening, blocklist and blacklist monitoring, and deliverability signals into one workflow.
For ongoing FACTS visibility, connect aggregate reports to DMARC monitoring and watch for the FACTS source to stay DKIM-passing before you increase enforcement.
When to alert on FACTS mail
Use these thresholds for school-owned From domains that rely on DKIM for FACTS.
Healthy
98-100%
FACTS messages pass DKIM and DMARC.
Investigate
90-97%
A small DKIM dip appears after a change.
Act now
Under 90%
DMARC failures affect family messages.
Secure your domain with p=reject
Move to p=reject only after FACTS and every other legitimate sender has a stable DMARC pass path. For FACTS, that means DKIM passes with your domain. SPF does not have to pass DMARC for FACTS when DKIM does.
- Inventory: Identify every legitimate source in DMARC reports, including FACTS, staff mail, admissions, finance, forms, and website mail.
- Fix: Resolve every recurring FACTS DKIM fail before changing policy.
- Stage: Move p=none to quarantine first if your organization wants a softer enforcement step.
- Reject: Switch to p=reject after reports show legitimate mail is consistently passing.
- Maintain: Keep alerts on after enforcement because one DNS change can turn a working FACTS source into a failing source.
Before reject
- FACTS: DKIM pass is not yet stable.
- Reports: Unknown sources still send as your domain.
- Risk: Legitimate school mail gets rejected.
Ready for reject
- FACTS: DKIM pass is stable by source.
- Reports: Known senders account for real volume.
- Risk: Unauthorized mail is blocked.
Final DMARC policyDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped's Hosted DMARC helps teams move through policy staging without repeated DNS edits. Hosted DMARC keeps policy changes controlled while alerts confirm FACTS stays authenticated.
