Why Office 365 Direct Send Emails Get Flagged as Spam

You set up Office 365 direct send for internal relay or transactional email. The emails are legitimate. No malicious content. But recipient gateways flag them as spam or phishing.

The problem is not your content. It is how the sending IP relates to the From address domain.

This happens to sysadmins regularly. Here is why it occurs and how to fix it.

What direct send actually does

Office 365 direct send routes email through Exchange Online transport without using a sending connector. The emails leave Microsoft infrastructure from IP addresses that belong to your Microsoft 365 tenant.

When a user in your tenant sends an email via direct send, Exchange Online uses its own transport IPs as the sending endpoint. The From address is your tenant domain. The envelope sender may also be your tenant domain.

At first glance this looks fine. Exchange Online is a legitimate mail server. But recipient spam filters do not just check whether the sending server is reputable. They check whether the From address domain is authorized to send from that IP.

Why SPF alignment is the core problem

SPF has a rule: the domain in the RFC5321 Mail From command (envelope sender) must be authorized to send from the connecting IP. Most SPF checks also apply an alignment check: the domain in the RFC5322 From header must match the domain authorized by SPF, unless DKIM is signed and aligned.

Direct send creates a gap here. When your tenant domain appears in the From header but the actual sending IP is an Exchange Online transport IP, the From domain must either:

have an SPF record that includes the Office 365 sending IPs, or
have a DKIM signature that is aligned and passes DMARC

Most tenant domains do not include all Exchange Online transport IPs in their SPF record. Many tenant domains have no custom SPF record at all beyond the default Microsoft SPF include. When a recipient gateway evaluates the email, it sees an SPF failure or softfail against the From domain and escalates the email to spam or phishing.

This is not a bug in Office 365. It is an expected consequence of the way direct send works. The From domain you see in the email header does not automatically inherit the sending reputation of the Office 365 infrastructure.

DKIM and direct send

Exchange Online can apply DKIM signatures to outbound email automatically for your verified domains. When DKIM is working, the email carries a DKIM signature that proves the message was signed by your tenant.

However, DKIM alone does not solve the alignment problem under DMARC. DMARC requires either SPF alignment or DKIM alignment (or both). If your From domain uses DKIM but the signature is for a subdomain or a domain that does not match the From header exactly, DMARC alignment still fails.

For direct send specifically, the question is whether the DKIM signature covers the exact domain in your From header. If you are sending from noreply@example.com but your DKIM is signed for example.com and the DMARC policy is p=reject, you may still fail DMARC.

How DMARC makes the problem visible faster

If you have DMARC monitoring in place, you will see these alignment failures in your aggregate reports before recipients complain. The reports will show a high volume of SPF fail or DKIM fail results for your direct send traffic, with the From domain clearly identified.

Without aggregate reports, you only find out there is a problem when someone reports a missing email or a spam folder complaint.

This is one of the reasons alignment failures from direct send tend to persist undetected. The emails appear to send successfully from your side. The bounce rate may be low. The problem only surfaces at the recipient gateway, where it is out of your sight.

How to diagnose which authentication mechanism is failing

Check your DMARC aggregate reports for the From domain in question. Look for:

SPF result: fail or softfail with the sending IP
DKIM result: fail or none
DMARC result: fail

If you see SPF failures, the From domain SPF record does not include the Office 365 sending IPs. If you see DKIM failures, either DKIM is not enabled for the domain or the signature does not align with the From header.

Aggregate reports break this down by source IP and From domain, so you can see exactly which direct send flows are failing and why. DMARCFlow processes these reports automatically and surfaces which IPs are causing alignment failures, so you do not have to parse raw XML to find the problem.

How to fix it

The fix depends on your sending scenario.

Option 1: Add Office 365 IPs to your SPF record

If you are sending from a specific domain and you want to keep direct send, add the Office 365 sending IPs to that domain's SPF record. Microsoft publishes the full list of Exchange Online IP ranges.

Your SPF record for the sending domain would include something like:


v=spf1 include:spf.protection.outlook.com ~all

If your From domain is different from your Microsoft 365 tenant domain, you may need to use a custom SPF record that covers the specific IPs used by your transport.

This approach works but requires ongoing maintenance as Microsoft updates its IP ranges.

Option 2: Use a connector with proper alignment

If you need reliable delivery to strict recipient gateways, switch from direct send to a connector-based send. Exchange Online connectors handle envelope sender rewrite so that the sending domain aligns with the From header. This eliminates the SPF alignment gap entirely.

The tradeoff is configuration complexity. Connectors require more setup than direct send.

Option 3: Ensure DKIM alignment

If you prefer to keep direct send, make sure DKIM is enabled for the exact From domain and that your DMARC policy accepts DKIM alignment. Set p=none or p=quarantine while testing, and monitor aggregate reports to confirm DKIM is passing before moving to p=reject.

How to confirm the fix is working

After applying any of the fixes above, check your DMARC aggregate reports again. You should see:

SPF: pass for the From domain, or DKIM: pass with aligned domain
DMARC: pass

You should also ask recipients to check their quarantine and spam folder logs to confirm the emails are landing in the inbox.

Ongoing monitoring matters here. Microsoft can change which IP addresses your tenant uses for transport. If you are relying on a fixed IP list in your SPF record, you will need to update it periodically.

FAQ

Does direct send use a connector? No. Direct send bypasses connector logic. Emails are injected directly into Exchange Online transport and sent from Microsoft's transport IPs. No connector means no envelope rewrite, which is why alignment can fail.

Can I use DKIM with direct send? Yes. Exchange Online DKIM signing applies to direct send traffic. The question is whether the DKIM signature domain aligns with your From header domain. If your From address is noreply@example.com and your DKIM is signed for example.com, that may or may not satisfy DMARC depending on your policy and whether the domains are the same.

Should I switch from direct send to a connector? If you are sending marketing, transactional, or any external-facing email and deliverability matters, use a connector. Direct send is appropriate for internal relay within your tenant or for scenarios where you control both ends of the communication.

How do I monitor whether direct send is causing alignment failures? DMARC aggregate reports are the most reliable way. They show authentication results per source IP and From domain, broken down by disposition. You can see exactly which emails are failing SPF or DKIM and which From domains are affected.

What to do next

If you are seeing direct send emails flagged as spam, pull your DMARC aggregate reports for the From domain in question. Identify which authentication mechanism is failing. If it is SPF, either update your SPF record or switch to a connector. If it is DKIM, check whether alignment is configured correctly for your From domain.

If monitoring aggregate reports manually is not practical, use a tool that processes them automatically. DMARCFlow aggregate report processing surfaces which source IPs and From domains are failing authentication for your direct send traffic, so you can confirm the fix is working without manually reviewing XML files.

The fix is usually straightforward. The problem is finding it without aggregate reports.