Skip to content

Authentication is not just another spam filter.

Most Microsoft 365 tenants have a spam filter turned up and email authentication left half-finished. SPF, DKIM, and DMARC are the domain-level records that decide whether other mail systems trust a message sent from your domain, and whether someone else can convincingly pretend to be you.

Book a scoping call

What each record actually checks.

  • SPF

    SPF says who's allowed to send

    Sender Policy Framework lists which mail servers may send email claiming to be from your domain. A receiving server checks that list before deciding whether to trust the message.

  • DKIM

    DKIM proves the message wasn't altered

    DomainKeys Identified Mail attaches a cryptographic signature to outgoing mail, so a receiving server can confirm the content wasn't changed in transit.

  • DMARC

    DMARC decides what happens when a check fails

    Domain-based Message Authentication tells receiving servers whether to deliver, quarantine, or reject mail that fails SPF or DKIM, and can send a report back showing what's actually happening.

  • Together

    Each one alone leaves a gap

    SPF without DMARC still lets a convincing look-alike message through. DKIM without SPF still lets an unauthorized server send. The three work as a set, not a menu to pick from.

Records, not a spam filter.

Authentication decides who's allowed to speak for your domain. Spam filtering just judges the message.

A spam filter reads the content of an incoming message and guesses whether it's junk. SPF, DKIM, and DMARC do something earlier and more structural: they let a receiving mail server check whether a message claiming to be from your domain was actually allowed to be sent that way. A well-tuned spam filter and a half-finished DMARC record solve two different problems, and plenty of Microsoft 365 tenants have the first without the second.

This matters most for the messages that never reach an inbox to be filtered at all—a look-alike invoice sent to one of your customers, or a spoofed message that appears to come from your own domain and lands in a partner's inbox instead of yours. Getting the record right doesn't need a security review. It needs someone to actually finish the configuration, then check it stays correct as the tenant adds new sending sources.

The same half-finished record, three different mornings.

A new tool starts sending on your behalf

Marketing platforms, invoicing software, and helpdesk tools all send mail as your domain. Each one needs adding to SPF and signing with DKIM, or its mail starts failing checks somewhere downstream.

DMARC is set to monitor, and stays there

A safe starting policy is meant to be a first step, not a permanent setting. Left unenforced for years, it quietly collects reports nobody reads instead of blocking anything.

A partner mentions mail "landing in spam"

The actual cause often isn't content or sender reputation at all—it's a missing or broken authentication record the sender never knew to check.

Five recurring checks.

  • SPF still lists every service that legitimately sends mail as your domain, and nothing else
  • DKIM signing is active for Microsoft 365 and every connected sending service
  • DMARC policy has moved beyond monitor-only once reports show mail behaving as expected
  • DMARC aggregate reports are checked for sending sources nobody recognizes
  • A newly adopted marketing, invoicing, or helpdesk tool is added to the record before it starts sending

A chronic deliverability problem is a separate, specialist question.

Getting flagged as spam can involve sender reputation, message content, and recipient engagement well beyond these three records. Fixing a deliverability problem that persists after authentication is correctly configured needs its own specialist review, not an assumption folded into routine tenant hygiene.