Security and Microsoft 365

Why company email goes to spam or can be spoofed

By the Montreal IT team

A client says your invoice never arrived. A newsletter lands in junk. A vendor receives a fake message that appears to come from your domain.

These situations are different, but they often share one question: recipient systems are trying to decide whether the message is genuinely authorized to use your domain name.

Recipient systems weigh several signals. SPF, DKIM and DMARC are among the main ones.

A visible address is not proof of identity

The From field in an email resembles the return address on an envelope. Without validation, a sender can try to display an address they do not control.

This is email or domain spoofing.

Email authentication helps recipient systems verify:

  • which servers are authorized to send;
  • whether the message was signed by the domain;
  • whether technical domains align with the visible domain;
  • what to do when a message fails checks.

No single mechanism is enough. They work together.

SPF: which servers may send for the domain?

SPF is a DNS record listing sources authorized to send mail for a domain.

It may include:

  • Microsoft 365;
  • an invoicing system;
  • a newsletter platform;
  • a CRM;
  • a website;
  • a ticketing or form service;
  • a scanning or alerting service.

In practice, trouble often starts when:

  • a legitimate source was omitted;
  • multiple SPF records exist when there should be one;
  • the record exceeds technical lookup limits;
  • an old platform remains authorized;
  • the sender’s technical domain does not align with the visible domain.

SPF mainly checks the sending source. By itself, it does not fully protect the address shown to the recipient.

DKIM: was the message signed by the domain?

DKIM adds a cryptographic signature to the message.

The recipient uses a key published in DNS to verify that:

  • the message came from a system authorized to sign for the domain;
  • important parts were not modified in transit.

In Microsoft 365, DKIM should be enabled for each custom domain used to send mail.

Configuration often breaks down when:

  • DKIM was never enabled;
  • DNS records are missing or incorrect;
  • a third-party service signs with its own domain rather than yours;
  • a system modifies content after signing;
  • a migration left old configuration behind.

DMARC: what should happen when checks fail?

DMARC connects the visible domain to SPF and DKIM results.

It lets the domain owner publish a policy to:

  • monitor only;
  • quarantine failed messages;
  • reject them.

DMARC can also send reports showing which sources use the domain.

The reports can show:

  • a forgotten legitimate platform;
  • configuration mistakes;
  • an old system still sending;
  • spoofing attempts;
  • an unprotected subdomain.

Moving directly to rejection without an inventory may block legitimate mail. Deployment should begin by identifying sources, correcting SPF and DKIM, and then increasing enforcement in a controlled way.

Why legitimate email may still reach junk

Authentication is only one part of delivery.

Mail providers also evaluate:

  • IP and domain reputation;
  • sending volume and sudden changes;
  • complaints and rejection rates;
  • links and attachments;
  • repetitive or deceptive content;
  • poorly maintained recipient lists;
  • compromised sending systems;
  • forwarded or modified messages;
  • new sources without history;
  • consistency between the visible address, signature and sending path.

A message can pass SPF, DKIM and DMARC and still be filtered for other reasons. A poorly authenticated message may occasionally be delivered because of other recipient signals.

Websites and applications are often forgotten

A business configures Microsoft 365 correctly, then a web form, copier or accounting application begins sending under the same domain.

Without coordination, those messages may:

  • fail authentication;
  • be rejected;
  • land in junk;
  • force an overly complex SPF record;
  • use a shared password;
  • send through an old mailbox;
  • expose an account if the service is compromised.

Each sending source should have an owner, business purpose, authentication method and review date.

Why spoofing remains possible even with good filters

Recipient filters protect the recipient’s mailbox. They do not replace configuring your domain.

An attacker may also use:

  • a lookalike domain;
  • a misleading display name;
  • a genuinely compromised mailbox;
  • a stolen reply chain;
  • a legitimate but misconfigured service;
  • a personal account impersonating an employee.

SPF, DKIM and DMARC reduce direct domain spoofing, but they should be combined with:

  • multifactor authentication;
  • anti-phishing protection;
  • employee awareness;
  • independent verification of financial requests;
  • monitoring sign-ins and forwarding rules;
  • clear reporting procedures.

Quick email-domain review

A clearly scoped review should verify:

1. Which service receives email? 2. Which platforms send using the domain? 3. Is there one valid SPF record? 4. Is DKIM active for every sending domain? 5. Does DMARC exist and what policy does it apply? 6. Are DMARC reports received and reviewed? 7. Are subdomains and unused domains protected? 8. Are connectors, relays and forwarding documented? 9. Are old providers still authorized? 10. Do headers from a real message show consistent results?

The result should distinguish:

  • correct configuration;
  • legitimate source needing correction;
  • old source to remove;
  • spoofing exposure;
  • reputation or content problem;
  • action requiring another provider.

What to collect when a message is rejected

Keep:

  • the complete non-delivery report;
  • time of the event;
  • sender and recipient addresses;
  • service used to send;
  • headers from a received message when available;
  • recent DNS changes;
  • one working example and one failing example.

Avoid changing several DNS records at random. A quick change can make diagnosis harder or interrupt another platform.

A Microsoft 365 security assessment can review identities, privileges, forwarding rules, connectors and logging capability. A DNS and email-authentication review can be scoped separately around the actual sending systems.

When several services send using your domain, a managed and co-managed IT relationship can help keep owners, vendors and changes documented in one operating picture.

Contact Montreal IT to review SPF, DKIM, DMARC, sending sources and delivery evidence.

Related resources

Review business email and domain ownership Review email trust and spoofing