Email remains a common delivery method for phishing, business email compromise, and impersonation attacks. Microsoft Defender can catch a great deal, but the authentication policies published for your own domain are another critical layer of protection.
If SPF, DKIM, and DMARC are missing or incorrectly configured, attackers may have more opportunity to send messages that appear to come from your organization.
Why spoofing is still a major threat
Email spoofing is when an attacker sends a message that appears to use your company's domain even though the message did not originate from an authorized system.
That can lead to fake invoice or payment-change requests, executive impersonation, fraudulent file-sharing links sent to partners, and damage to both brand trust and email deliverability.
SPF: who is allowed to send?
SPF (Sender Policy Framework) publishes an approved list of systems that are allowed to send email on behalf of your domain.
When a receiving server gets a message claiming to come from your domain, SPF gives it a way to check whether the sending infrastructure is authorized.
SPF is useful, but it is not enough on its own. SPF checks the return-path domain, which does not always match the visible From domain users see in their inbox.
DKIM: was the message signed and preserved?
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound email. Receiving systems can verify that signature using a public key published in DNS.
This helps recipients confirm that the message came through a system authorized to sign for the domain and that the signed content was not altered in transit.
DMARC: do the identities align, and what happens when they don't?
DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM to the visible From domain and adds an enforcement policy.
DMARC asks whether SPF or DKIM authenticated in a way that aligns with the From domain, and it tells receiving systems what to do when authentication fails.
- p=none — monitor without requesting enforcement.
- p=quarantine — ask recipients to treat failing mail as suspicious.
- p=reject — ask recipients to reject mail that fails DMARC.
DMARC reporting also provides visibility into who is sending mail that claims to be your domain and which sources are passing or failing authentication.
Why this matters even if you use Microsoft 365
Your customers, vendors, and other receiving systems rely on DNS-based authentication to validate messages that claim to come from you. Attackers do not have to operate inside your Microsoft 365 tenant to spoof your domain.
Strong authentication therefore protects more than your own inboxes. It helps protect your organization's identity across the broader email ecosystem.
Common configuration problems
- Publishing multiple SPF records instead of one valid SPF policy.
- Exceeding SPF's limit of 10 DNS lookups.
- Enabling DKIM for Microsoft 365 while overlooking third-party senders such as CRMs, marketing platforms, or ticketing systems.
- Leaving DMARC at
p=noneindefinitely without moving toward enforcement. - Allowing SPF or DKIM to pass while failing DMARC because the authenticated domain does not align with the visible From domain.
A practical path to stronger domain protection
Start by inventorying every legitimate service that sends mail using your domain. Publish exactly one valid SPF record, enable DKIM signing for each appropriate sender, and then use DMARC reporting to identify gaps before increasing enforcement.
A common progression is to begin with monitoring, move to quarantine as legitimate senders are validated, and ultimately move toward reject when the environment is ready.