For many businesses in South East Queensland, the configuration of email security records is often viewed as a one-time setup task. During the initial migration to Microsoft 365 or the launch of a new domain, technical records are published to DNS, verified once, and then left untouched. However, maintaining a secure email environment is not a static state achieved through configuration alone; it is a discipline of ongoing governance.

It is common to find environments where SPF, DKIM, and DMARC records exist but no longer reflect the actual operational reality of the business. When security records are ungoverned, they become stale, inaccurate, and eventually fail to provide the protection they were intended to offer.

Email security governance is the practice of documented visibility, active review, and tested response. It moves the conversation from "do we have these records?" to "are these records accurate, and what policy are they enforcing today?"

Defining the Email Security Posture

Before addressing the governance of these systems, it is necessary to understand the components that form a modern email security posture. These protocols work together to verify that an email is legitimate and has not been tampered with.

SPF (Sender Policy Framework): A DNS record that specifies exactly which mail servers and third-party services (such as CRMs or marketing platforms) are authorised to send email on behalf of your domain.
DKIM (DomainKeys Identified Mail): A digital signature attached to your outgoing emails. It uses cryptography to prove that the email was sent from your domain and that its content was not altered in transit.
DMARC (Domain-based Message Authentication, Reporting, and Conformance): The enforcement policy that ties SPF and DKIM together. It instructs receiving mail servers on what to do if an email fails authentication: whether to let it through, put it in the junk folder, or reject it entirely.
Mail Flow Rules and Anti-Phishing Policies: Internal Microsoft 365 configurations that define how incoming and outgoing messages are handled, including specific protections against impersonation and spoofing.

The Default State: Configuration vs. Governance

The standard approach for many small to medium-sized businesses is to configure these records once and then forget them. This "set and forget" mentality creates a significant gap between the perceived security posture and the actual risk.

Over time, businesses evolve. New marketing tools are adopted, CRM systems are integrated, and transactional email services are added to support website functions. If the SPF record is not updated to include these new senders, legitimate business emails may be flagged as spam. Conversely, if a business stops using a particular service but leaves it in the SPF record, that service remains an authorised sender for the domain, creating an unnecessary security vulnerability.

The core misconception is that having the records configured equals being protected. In reality, a record that has not been reviewed in twelve months is a liability. Real governance means the business can answer four critical questions at any time:

What specific records do we have configured?
Are those records current and accurate for our current technology stack?
What enforcement policy (DMARC) is currently being applied?
Who is responsible for reviewing these records, and how often does that review occur?

The Four Pillars of Email Security Governance

Moving from passive configuration to active governance rests on four primary pillars. These pillars ensure that your managed IT services provide more than just a functional mailbox; they provide a secure, validated environment.

1. Documented Record State

Governance begins with visibility. You cannot govern what you cannot see. A business should maintain a current, accurate inventory of all email-related DNS records. This includes:

A list of every "include" in your SPF record, with a clear note explaining which third party (e.g., Microsoft, Mailchimp, Xero) it belongs to.
Documented DKIM selectors and the platforms they are associated with.
The current DMARC policy (p=none, p=quarantine, or p=reject) and the specific email addresses designated to receive aggregate reports.

2. Defined Review Cadence

Records should be validated on a quarterly basis at minimum. This is not a deep technical rebuild, but a verification step to ensure:

SPF records remain within the 10-lookup DNS limit (exceeding this limit causes SPF to fail silently).
Stale senders who are no longer used by the business are removed.
DKIM keys are still active and are rotated according to a sensible security schedule.
DMARC reports are being reviewed to identify any unauthorised attempts to use the domain.

3. Mail Flow and Policy Ownership

Mail flow rules and anti-phishing policies within Microsoft 365 often accumulate over time. Governance requires that every rule has a documented purpose and a clear owner. Without documentation, IT teams are often hesitant to remove old rules for fear of "breaking something," leading to a cluttered and potentially conflicting set of policies that are difficult to manage.

4. Alert and Response Process

Security policies are only as effective as the response they trigger. If an anti-phishing policy flags a high-risk impersonation attempt, where does that alert go? Alerts that are sent to an unmonitored mailbox or a generic "info@" address are effectively ignored. Governance defines who owns the alert, how it is escalated, and what the tested response routine looks like.

