📧 Cybersecurity

Why Your Daycare's Emails Land in Parents' Spam Folder (And How to Fix It)

You sent the closure notice at 6am. By drop-off, half the families hadn't seen it. The problem almost never lives in what you wrote — it lives in three DNS records most centers have never been told about.

By Eshan de Silva · October 18, 2026 · 8 min read

Every director has had this conversation. You emailed every family about the water main break, and at 7:30am three parents walk in with no idea the center is closed. You check the sent folder — it went out. You ask a parent to look in spam, and there it is, sitting next to an offer for discount sunglasses. It feels like bad luck. It isn't. It's a configuration problem, and it's one of the few technology problems with a clean, permanent fix.

This guide explains what's actually happening, what the three records do in plain English, what Gmail now expects of every sender, and the order to do things in. No jargon you can't repeat to your co-director.

What's really happening when your email goes to spam

Anyone, anywhere, can type your center's email address into the "From" line of a message. Email was designed in a more trusting era and it never checked. So mail providers built the check themselves: before Gmail or Outlook puts a message in front of a parent, it asks the sending domain to prove the mail is authorized.

That proof lives in your domain's DNS records — the same place your website and mail settings live. If the proof is missing, the receiving provider has no way to tell your closure notice apart from a scammer impersonating you. Faced with that doubt, it does the safe thing and files the message in spam. Your email isn't being punished for its content. It's being filtered for lack of ID.

The three records, in plain English

• SPF is the guest list. It's a short line in your DNS that names which mail servers are allowed to send as your domain — your email platform, your childcare app, your newsletter tool. If a message arrives from somewhere that isn't on the list, that's a red flag.
• DKIM is the tamper-proof seal. Your mail platform signs each outgoing message with a private key, and the matching public key sits in your DNS. The receiver checks the signature to confirm the message really came from your system and wasn't altered on the way.
• DMARC is the instruction sheet. It tells receiving providers what to do when SPF and DKIM don't line up with the address in your From field — do nothing, send it to spam, or reject it outright — and it asks them to send you reports about who's sending mail as your domain.

The Federal Trade Commission recommends all three for small businesses, for exactly the reason that matters most to a childcare center: without them, a scammer can send email that appears to come from your domain, and the families who get burned are yours.

What Gmail now expects from you

Google's email sender guidelines apply to all senders who email personal Gmail accounts — not just marketing departments. The rules get stricter once you cross into what Google calls bulk sending, defined as close to 5,000 messages or more to personal Gmail accounts within a 24-hour period. Messages from your whole primary domain count together, and once you're classified as a bulk sender, that classification is permanent.

Most single-site centers never hit 5,000 a day. But it's worth knowing what Google asks of bulk senders, because it's a tidy description of a healthy email setup:

• Both SPF and DKIM on outgoing mail — not one or the other.
• A DMARC record with a policy of at least p=none.
• Alignment: the domain in your From header has to match the domain verified by SPF or by DKIM. Only one needs to align, though Google recommends both.
• A spam complaint rate below 0.1%, and never at or above 0.3%.
• One-click unsubscribe on marketing and promotional messages — not on transactional ones like an incident report or an invoice.
• Mail sent over TLS, with valid forward and reverse DNS on the sending IP.

Microsoft and Yahoo have landed in much the same place. The practical upshot: the three records are no longer optional hygiene for anyone who emails families.

The fix, in the order that works

1. List everything that sends mail as your domain. This is the step people skip, and skipping it is why DMARC breaks things. Write down your email platform (Microsoft 365, Google Workspace), your childcare management app if it emails parents under your address, your newsletter or tour-follow-up tool, your website contact form, your invoicing or payment system, and your payroll provider. Four to six senders is normal for a center that feels like it "only uses email."

2. Publish one SPF record. One, not several — a domain with two SPF records fails the check entirely, and that single mistake is behind a surprising share of delivery problems. It looks like v=spf1 include:_spf.google.com ~all, with an include for each authorized sender from step one. Keep the list tight: SPF has a hard limit of ten DNS lookups, and stuffing in every service you've ever trialled will break it.

3. Turn on DKIM everywhere. In Microsoft 365 or Google Workspace this is a few clicks in the admin console plus a DNS entry. Then go through every third-party sender on your list and enable its own DKIM signing too. A newsletter tool that isn't signing is a newsletter tool that lands in spam.

4. Publish DMARC at p=none first. Something like v=DMARC1; p=none; rua=mailto:dmarc@yourcenter.com. At p=none nothing gets blocked — you're only asking for reports. Those reports are the point: they show you every system sending as your domain, including the ones nobody remembered and the ones that aren't yours at all.

5. Watch, then tighten. After a few weeks of clean reports, move to p=quarantine, then to p=reject. Going straight to reject before you've seen the reports is how a center accidentally blocks its own tuition invoices. Patience here is free; impatience is not.

The mistakes that keep centers in the spam folder

• Sending from a free address. You can't publish authentication records for a domain you don't own, so a @gmail.com or @yahoo.com address in the From field of a bulk tool is a known cause of filtering. It also costs you credibility with enrolling families, and it's unmanageable the day that staff member leaves.
• Forgetting the childcare app. If your parent-communication platform sends under your domain, it needs to be in SPF and signing with DKIM. Many centers authenticate their staff email beautifully and leave the system that sends the most parent mail unauthenticated.
• Two SPF records. Usually the result of two different people adding one, months apart. Merge them into a single record.
• A stale parent list. Bounces and complaints damage your sending reputation over time. Old addresses from families who left two years ago are quietly working against the families still with you.
• Treating it as a one-time job. Every time you add a tool that emails parents, it has to be added to SPF and DKIM. Put it on the same checklist you use when onboarding any new system.

List hygiene starts at the front desk. If tour inquiries and visitor sign-ins are captured on a clipboard and typed in later, you're building bounces in from day one — which is part of why we built SenLobby.ai to capture visitor and tour details accurately at check-in instead.

This is a security fix, not just a delivery fix

Here's the part that makes this urgent rather than merely annoying. The same missing records that send your closure notice to spam are what let someone else send mail that looks like it came from you. The attack writes itself: a message from "the director" to every enrolled family, explaining that the tuition portal has changed and payment should now go to a new account. It arrives from your address. It reads like you. Parents pay.

That's not hypothetical — it's the standard playbook we cover in our guide to business email compromise, and the AI tools now used to write these messages have made them considerably harder to spot, as we explain in AI phishing and deepfake fraud. A DMARC policy at reject doesn't stop every variation, but it closes the easiest door: sending as your exact domain.

If you're not sure where your domain stands today, that's a reasonable place to be — most centers have never had a reason to look. EDCON's managed IT services include email authentication as part of the standard setup for childcare centers and small businesses across Los Angeles, Oxnard, Ventura and Azusa, and if you're still deciding between platforms, our comparison of Google Workspace and Microsoft 365 for childcare covers how each handles this.

What it costs and how long it takes

The records themselves are free — DNS entries cost nothing, and SPF, DKIM and DMARC support is included in business email platforms you're likely already paying for. The real cost is an afternoon of careful work: inventory your senders, publish the records, verify each one, then read reports for a few weeks before tightening. DNS changes typically propagate within hours.

The payoff is immediate and you can feel it. The closure notice lands in the inbox. The invoice gets paid. The tour follow-up reaches the family who's deciding between you and the center down the street. And the next person who tries to impersonate your domain gets stopped before a parent ever sees the message.

Common questions about email landing in spam