Should every business domain have a DMARC policy?
Yes. Every domain your organization owns should have a DMARC policy, even if the domain does not send email. For Modesto and Central Valley businesses, the risk is not limited to the primary Microsoft 365 domain. Parked domains, campaign domains, acquisition domains, and old brand domains can all be abused for spoofing if they are left unprotected.
Most organizations think about email authentication only when they configure the main domain used by employees. That is too narrow. Attackers do not need to spoof your busiest domain if they can abuse a forgotten domain that still looks related to your company, a former product, a location-specific campaign, or a subsidiary.
For a mid-market business, school district, healthcare clinic, financial firm, or municipal organization, the practical question is not “Did we configure SPF, DKIM, and DMARC once?” The better question is: “Can we prove every domain we own has an intentional sending policy, a monitoring path, and an enforcement plan?”
That is where a second-level-domain DMARC program matters.
What is a second-level domain in DMARC governance?
A second-level domain is the registered domain directly under a top-level domain, such as example.com, example.org, or example.net. Subdomains such as mail.example.com, alerts.example.com, and billing.example.com sit underneath that registered domain and may inherit the parent domain’s DMARC policy unless a more specific subdomain policy is published.
This distinction matters because most businesses accumulate more second-level domains than they realize. A company may own its primary domain, common misspellings, old brands, location domains, recruiting domains, event domains, product domains, and domains acquired through mergers or vendor campaigns.
From a security perspective, each of those domains falls into one of three categories:
- Active sending domain: used by employees, Microsoft 365, Google Workspace, CRM systems, billing platforms, help desk tools, marketing automation, or operational alerts.
- Non-sending domain: owned by the business but not supposed to send email.
- Unknown-status domain: owned by the business, but no one can say with confidence whether it sends email.
The unknown-status group is where businesses get burned. It is common for marketing, sales, HR, finance, and IT to each know about a different slice of the domain portfolio. Without a central inventory, a domain can be delegated to a vendor years ago, left with stale DNS records, or left entirely unauthenticated.
NIST’s trustworthy email guidance treats SPF, DKIM, and DMARC as core mechanisms for authenticating a sending domain and improving trust in enterprise email systems.1 NIST’s NCCoE email security practice guide also emphasizes standards-based DNS and email security architectures that organizations can adapt using commercial and open-source components.2 The takeaway for business leaders is straightforward: email authentication is not a one-time DNS chore. It is a governed control surface.
Why should Modesto and Central Valley businesses care about parked domains?
Parked domains are often more dangerous than they look because they feel harmless. A parked domain may have no website, no mailbox, and no current marketing campaign. But if it lacks an explicit DMARC policy, it may still be useful to an attacker attempting brand impersonation, vendor fraud, payroll fraud, or business email compromise.
A Modesto manufacturer, Fresno healthcare group, Central Valley school district, or multi-location professional services firm may own domains tied to:
- past rebrands
- executive initiatives
- recruiting campaigns
- event landing pages
- regional office expansions
- acquired businesses
- alternate spellings
- defensive registrations
- vendor-managed microsites
- abandoned sales campaigns
The business may not send from those domains, but attackers may still use lookalike sender identities in phishing. Even when receiving systems do not accept every spoofed message, weak or missing email authentication makes it harder for recipients, security gateways, and investigators to distinguish legitimate from illegitimate mail.
For non-sending domains, the target state is usually simple: publish DNS records that say the domain is not authorized to send email. That typically means a restrictive SPF posture, no active DKIM selectors unless needed, and a DMARC policy that moves toward rejection once monitoring confirms there is no legitimate traffic.
For active domains, the target state is more nuanced: identify legitimate senders, align SPF and DKIM where possible, watch reports, fix failures, and then move from monitoring to quarantine or reject.
How does DMARC actually reduce spoofing risk?
DMARC gives domain owners a way to tell receiving mail systems how to handle messages that claim to be from the domain but fail authentication and alignment checks. SPF can help verify whether a sending server is authorized. DKIM can help verify that a message was cryptographically signed by an authorized domain. DMARC ties those mechanisms to the visible “From” domain that users actually see.
That visible alignment is the point. A message may pass some technical checks and still not represent the domain shown to the recipient in a trustworthy way. DMARC helps close that gap by giving domain owners policy and reporting controls.
A basic DMARC lifecycle usually looks like this:
- Inventory domains. List every domain the organization owns, including parked and legacy domains.
- Classify sending status. Decide whether each domain is active, non-sending, or unknown.
- Publish monitoring policy. Start with a reporting policy where needed so legitimate senders can be discovered.
- Fix legitimate senders. Align Microsoft 365, CRM, billing, ticketing, marketing, and alerting systems.
- Restrict non-sending domains. Publish policies that make clear the domain should not send mail.
- Move active domains toward enforcement. Progress from monitoring to quarantine or reject after validation.
- Monitor continuously. Treat new SaaS tools, new campaigns, and DNS changes as change-management events.
DMARC is not a full anti-phishing program by itself. It does not stop every lookalike domain, compromised mailbox, malicious attachment, or vendor invoice scam. But it does reduce one important class of abuse: unauthorized mail claiming to come from domains your business controls.
That makes it a natural companion to Microsoft 365 phishing protection services, security awareness training, conditional access, endpoint controls, and managed detection.
What should a DMARC domain inventory include?
A usable DMARC inventory should be simple enough for IT to maintain and specific enough for executives, auditors, and insurers to understand. The goal is not to create a beautiful spreadsheet that goes stale. The goal is to maintain a control record that supports real decisions.
For each domain, track:
- registered domain name
- registrar
- DNS host
- business owner
- technical owner
- renewal owner
- current business purpose
- active, non-sending, or unknown status
- approved sending platforms
- SPF record status
- DKIM status
- DMARC policy
- reporting mailbox or reporting service
- enforcement target
- last review date
- exceptions and expiration dates
Do not let “marketing owns that” or “the vendor set it up” be the final answer. Marketing may own the campaign outcome, but IT and security still need evidence that the domain is authenticated, monitored, and governed.
This is especially important for organizations using multiple SaaS tools. A common failure pattern looks like this: Microsoft 365 is configured correctly, but a CRM, payroll platform, billing system, survey platform, ticketing tool, recruiting platform, or marketing system sends on behalf of the domain without aligned authentication. The business then hesitates to enforce DMARC because legitimate mail might break. That hesitation can last for years unless someone owns the remediation plan.
If your team needs the technical baseline first, Datapath’s SPF, DKIM, and DMARC setup guide is the right companion piece. This article is the governance layer: how to make sure the work covers the whole domain portfolio, not just the obvious mailbox domain.
What DMARC policy should non-sending domains use?
A non-sending domain should eventually have a policy that tells receivers to reject mail claiming to come from that domain. Before jumping straight to enforcement, confirm that the domain truly does not send email through any legitimate platform.
A practical non-sending-domain checklist includes:
- confirm the domain is still owned and renewed intentionally
- confirm no business unit uses it for outbound mail
- confirm no SaaS platform is authorized to send from it
- remove stale SPF includes that are no longer needed
- remove unused DKIM selectors where appropriate
- publish or update DMARC
- route reports to a monitored mailbox or reporting tool
- move toward a reject policy once no legitimate sending is observed
For many businesses, non-sending domains are the fastest wins. They usually do not require coordination with HR, sales, finance, and marketing platforms. They require ownership, DNS access, and a willingness to close an unnecessary spoofing path.
The trap is assuming that a domain is non-sending because no one remembers using it. That is not evidence. Check DNS, mail flow, SaaS configurations, marketing tools, and DMARC aggregate reports first.
When should an active domain move from monitoring to enforcement?
An active domain should move toward enforcement after legitimate sending sources are known, authentication failures are remediated, and stakeholders understand the impact of enforcement. The business should not sit indefinitely at monitoring-only policy if reports show that legitimate mail is aligned and unauthorized mail is still appearing.
A staged approach usually works best:
- Stage 1: Discover. Publish a monitoring policy and collect reports.
- Stage 2: Normalize. Identify legitimate senders and remove obsolete systems.
- Stage 3: Fix. Configure SPF, DKIM, and alignment for approved senders.
- Stage 4: Contain. Move to quarantine for a defined percentage or scope where appropriate.
- Stage 5: Enforce. Move toward reject when evidence supports it.
- Stage 6: Govern. Add DMARC review to vendor onboarding, domain purchases, rebrands, and marketing launches.
The percentage rollout matters because email is operationally sensitive. A healthcare clinic cannot casually break patient communications. A school district cannot casually interrupt parent alerts. A financial firm cannot casually disrupt billing, ACH notices, or client service messages.
That does not mean enforcement should be avoided. It means enforcement should be managed like a real IT change: scoped, tested, documented, reviewed, and monitored.
Who should own DMARC in a mid-market business?
DMARC ownership should sit with IT or security, but the operating process must include marketing, finance, HR, operations, and any department that sends email through third-party platforms. A purely technical owner can publish records, but cannot always identify which SaaS senders are business-critical.
In a Central Valley business with lean IT staffing, the practical ownership model may look like this:
- IT/security: DNS, Microsoft 365, authentication records, monitoring, enforcement.
- Marketing: campaign platforms, newsletter systems, event domains, landing pages.
- Finance: billing, payment notifications, vendor communications.
- HR: recruiting, payroll, benefits, employee communications.
- Operations: dispatch, ticketing, customer notifications, alerts.
- Leadership: risk acceptance, enforcement deadlines, exception approvals.
This is why DMARC belongs in change management. New sending tools should not go live because a department pasted a DNS record from a vendor help article into a ticket. The request should include the domain, business owner, sender purpose, SPF/DKIM requirements, alignment impact, monitoring plan, rollback plan, and exception expiration.
For businesses that do not have time to run this internally, a managed partner can help build the inventory, clean up DNS, coordinate with SaaS vendors, and keep the program moving. Datapath’s Modesto managed IT services and Modesto cybersecurity services are designed for organizations that need security controls maintained as an operating discipline, not a one-time project.
What evidence should leadership ask for?
Leadership should not ask only, “Are we DMARC compliant?” That question produces vague answers. Ask for evidence by domain.
A useful executive DMARC review includes:
- total number of owned domains
- number of active sending domains
- number of non-sending domains
- number of unknown-status domains
- number of domains with DMARC records
- number of domains at monitoring, quarantine, and reject
- domains with no SPF or DKIM alignment
- third-party senders discovered in reports
- open exceptions and owners
- target dates for enforcement
- domains with unclear ownership
- high-risk domains tied to payments, healthcare, student data, or executive communications
This turns DMARC from a DNS detail into an accountability system. It also helps with cyber insurance discussions, vendor reviews, audit readiness, and incident response. If a phishing incident occurs, the business can quickly determine whether the abused domain was owned, protected, monitored, or unrelated.
What is the best first step?
The best first step is a domain inventory and sending classification. Do not start by changing production DNS records across the company. Start by identifying every domain the organization owns and deciding whether each one is active, non-sending, or unknown.
For many businesses, the first review uncovers surprises: domains no one remembers, vendor-managed DNS zones, stale SPF includes, duplicate marketing tools, former brand domains, and parked domains with no anti-spoofing policy.
Once the inventory exists, prioritize in this order:
- Domains used for employee email.
- Domains used for finance, invoices, payments, or vendor communication.
- Domains used for healthcare, student, legal, or regulated communications.
- Domains used by marketing automation or CRM platforms.
- Parked domains that should never send email.
- Legacy and acquired domains with unclear ownership.
This sequence balances risk and operational safety. It protects the domains most likely to be abused while giving IT enough evidence to avoid breaking legitimate business communication.
How can Datapath help?
Datapath helps Central Valley and multi-location organizations turn email authentication into a managed security control. That includes domain inventory, Microsoft 365 review, DNS cleanup, SPF/DKIM/DMARC alignment, SaaS sender validation, monitoring, and executive evidence reporting.
If your business has grown through new locations, campaigns, vendors, acquisitions, or years of “temporary” DNS changes, assume the domain portfolio needs review. The cost of finding stale domains during a calm assessment is much lower than finding them during a phishing incident.
For help reviewing your domain portfolio and Microsoft 365 email security posture, contact Datapath through the Datapath contact page.
FAQ
Does DMARC stop all phishing?
No. DMARC helps reduce unauthorized spoofing of domains you own, but it does not stop every phishing technique. Attackers can still use lookalike domains, compromised accounts, malicious links, attachments, social engineering, and vendor impersonation. DMARC should be paired with phishing protection, MFA, endpoint security, user training, and incident response.
Should parked domains have DMARC?
Yes. Parked domains should have an explicit policy because they are often not supposed to send email at all. A parked domain without a clear anti-spoofing posture can still create brand and fraud risk.
Is a monitoring-only DMARC policy enough?
Monitoring is a starting point, not the finish line. It helps identify legitimate and illegitimate senders, but it does not instruct receivers to block failing mail. Mature programs use monitoring to fix issues and then move toward quarantine or reject where operationally safe.
Who should receive DMARC reports?
DMARC reports should go to a monitored mailbox or reporting service owned by IT or security. Sending reports to an unattended mailbox defeats the purpose. Reports should be reviewed for new senders, authentication failures, vendor changes, and signs of abuse.
How often should DMARC records be reviewed?
Review DMARC whenever domains, DNS, email platforms, marketing tools, billing systems, ticketing tools, or CRM platforms change. At minimum, domain inventory and enforcement status should be reviewed quarterly for regulated or multi-location organizations.
Can a vendor configure DMARC for us?
Yes, but the business still needs ownership of the policy. Vendors can help with DNS records, reporting, and remediation, but leadership should know which domains exist, who owns them, which platforms send mail, and which exceptions remain open.