Common SMB Pitfalls in Email Security

When email security is left ungoverned, several common technical failures tend to emerge:

The 10-Lookup SPF Limit: DNS has a limit of 10 lookups for an SPF record. As businesses add more third-party services, it is easy to exceed this limit. Once the limit is hit, many receiving mail servers will simply treat the SPF record as invalid, causing deliverability issues that are difficult to diagnose.
DKIM Stagnation: DKIM keys should be rotated periodically to maintain security. Often, keys are set up once and never touched again. If a third-party sender is compromised, an old DKIM key could potentially be used to sign fraudulent messages that appear legitimate.
DMARC "Monitor Mode" Indefinitely: Many businesses implement DMARC at p=none. This is a monitoring phase designed to collect data without blocking any mail. However, many stay in this phase forever. While p=none provides visibility, it provides zero enforcement. Governance involves a planned progression toward p=quarantine and eventually p=reject.
Ungoverned Subdomains: Attackers often look for subdomains (like dev.yourdomain.com.au or marketing.yourdomain.com.au) that do not have their own SPF or DMARC records. Without a governed policy that covers all subdomains, your primary domain's reputation can still be damaged by spoofing on a secondary record.

The DMARC Policy Progression Path

Progressing your DMARC policy is a primary objective of email security governance. It is a journey from visibility to strict enforcement. This path must be managed carefully to ensure that legitimate business communication is not accidentally blocked.

Monitoring (p=none): The starting point. You receive reports about who is sending mail on your behalf, but no mail is blocked. This allows you to identify legitimate senders that were missing from your SPF or DKIM records.
Risk Reduction (p=quarantine): Once you are confident that all legitimate senders are authorised, you move to quarantine. Emails that fail authentication are sent to the recipient's junk folder.
Strict Enforcement (p=reject): The final goal. Emails that fail authentication are rejected by the receiving server and never reach the recipient. This provides the highest level of protection against domain spoofing.

Integration with Incident Response and Monitoring

A governed email security posture does not exist in a vacuum; it is a critical component of your broader security strategy. Email is the most frequent entry point for phishing and business email compromise (BEC). Therefore, the data generated by your email security protocols must be integrated into your logging and monitoring routines.

When a DMARC report shows a spike in failed authentication attempts from a specific geographic region, or when an anti-phishing policy triggers a high-severity alert, the business needs to be ready. This is where incident response readiness becomes vital. Governance ensures that the technical alerts from your email system are transformed into actionable information for your security team.

Practical First Steps for Governance

If your business has records configured but lacks a governance framework, these steps provide a path forward:

Audit the Current State: Retrieve your actual SPF, DKIM, and DMARC records from your DNS provider. Do not rely on what you think is there; look at the live records.
Document the Inventory: For every entry in your SPF record, identify the associated service. If you find an entry and no one in the business knows what it is for, mark it for investigation.
Establish the Review Cadence: Schedule a recurring calendar invite for a quarterly review. The goal of this review is to confirm the inventory is still accurate and to check DMARC reports for anomalies.
Assign Alert Ownership: Identify which individual or team is responsible for monitoring email security alerts in the Microsoft 365 Defender portal. Ensure they have a defined process for investigating and closing those alerts.
Set a DMARC Goal: If you are currently at p=none, set a target date to move to p=quarantine. Use the intervening time to ensure all legitimate senders are correctly authenticated.

Conclusion

Configuration is a technical event, but governance is an organisational habit. Having SPF, DKIM, and DMARC records is a necessary starting point, but without a documented inventory, a regular review cadence, and clear ownership of alerts, those records offer a diminishing level of protection.

By treating email security as a governed discipline rather than a one-off task, businesses can ensure their communication remains secure, their domain reputation is protected, and their IT environment remains stable. To discuss how to implement a governed security posture for your organisation, speak with Moreton Bay IT.

Microsoft 365 Email Security Governance: Why Having SPF and DKIM Is Not the Same as Being Protected

Defining the Email Security Posture

The Default State: Configuration vs. Governance