An employee sends a proposal or an invoice. It sits in Sent Items with no error. The customer never sees it, or finds it in junk a week later.
When Microsoft 365 emails going to spam becomes a pattern, the first assumption is that Microsoft 365 is broken. It rarely is. The cause is usually a DNS record, and the fix is usually small.
Sent Items Does Not Prove Delivery
A message in Sent Items only proves that it left the mailbox. It says nothing about whether the receiving system accepted it, filtered it or sent it to junk. Each receiving system judges the message on its own, and it looks hard at whether the sender is allowed to use the domain in the From address.
What SPF, DKIM and DMARC Do for Microsoft 365 Email
These three records are checks that prove a message really came from your business.
- SPF lists the servers and services allowed to send mail for your domain
- DKIM adds a digital signature that shows your domain approved the message and nobody altered it
- DMARC confirms that the SPF or DKIM result lines up with the domain the recipient sees, and tells receivers what to do when it does not
Without these checks, anybody could impersonate anybody. That is a serious security risk, so receiving systems treat missing or broken records as a warning sign.
The Usual Culprit Is DKIM, Then SPF
When a client’s mail lands in junk or gets rejected, DKIM is the problem we find most often. SPF is a close second. The records usually exist, yet they are misaligned, incomplete or missing a service.
Microsoft’s own email authentication troubleshooting guidance describes the same pattern. DMARC needs SPF or DKIM to pass and to align with the From domain. A service that sends on your behalf can pass for its own domain and still fail for yours.
Forwarding and security gateways add another wrinkle. Microsoft notes that forwarding breaks SPF alignment, and a gateway that modifies a message can invalidate its DKIM signature.
Third-Party Senders Break Things Quietly
The trouble often starts when a business adds a service. A client begins sending newsletters through Mailchimp or SendGrid, or a billing platform or CRM starts sending email. Each of those tools needs records in your DNS that prove it may send on your behalf. Without them, the mail fails authentication and lands in junk or gets rejected.
That is why we like to know what a client is doing from a marketing standpoint before the first campaign goes out. Standardizing on a small set of sending services keeps the records manageable and the results predictable.
When the Wrong Records Make Things Worse
Adding records is not a harmless fix. A domain can have only one SPF record, and a second one makes SPF fail outright. SPF also allows a maximum of 10 DNS lookups. Each include counts, so a stack of services can push a record over the limit and cause deliverability problems on some systems.
The remedy is to split or trim the record. It can be done, but it is a little tricky. We review the lookups so nobody adds services at random. Most clients rely on a short list, such as a CRM, Microsoft 365, the mail gateway, which is a single IP, and a few other services. The limit does not come up often, though it matters when it does.
This is also why DNS changes belong in a controlled process. A well-meaning edit can remove a record that mail depends on, a risk we covered in our post on business domain name ownership.
When the Other Side Has the Broken Records
The same checks work in the opposite direction. When a legitimate sender has a DKIM or SPF problem, our mail gateway can block their message to a client. We can exempt that sender from SPF or DKIM checking in Barracuda so the mail gets through.
We also ask the recipient to tell the sender about the problem. It does not stay with us. Other recipients that run strict checks outside our gateway will block that sender too, and the sender may never find out.
How We Find the Real Cause
At onboarding, we look at the client’s DNS records and run them against the appropriate validators to confirm everything aligns. An experienced eye can read an SPF record and tell quickly whether it fits the services in use.
For a live problem, a message trace and the message headers show which check failed and why. That turns a vague complaint about spam into a specific record to fix.
That review is part of our Microsoft 365 services and our cybersecurity services. It also supports the layered email protection approach we recommend. If your messages say sent but your customers say they never arrived, start with the records.