During security audits, Microsoft 365 migrations, or messaging platform reviews, we often come across the same issue: email authentication is usually taken for granted—until something goes wrong.
The first warning signs
Sometimes, the first sign is a support ticket saying that a business application can no longer deliver notifications to certain recipients. In other cases, security teams are alerted to fraudulent emails using the company’s domain being sent to customers or partners. More recently, we have also seen DMARC reports reveal unknown sending sources or recurring authentication failures that had never been identified before.
In most cases, though, nothing appears to be obviously wrong. Users can still send and receive email, business applications continue to work normally, and messaging platforms report no major incidents.
When weaknesses start to show
A closer look often reveals weaknesses in email authentication mechanisms, particularly SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).
These protocols help mail servers verify who is really sending a message, check that the message has not been altered, and distinguish legitimate email from spoofing attempts or spam. When they are missing, poorly configured, or no longer reflect the way email is actually being sent, the consequences can quickly go beyond the purely technical.
Why SPF and DKIM are not enough
Two common situations IT teams encounter illustrate the problem.
-
Scenario one: a security team is investigating spoofing campaigns using the organisation’s domain. The investigation shows that some subdomains have no effective DMARC policy, or that several third-party services are authorised to send email on behalf of the organisation without appropriate controls in place.
-
Scenario two: email administrators are trying to understand why notifications sent by a SaaS platform or an internal application repeatedly fail SPF or DKIM checks at certain providers.
Both situations have one thing in common: they reveal a weakness in how the email service is managed.
Insufficient email authentication is not just about a few misconfigured DNS records. It has a direct impact on deliverability, domain reputation, visibility into email flows, and the organisation’s ability to protect itself against spoofing attacks.
Increasingly strict requirements
The email landscape has changed significantly. Since February 2024, providers such as Gmail, Yahoo, and Microsoft have tightened their email authentication requirements, especially for high-volume senders. These are no longer simply best-practice recommendations. They have become an essential part of operational security and email deliverability.
This shift is driven by the continued rise in email abuse. SPF, DKIM, and DMARC are now used not only to identify legitimate senders, but also to inform reputation systems, spam filters, and other trust mechanisms used by major email providers.
Multiple sources of weakness
Even in environments that appear to be well configured, several factors can weaken email authentication.
-
Subdomain vulnerabilities: in many organisations, most security efforts focus on the main domain. Yet subdomains used for specific projects, business applications, or legacy services often receive less scrutiny. These gaps create opportunities that attackers can exploit to launch spoofing campaigns or bypass certain protections.
-
Poor integration of third-party services: modern email environments rarely rely on a single sending platform. SaaS applications, ITSM tools, HR systems, CRMs, ticketing platforms, and monitoring tools may all send email on behalf of the organisation. If they are not properly integrated with SPF, DKIM, or DMARC, authentication failures can quickly arise.
-
DNS configuration that degrades over time: we often see environments where DNS records have accumulated over years of migrations, provider changes, and infrastructure updates. Outdated SPF mechanisms, unused DKIM selectors, or DMARC policies left over from previous projects can make it difficult to understand the actual configuration.
-
Failures caused by email forwarding: some intermediary systems modify headers or parts of a message when forwarding it. Depending on how the system is configured, those changes can invalidate a DKIM signature and cause authentication to fail even though the original message was entirely legitimate.
-
Different behaviour across email providers: not all providers handle authentication in exactly the same way. A message accepted by Microsoft 365 may be treated differently by Gmail or Yahoo depending on reputation mechanisms, DMARC alignment, and the observed sending context.
-
Cumulative impact on domain reputation: authentication failures do not happen in isolation. They contribute to the domain’s overall reputation and can, over time, affect the organisation’s ability to successfully deliver legitimate communications.
Beyond the initial setup
Email authentication is often seen as a purely operational matter, limited to a few DNS records or to settings put in place during a messaging platform migration. Our experience, however, shows that the reality is much more complex.
Over time, infrastructures evolve, new services are introduced, applications are integrated, and email flows multiply. Without clear governance and regular reviews, it becomes difficult to ensure that all sending sources are properly authenticated and aligned with the organisation’s security policies.
SPF, DKIM, and DMARC are not simply requirements imposed by email providers. They are now fundamental controls for establishing trust in a domain’s digital identity. They help protect users against spoofing attempts, improve visibility into email flows, and reduce the risks associated with third-party services that are not properly managed.
What this means in practice
In our work, we often find that the problem is not a complete lack of authentication, but rather an incomplete understanding of sending sources, an accumulation of legacy configurations, or a lack of oversight as the infrastructure evolves.
These gaps often remain unnoticed until an incident occurs, a deliverability issue appears, or a spoofing campaign targets the organisation’s domain.
The goal is therefore not simply to deploy SPF, DKIM, or DMARC, but to make sure these protocols accurately reflect actual email flows and evolve in step with the infrastructure they are designed to protect.
Ultimately, the question may not be whether your domain has an SPF record, a DKIM signature, or a DMARC policy.
The real question is whether you can confidently identify who is authorised to send email on behalf of your organisation, how those messages are authenticated, and whether the current configuration still reflects the reality of your environment.
That is usually the starting point for truly taking control of your email environment and securing it effectively.