Provider deliverability · All major providers (Gmail, Outlook, Yahoo, iCloud)
Why are my emails being blocked?

By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 17, 2026
Emails get blocked for four main reasons: your domain fails SPF, DKIM, or DMARC checks, your spam complaint rate crossed the provider's threshold, your IP or domain sits on a blocklist, or you broke a bulk-sender rule. Read the bounce to identify the provider, fix authentication first, then check blocklists and complaint data.
The 30-second check
Start with the symptom. Bounced mail comes back with an NDR naming the blocking server; silently missing mail was accepted and junked. Either way the diagnosis begins with your own domain, because every major provider now gates on the same three records. The free email security score below grades SPF, DKIM, DMARC, and the rest of your domain's mail security in one pass.
Check your domain now
Enter your sending domain and the check runs instantly on the next page. Free, no signup.
Why All major providers is blocking your email
| Likely cause | What's happening |
|---|---|
| Your domain fails SPF, DKIM, or DMARC | Since 2024 authentication is the entry ticket everywhere. Gmail and Yahoo require SPF or DKIM to pass for every sender; Gmail demands SPF plus DKIM plus a DMARC policy once you send 5,000+ messages a day, and Yahoo imposes the same trio on bulk senders while explicitly declining to publish a volume threshold; Microsoft enforced the same trio for domains sending 5,000+ daily messages to Outlook.com from May 5, 2025; Apple lists SPF, DKIM, and a published DMARC policy among its bulk requirements for iCloud Mail, with rejection if they're not met (each provider's own documentation, checked 2026-07-17). |
| Your spam complaint rate crossed the provider's line | Gmail tells senders to keep the spam rate in Postmaster Tools below 0.3% and recommends staying under 0.10%; Yahoo publishes the same 0.3% ceiling. Microsoft names the junk-complaint rate one of the principal factors driving a sender's reputation down but publishes no number, and Apple publishes none either; both still filter on user feedback. Past the line, even fully authenticated mail stops arriving. |
| Your sending IP or domain is on a blocklist | Microsoft runs an internal block list; the tell is a marker like S3150 inside a 550 5.7.1 bounce, and the remedy is Microsoft's self-service delist portal. Public DNS blocklists feed corporate gateways and smaller providers. Shared IPs inherit listings from noisy neighbors, so you can be listed without ever sending a bad message yourself. |
| Broken sending infrastructure: reverse DNS, TLS, dynamic IPs | Gmail's guidelines require valid forward and reverse DNS (PTR records) and a TLS connection from every sender, and Apple asks bulk senders to publish reverse DNS that identifies their IPs. Direct-to-MX mail from dynamic or residential IP space barely gets accepted anywhere; Microsoft rejects it outright with its DY-class codes. These basics fail silently until a provider tightens enforcement. |
| You broke a bulk-sender list rule | Gmail and Yahoo require one-click unsubscribe in marketing mail, and Yahoo requires unsubscribes honored within two days. Apple requires explicitly subscribed recipients only (no purchased, rented, or appended lists) plus ARC headers on forwarded mail. Blasting a stale or bought list also drives the complaint rate that the second cause above punishes. |
| No sending history: new domain, new IP, or a volume spike | Every major filter rate-limits senders it has never seen. A new domain or IP starting at full volume reads as a spam cannon and collects deferrals (421-class codes) before outright blocks. No provider publishes a warm-up schedule; Apple tells bulk senders to keep sending IPs and domains consistent, which is the same advice from the other direction. |

