How to set up DMARC/DKIM/SPF for FACTS
Updated on 25 Oct 2026: We revised FACTS setup checks and DNS troubleshooting, and clarified when p=reject is appropriate for school sending domains.
FACTS email authentication depends on the sending service and domain used by your school. Confirm your school sender domain with FACTS support, request the supported DNS values, keep one valid SPF record per MAIL FROM domain, and publish DMARC with aggregate reporting. Prioritize aligned DKIM because it can preserve a DMARC pass when forwarding breaks SPF, but verify both paths in a real FACTS message.
Request SPF and DKIM instructions for the exact FACTS product and sending workflow your school uses. Confirm whether custom DKIM signing and a custom MAIL FROM domain are supported before publishing DNS records. Then use message headers to check alignment with the visible From domain.
|
|
|
|
|---|---|---|---|
Domain | Confirm sender and product | Confirm DNS access | Known From domain |
SPF | Request values | Merge if supplied | SPF checked |
DKIM | Request values | Publish supplied TXT or CNAME | Aligned signature |
DMARC | Send tests | Add record | Reports |
FACTS email authentication setup map
Confirm your FACTS sender domain
Start by confirming the exact domain used in the visible From address of a FACTS message. DMARC checks that domain, not the display name or Reply-To address. You also need access to the domain's authoritative DNS provider, which is not always the registrar.
- Sign in to FACTS SIS with administrative access, and have your DNS administrator available to publish the records confirmed by FACTS support.
- Identify the sender address for each FACTS workflow your school uses. Do not assume SIS communications and tuition notifications share the same email configuration.
- Domain: Use a real mailbox or monitored alias on your domain, such as noreply@example.com or office@example.com.
- Ask FACTS support which authentication options your account supports, including the expected MAIL FROM domain and any SPF include or IP range, DKIM selector, DNS record type, value, and activation step.
- Test: Send a real FACTS message to a mailbox you control, then save the full headers before you change DNS.
Illustrative FACTS SIS sender settings for school email authentication.
Do not start by changing DMARC to reject. First prove that FACTS has an aligned authentication path for your From domain, with aligned DKIM preferred before enforcement.
- 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.
Choose a sender domain before enforcement
A domain used for staff correspondence needs a different policy assessment than a domain reserved for automated FACTS messages. RFC 9989 advises against p=reject for general-purpose email domains because mailing lists and other indirect delivery paths can break authentication.
- For a shared staff domain, assess mailing-list and forwarding traffic before changing DMARC policy.
- If FACTS supports it, use a dedicated sender subdomain such as notices.example.com. Verify its authentication and effective DMARC policy separately; a subdomain can inherit a parent policy.
If FACTS cannot provide an aligned authentication path for your domain, ask whether a FACTS-owned From address with your school mailbox in Reply-To is supported. Changing Reply-To alone does not fix DMARC alignment.
Set up SPF
Do not guess a FACTS SPF include or assume SPF alignment is unavailable. Use only the values FACTS provides for your tenant. SPF contributes to DMARC only when it passes and the authenticated MAIL FROM domain has the required alignment with the visible From domain.
- Identify the MAIL FROM domain in Return-Path or smtp.mailfrom. Inspect the SPF TXT record at that exact name only if you control it; a subdomain does not inherit the root domain's SPF record.
- Preserve: Keep existing approved senders for staff mail, admissions mail, finance mail, and any other platform that uses that Return-Path domain.
- Request: Get the approved SPF include or IP range and the expected MAIL FROM domain directly from FACTS support.
- Merge: If FACTS supplies an SPF mechanism for a domain you control, merge it into the one existing SPF record instead of creating a second SPF TXT record.
- Keep SPF within the limit of 10 DNS-querying terms during evaluation, including nested include and redirect chains. Count include, a, mx, ptr, exists, and redirect; ip4, ip6, and all do not count.
- Confirm: Record the smtp.mailfrom domain and SPF result from a delivered FACTS message. If SPF fails alignment, require aligned DKIM for the DMARC pass.
SPF pattern onlyDNS
example.com. TXT "v=spf1 include:mail.example.net ~all"
This SPF example is a placeholder, not a FACTS include. Keep the existing all qualifier when adding an approved sender: ~all produces softfail and -all produces fail, while receivers decide message handling. The lookup limit is defined in RFC 7208.
Multiple SPF records at the same DNS name cause SPF permerror at receivers. If that name already has SPF, edit the existing record. Separate MAIL FROM subdomains can each have their own SPF record.
- 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
A syntactically valid SPF record does not prove FACTS passes DMARC. The message must pass SPF using an aligned MAIL FROM domain, or pass DKIM using an aligned signing domain.
Set up DKIM
A passing DKIM signature with alignment gives FACTS a DMARC pass path. Under relaxed alignment, the DKIM d= domain and visible From domain need the same organizational domain. Under strict alignment, they must match exactly. Forwarding that changes signed content can still break DKIM.
- Ask FACTS support whether custom DKIM signing is available for the exact From domain and sending workflow used in your messages.
- Collect: Get the selector, host name, record type, target, and any required verification step.
- Publish the supplied TXT public key or CNAME target at selector._domainkey.yourdomain. Never publish a private key. Check whether your DNS panel appends the zone name so you do not duplicate the domain.
- Confirm the record is visible on authoritative DNS and allow cached answers to expire, then ask FACTS to validate or activate signing. A new record does not always require waiting a full TTL.
- Confirm: Send a FACTS message and confirm DKIM passes with a d= value aligned to your visible From domain.
DKIM placeholder patternDNS
facts1._domainkey.example.com. CNAME facts1.example.vendor.net.
Do not publish the placeholder above. FACTS must confirm the real selector and record type for your school account. For RSA signing, request a 2048-bit key or stronger where supported, as recommended by RFC 8301. Coordinate selector rotation with FACTS and retain the old public key until previously signed messages have cleared delivery queues.
Working DKIM
- Signature: The message has a passing DKIM signature.
- Domain: The d= domain has alignment with the visible From domain under your DMARC alignment mode.
- Result: DMARC passes even when SPF or SPF alignment fails.
Broken DKIM
- Missing: No DKIM signature exists on the FACTS message.
- Mismatch: The passing d= domain lacks alignment with your visible From domain.
- Result: DMARC fails unless SPF also passes with an aligned MAIL FROM domain.
Illustrative FACTS SIS custom DKIM configuration for a school domain.
Set up DMARC
DMARC belongs in your DNS, not inside FACTS. The current standard is RFC 9989, and the record still starts with v=DMARC1. Start with monitoring if the domain has no existing or inherited DMARC policy. If it already uses quarantine or reject, keep that policy while fixing the FACTS authentication path.
- Create a TXT record at _dmarc.example.com, replacing example.com with your sender domain. For notices.example.com, the name is _dmarc.notices.example.com; check for an existing or inherited policy first.
- Policy: Use p=none while FACTS authentication is being verified, unless your domain already runs quarantine or reject.
- Point rua to a working mailbox or reporting service that parses aggregate XML. Replace dmarc@example.com in the sample with your actual destination.
- 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 at the policy name.
- Tags: Do not use pct for gradual enforcement. RFC 9989 removed pct and added t for testing behavior, not percentage rollout.
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 change message handling under the standard. With rua configured, reports show authentication results for FACTS and other sources. A DMARC pass does not guarantee inbox placement, and aggregate reports are not proof that each message reached a family mailbox.
Authorize external DMARC reports
If the domain after @ in your rua address sits outside the organizational domain that publishes DMARC, the report destination normally needs a DNS authorization record. Without that approval, receivers can ignore the external report address even when your DMARC record is valid.
- Compare: Compare the domain publishing DMARC with the domain used by the rua destination. A same-domain mailbox does not need external authorization.
- Confirm: Ask the report destination operator whether it authorizes your exact domain or uses an accepted wildcard record.
- Publish: The destination domain operator publishes the authorization TXT record under its own DNS zone. Do not place that record in the school's zone unless the school owns the destination domain.
- Verify: Confirm that the authorization record resolves, then wait through a normal reporting cycle for aggregate data. Suped provides the reporting address used by its product workflow and handles authorization on the reporting domain.
External reporting authorization patternDNS
example.com._report._dmarc.reports.example.net. TXT "v=DMARC1;"
The pattern above is an example, not a FACTS record. Replace both domains with the exact publishing and reporting domains, or use the reporting address and instructions supplied by your report processor.
Verify and troubleshoot
Verification means testing a real FACTS message, not only checking that DNS exists. Use the headers and DMARC aggregate reports together because DNS can be correct while FACTS still authenticates with a domain that lacks alignment.
- Trigger a real email through each FACTS workflow your school uses, and test direct delivery plus a forwarding route used by families where practical.
- Open the full message headers in the recipient mailbox and find its trusted, receiver-added Authentication-Results field. Request delivery logs and SMTP rejection details from FACTS support for messages that did not arrive.
- Record the SPF result and smtp.mailfrom domain, then check alignment with the visible From domain under your aspf setting. The default relaxed mode uses the organizational domain; strict mode requires an exact domain match.
- Confirm DKIM says pass and the header.d domain has alignment with the visible From domain under your adkim setting.
- DMARC: Confirm DMARC says pass. FACTS needs one aligned authentication path, although both SPF and DKIM should be configured when FACTS provides them.
- Health: Run a full domain health checker review after DNS changes.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Suped's email tester checks one FACTS-generated message for authentication and DNS issues. Use that sample alongside aggregate reports covering every FACTS sending workflow.
|
|
|
|---|---|---|
DKIM fail | Wrong key, DNS name, or changed signed content | Compare FACTS DNS values and test a direct message |
No DKIM | Signing not active | Ask FACTS to activate |
SPF fail or permerror | Unauthorized IP, duplicate records, or lookup limit | Check the MAIL FROM record and complete include chain |
DMARC fail | No aligned pass | Fix DKIM or aligned SPF |
DKIM record not found | Duplicated zone suffix or wrong selector | Use the s= selector and d= domain to query selector._domainkey.domain |
No aggregate reports | Wrong rua, missing authorization, or no reporting traffic | Verify the destination and allow a reporting cycle |
DMARC passes but mail is missing | Recipient filtering or another delivery issue | Check the SMTP response, quarantine, and recipient mailbox |
FACTS troubleshooting checklist
Illustrative FACTS SIS communication log for an email authentication test.
Monitor FACTS authentication failures
FACTS authentication can break after a domain change, DNS migration, selector rotation, or sender setting update. Suped's product monitors DMARC results by source, detects authentication failures, and alerts teams when FACTS mail moves away from its established passing pattern.
- Use authentication alerts to flag new failures as reports arrive. Aggregate reporting is delayed, so these alerts are not a live per-message delivery log.
- Use Suped's issue guidance to investigate authentication failures, then confirm the required DNS changes with FACTS support.
- Sources: The source breakdown separates FACTS from staff mail, admissions tools, finance systems, and unknown senders.
- Reputation: Blocklist (blacklist) monitoring helps compare authentication failures with domain and IP reputation changes.
- Scale: The MSP and multi-tenancy dashboard keeps separate schools and domains in one operational view.
For ongoing FACTS visibility, connect aggregate reports to DMARC monitoring and confirm its authentication remains stable after DNS or sender changes.
How to prioritize FACTS failures
Compare current results with the normal volume and authentication path for each school-owned From domain.
Healthy
Expected volume passes
Expected FACTS volume passes DMARC through an aligned path.
Investigate
New failures
New low-volume failures appear after a DNS or sender change.
Act now
Sustained failures
Failures persist or affect a material share of family messages.
Choose a DMARC enforcement policy
For a domain suited to p=reject, first confirm FACTS and every legitimate source consistently pass DMARC with aligned DKIM. RFC 9989 requires domains using reject to sign mail with valid DKIM rather than relying solely on SPF. Receivers still apply local policy.
- Inventory: Identify every legitimate source in DMARC reports, including FACTS, staff mail, admissions, finance, forms, and website mail.
- Fix: Resolve every recurring FACTS authentication failure before changing policy.
- Observe: Collect reports across a full sending cycle. For domains used by people who post to mailing lists, RFC 9989 advises at least one month at p=none and another month at p=quarantine before reject.
- Stage: Move from p=none to p=quarantine as the enforcement step before reject. Do not use pct for a percentage rollout.
- Publish p=reject only for a suitable sending domain after legitimate mail consistently passes and indirect delivery risks have been assessed. Keep a policy appropriate to general-purpose staff mail.
- Maintain: Keep alerts on after enforcement because one DNS change can turn a working FACTS source into a failing source.
Before reject
- FACTS: Its aligned pass path is not yet stable.
- Reports: Unknown sources still send as your domain.
- Risk: Legitimate school mail can be quarantined or rejected.
Ready for reject
- FACTS has a stable aligned DKIM pass path, and the domain is suitable for reject.
- Reports: Known senders account for legitimate volume.
- Policy: Receivers see your reject preference for DMARC failures.
Reject policy example for a suitable sending domainDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped's Hosted DMARC lets teams change policy stages without repeated DNS edits. Hosted DMARC keeps those changes controlled while alerts confirm FACTS stays authenticated.
FACTS authentication FAQ
Ask FACTS support whether a custom MAIL FROM domain is supported for your sending workflow, then inspect a real message. SPF has alignment under the default relaxed mode when its passing MAIL FROM domain and the visible From domain share the same organizational domain. Adding an SPF include to your school domain does not change a FACTS-owned MAIL FROM domain.
Add only the include or IP range FACTS confirms for a MAIL FROM domain you control. Merge it into the existing SPF record at that DNS name and stay within the 10-lookup limit. If the MAIL FROM domain belongs to FACTS, FACTS manages its SPF; editing your school domain does not change that SPF result.
A FACTS-owned d= domain lacks alignment with your school From domain. DMARC can still pass through aligned SPF, but custom DKIM gives the message a more durable aligned path. Ask FACTS support whether custom DKIM is available for your tenant.
Reverse DNS names containing RenWeb, FACTS, or factsmgt can provide a clue, but they are not proof. Match the sending IP, visible From domain, MAIL FROM domain, DKIM d= domain, message sample, and authentication result before classifying the source as FACTS.
A dedicated sending domain can use p=reject after FACTS and all other legitimate sources consistently pass with aligned DKIM and indirect delivery risks have been assessed. RFC 9989 advises against reject for general-purpose email domains, especially where users post to mailing lists. Keep monitoring after enforcement. Fix an unconfigured FACTS source without automatically weakening an existing domain policy.
