Email delivery used to be simple.
Set up SMTP, send emails, done.

That’s no longer true.

We recently investigated a case where a client’s system was sending thousands of transactional emails daily – and some of them were silently failing. No clear errors, no obvious pattern. Just users saying: “I didn’t receive the email.”

What we found is a good example of how modern email delivery actually works today.

The Symptoms

• Some users (especially @bellsouth.net) were not receiving emails at all
• Others (AOL/Yahoo) had messages going to spam or getting blocked
• Forwarding from internal mailboxes was failing
• Everything looked “correct” at first glance (SPF, DMARC already configured)

This is where things get tricky – because multiple independent issues can look like one.

Issue #1 – SPF Alignment Failure (SendGrid + Microsoft)

The first problem appeared in Microsoft-hosted domains (including Bellsouth).

Emails were rejected with errors like:

“sender’s domain doesn’t meet the required authentication level”

At the same time:

• DKIM = PASS
• DMARC = PASS
• SPF = FAIL

That combination is confusing if you’re used to older email rules.

What was happening

SendGrid was sending emails using its default return-path:

• From: @clientdomain.com
• Return-Path: sendgrid.net

SPF checks the Return-Path domain, not the visible From.

So:

• SPF validated against sendgrid.net
• But the visible sender was clientdomain.com

Result: SPF not aligned

Modern Microsoft policies require alignment, not just a pass.

The Fix

We configured SendGrid Domain Authentication with a custom return-path:

• emXXXX.clientdomain.com

After that:

• SPF = PASS
• SPF = ALIGNED
• DKIM = PASS
• DMARC = PASS

And the Microsoft blocks stopped immediately.

Issue #2 – Email Forwarding Blocked by Microsoft 365

Another reported issue was email forwarding failing completely.

Error:

“Your organization does not allow external forwarding”

This one had nothing to do with DNS or authentication.

What was happening

Microsoft 365 blocks automatic forwarding by default for security reasons (data exfiltration protection).

The message was rejected before SPF/DKIM/DMARC even matter.

The Fix

This must be handled in Microsoft 365:

• Enable forwarding per mailbox

or

• Allow external forwarding in outbound spam policy

No DNS change will fix this.

Issue #3 – Users Marking Emails as Spam (AOL/Yahoo)

We also found users who had marked system emails as spam.

Result:

• Future emails were silently blocked or filtered
• No bounce back to the system

In SendGrid, these show up as Spam Reports.

What was happening

Providers like Yahoo and AOL maintain per-user reputation.

If a user clicks “Spam”:

• Future emails from that sender may never reach inbox
• Sometimes not even the spam folder

The Fix

This cannot be solved from the server side.

The recipient must:

• Mark the email as “Not Spam”
• Add the sender to contacts / safe senders

Issue #4 – DNS Confusion (SPF, DKIM, DMARC)Issue #4 – DNS Confusion (SPF, DKIM, DMARC)

We also reviewed DNS configuration after a support request suggesting missing records.

Findings:

• SPF was already correctly configured
• DMARC was already active (with quarantine policy)
• DKIM for SendGrid was already set

The only potential addition:

• DKIM for another provider (if used)

Key takeaway here

Many support teams default to:

“Add SPF/DKIM/DMARC”

But in real systems:

• They are often already correct
• The problem is alignment, policy, or provider behavior

What This Case Shows

Modern email delivery is no longer about “having SPF and DKIM”.

It’s about:

• Alignment (SPF + DKIM vs From domain)
• Provider-specific policies (Microsoft, Yahoo)
• User behavior (spam marking)
• System configuration (forwarding rules)

Final Takeaways

If you’re troubleshooting email delivery today:

1. Don’t stop at “SPF/DKIM exist”
2. Check alignment, not just pass/fail
3. Separate:
   • authentication issues
   • policy blocks
   • user-level actions
4. Expect different behavior across providers

Email infrastructure has become a system of interacting rules – not a checklist.

Understanding that difference is what turns “random delivery issues” into solvable problems.