How to fix it, step by step
Run the email security score on your sending domain
Use the free checker above (or at /tools/email-security-score). It grades SPF, DKIM, DMARC, and the rest of your domain's mail security in one pass and shows which record is missing, misaligned, or failing, which settles the most common cause before you chase anything else.
Read the bounce, or notice there isn't one
A rejection returns an NDR with an SMTP code and the blocking server's name; that code plus the reference at /learning/smtp-error-codes tells you which provider refused the mail and why. No bounce and no reply usually means silent spam-foldering: send tests to mailboxes you control at each major provider and see where they land.
Fix SPF, DKIM, and DMARC for every sending service
Add each platform that sends as your domain to your SPF record, enable DKIM signing with your own domain rather than the provider's default, and publish a DMARC record. Verify with the free checkers at /tools/spf, /tools/dkim, and /tools/dmarc; Gmail, Yahoo, and Microsoft all require the passing domain to align with your From address at bulk volume.
Check the blocklists and request removal
Run your sending IP and domain through /tools/blocklist-checker. For a Microsoft block, submit the IP at sender.office.com; for public lists, follow each list's own delisting process. Fix the root cause first, because delisting a still-broken sender is a round trip back onto the list.
Enroll in the providers' own reputation programs
Google Postmaster Tools shows your spam rate and reputation with Gmail; Microsoft's SNDS and JMRP do the same for Outlook.com; Yahoo's Complaint Feedback Loop sends you a copy of every complaint. Apple offers no feedback loop; its postmaster contact is icloudadmin@apple.com with your domain, sending IPs, and the SMTP errors you received.
Go provider-specific and re-test
Once you know who is blocking you, follow the per-provider guides linked below for that filter's quirks: Outlook's SmartScreen and delisting, Gmail's sender requirements, Yahoo's feedback loop, iCloud's bulk rules. After DNS changes propagate, re-send and confirm spf=pass, dkim=pass, and dmarc=pass in the received headers.
Related free tools: SPF checker · DKIM checker · DMARC checker · Blocklist checker · Domain reputation
If you send in volume: All major providers's published rules
Three of the four major providers publish hard bulk-sender rules. Gmail (since February 1, 2024) and Yahoo require SPF or DKIM from every sender. At 5,000+ messages a day Gmail demands SPF plus DKIM plus a DMARC policy of at least p=none that passes with From-domain alignment, one-click unsubscribe, and a spam rate below 0.3%; Yahoo requires the same of bulk senders but states in its sender FAQ that it "will not specify a volume threshold". Microsoft matched Gmail's number on May 5, 2025 for domains sending 5,000+ daily messages to Outlook.com: non-compliant mail was junked first, with rejection to follow. Apple publishes bulk requirements for iCloud Mail without numeric thresholds: SPF and DKIM, a published DMARC policy, ARC headers on forwarded mail, and opt-in-only lists, otherwise "the email will be rejected" (each provider's own documentation, checked 2026-07-17).
Check your standing with All major providers
- Google Postmaster Tools
Google's dashboard for your domain's spam rate, authentication results, and reputation with Gmail. The 0.3% spam-rate ceiling is measured here.
- Microsoft Smart Network Data Services (SNDS)
Microsoft's view of your IP space for Outlook.com: filter verdicts, complaint rates, and trap hits per sending IP.
- Microsoft anti-spam IP delist portal
Self-service removal from Microsoft's block list: submit the blocked IP, verify your email address, request delisting.
- Yahoo Complaint Feedback Loop (CFL)
Sends you a copy of every message Yahoo users mark as spam. Yahoo asks for an active CFL on all DKIM domains.
- Yahoo sender support
Yahoo's contact form for delivery issues its sender documentation doesn't resolve.
- Apple iCloud Mail postmaster page
Apple offers no feedback loop and no delist portal; this page documents the bulk rules and the postmaster contact (icloudadmin@apple.com).
Bounce codes you may be seeing
Blocks in this cluster surface as specific SMTP codes. Match yours below; the linked guides cover each code's verbatim provider messages and full fix.
- 550 5.7.26 (sender is unauthenticated): Gmail's rejection for mail that fails SPF and DKIM Full guide →
- 550 5.7.1: the generic policy rejection; Microsoft's version carries markers like S3150 when your IP is on its block list Full guide →
- 550 5.7.509: Microsoft's rejection for a sending domain that fails DMARC verification Full guide →
- 421 4.7.0 and Microsoft's 421 RP codes: temporary deferrals from reputation rate limits on new or spiking senders Full guide →
- 554 5.7.1: a content or policy refusal issued after the message body was seen Full guide →
The real root cause: unenforced authentication
Strip away the provider differences and the same root cause sits under almost every block: mail that can't prove it came from your domain. Unauthenticated mail scores badly, bad scores draw junk placements and complaints, and complaints push you onto the lists that turn filtering into refusal. The way out is to make authentication a settled fact: correct SPF and DKIM for every sending service, DMARC alignment on the From domain, and a policy enforced at p=reject so spoofers can't burn your reputation while you rebuild it. Monitoring shows you which senders fail; enforcement is what makes the blocking stop and stay stopped, at every provider at once.
Enforce it — don't just monitor it
Palisade's AI agent takes domains all the way to enforcement: hosted SPF, DKIM, DMARC, and MTA-STS records, DMARC reports monitored continuously, and policies advanced to p=reject automatically. Your first domain is free, and the full product is open for 15 days, no card.
Free 15-day trial · No credit card · Your own domain free forever (NFR)
Fixing this across every client domain
One blocked domain is a support ticket; a fleet of client domains hitting the Gmail, Yahoo, and Microsoft enforcement waves is a quarter of them, because every provider scores every domain separately and each one needs its own SPF, DKIM, DMARC, and postmaster enrollments. Palisade runs this per fleet: it hosts and manages the SPF, DKIM, DMARC, and MTA-STS records for every client domain, flags failing senders from DMARC reports before a provider starts refusing them, and walks each domain to p=reject automatically. Tickets land in ConnectWise, HaloPSA, or Autotask through native PSA integrations, pricing is per domain ($9, dropping to $7 at 100+ and $5 at 1,000+), and your own MSP domain is a free NFR domain to prove it on.
Frequently asked questions
Related guides
550 5.7.26550 5.7.1421 4.7.0p=rejectinclude:adkim / aspf