SMTP response received
550 5.7.7 Anti-spoofing policy: this message is from an unauthorized sender for the domainYou received this code because the receiving Microsoft 365 tenant refused delivery because your message violated their anti-spoofing policy. This is a policy rejection specific to Exchange Online Protection (EOP) โ it means your DMARC, SPF, or DKIM alignment does not satisfy what the receiver tenant expects from a sender claiming to be your domain. The fix is on your side: proper authentication configuration and alignment, not action at the recipient tenant.
๐ In this guide
๐ค Who sees this code
- Sender whose messages recently started bouncing at Microsoft 365 tenants
- Team facing new Microsoft anti-spoofing enforcement (2024+)
- Deliverability lead debugging DMARC alignment for B2B sending
๐ง What this guide fixes
- Identify which authentication mechanism specifically failed alignment
- Fix SPF, DKIM, or DMARC alignment at the source
- Verify the fix passes Microsoft EOP anti-spoofing checks
โก Do these 3 things first (before diving deeper)
Check the Authentication-Results header for the specific mechanism that failed
The Authentication-Results header at Microsoft contains the definitive verdict on your SPF, DKIM, and DMARC verification and alignment. Grab a copy of a recently delivered message from any Microsoft tenant (or checked via a delivery-testing tool) and inspect the header. It shows exactly which mechanism failed: SPF fail, DKIM fail, DMARC fail. If Microsoft rejected with anti-spoofing wording but Authentication-Results shows all pass, the issue is EOP tenant-level policy rather than fundamental auth failure.
Verify your DMARC record exists and is enforcing
Anti-spoofing rejections at Microsoft 365 correlate strongly with weak or missing DMARC. Query your DMARC record with dig TXT _dmarc.yourdomain.com. If no DMARC record exists, publish one at p=none as an immediate step. If DMARC exists but p=none, Microsoft treats you as an unauthenticated sender for tenant anti-spoofing evaluation. Moving to p=quarantine or p=reject after proper monitoring is what activates the anti-spoofing protection for your domain.
Confirm alignment, not just verification, at Microsoft
DMARC alignment is where most anti-spoofing rejections originate. Even if SPF passes (your IP is authorized in the SPF record) and DKIM verifies (the signature is valid), the mechanism must ALIGN with your From header domain. SPF alignment checks the Envelope-From domain against the header From domain. DKIM alignment checks the d= tag against the header From domain. Passing without alignment produces DMARC fail, which triggers anti-spoofing at Microsoft tenants with strict EOP policy.
Common causes of 550
- Missing or misconfigured DMARC record on sender domain. The most common cause. Microsoft anti-spoofing policy checks whether your From domain has a valid DMARC record and whether the message satisfies it. Missing DMARC means Microsoft treats you as an unauthenticated sender, and tenant-level anti-spoofing policies increasingly reject unauthenticated inbound. Even p=none is better than no DMARC because it signals to Microsoft that you have deployed DMARC monitoring. See the fix section for the specific record structure to publish.
- DMARC pass but alignment failure between Envelope-From and From. Your infrastructure might send with a bounce address (Envelope-From) at a different domain than your visible From address. For example, ESPs commonly use bounces@mail.sendgrid.net as Envelope-From while your visible From is you@yourdomain.com. SPF passes (SendGrid IP is authorized in their SPF), but SPF alignment fails because Envelope-From is not your domain. DMARC treats this as fail even though SPF verification succeeded. Configure your ESP for aligned SPF via a custom return path.
- SPF pass but from a non-authorized IP for the header From domain. Your outbound IP might be authorized in one domain SPF but not in your header From domain SPF. This happens when subsidiaries send through shared infrastructure without proper SPF authorization on each domain. The message technically has SPF pass for the Envelope-From domain, but the header From domain does not authorize the sending IP. Alignment fails. Update your SPF records so each domain that appears in From authorizes the sending IPs.
- DKIM signature valid but d= tag does not align with From domain. DKIM signatures include a d= tag identifying the signing domain. For DMARC alignment, this d= domain must organizationally match the header From domain (strict alignment requires exact match; relaxed alignment allows subdomain matching). ESPs often sign with their own domain (d=sendgrid.net) rather than your domain, breaking alignment. Configure your ESP for domain-aligned DKIM signing with a CNAME setup that places the signing selector under your domain.
- Recipient tenant has enabled strict EOP anti-spoofing enforcement. Microsoft 365 tenant administrators can enable enhanced anti-spoofing policies through EOP. When enabled, tenants reject messages that fail DMARC even when the sender might pass at other Microsoft tenants with laxer policies. This is why some tenants accept your mail while others reject with anti-spoofing wording despite identical authentication configuration. The fix is fundamental authentication improvement on your side, not asking the recipient tenant to relax their policy.
How to fix 550, step by step
- Publish or strengthen your DMARC record. If no DMARC exists, publish this minimum:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. This enables monitoring without enforcement. Review DMARC aggregate reports weekly for 30 to 60 days to identify all legitimate sending sources. Then move to p=quarantine, then p=reject once all sources are aligned. Skipping the monitoring phase and going straight to p=reject produces your own delivery outages. - Fix SPF alignment via custom return path at your ESP. Contact your ESP (SendGrid, Mailgun, Amazon SES, etc.) to configure a custom Return-Path that aligns with your domain. Instead of bounces@mail.sendgrid.net, use bounces@bounces.yourdomain.com with a CNAME setup that points to the ESP infrastructure. This makes Envelope-From align with header From, satisfying DMARC SPF alignment. Every reputable ESP supports this and provides step-by-step setup documentation.
- Configure domain-aligned DKIM signing. Configure your ESP or sending infrastructure to sign with a DKIM selector under your domain rather than the ESP's domain. This typically involves publishing CNAME records at selector._domainkey.yourdomain.com pointing to selector._domainkey.esp-domain.com. The signature validates as normal but d= reflects your domain, satisfying DMARC DKIM alignment. Most ESPs walk you through this during onboarding as a required step for deliverability.
- Test with check-auth and verify pass across all mechanisms. Send a test message from your production sending path to
check-auth@verifier.port25.com. The response report shows SPF pass or fail with alignment status, DKIM pass or fail with alignment status, and DMARC final verdict. All three should show pass with proper alignment before you resume production sending to Microsoft tenants. If any fails, the corresponding mechanism is not fixed. - For persistent tenant-specific issues, contact the recipient admin. When your authentication is fully aligned and Microsoft anti-spoofing rejections continue at specific tenants only, the receiving tenant has enabled strict enhanced filtering that even legitimate senders sometimes trigger. Provide the recipient admin with evidence: your DMARC record, Authentication-Results header from a successful send elsewhere, and the specific Message-ID that bounced. They can add your domain to their allowlist or relax the enhanced filtering rule.
๐ How each provider sends this exact code
โ How this code differs from adjacent ones
550 5.7.26550 5.7.1550 5.4.1Prevention going forward
Anti-spoofing rejections at Microsoft 365 signal that your DMARC posture does not meet modern receiver expectations. Preventing them means treating DMARC alignment as a baseline requirement, not an advanced feature.
- Publish DMARC with rua reporting and monitor aggregate reports weekly. Reports arrive as XML from every major receiver and show which of your sending sources are silently failing alignment.
- Configure custom return-path at every ESP you use to align SPF with your domain. This is a one-time setup per ESP but eliminates the largest single class of alignment failures.
- Set up domain-aligned DKIM signing at every ESP. Selectors under your domain (via CNAME to ESP infrastructure) satisfy DKIM alignment without any performance cost.
- Monitor the Authentication-Results header in delivered messages across major receivers. All three of SPF, DKIM, and DMARC should show pass with alignment. Any fail is a future anti-spoofing rejection waiting to happen.
- Progress DMARC policy from p=none to p=quarantine to p=reject over 90 to 180 days as monitoring confirms all sources align. Rushing to p=reject before monitoring completes creates your own delivery incidents.
Frequently asked questions about 550
What is Microsoft anti-spoofing policy exactly?
What is the difference between DMARC pass and DMARC alignment?
Why does the same message deliver at one Microsoft tenant but fail at another?
How is anti-spoofing (5.7.7) different from 550 5.7.26 multiple auth failure?
Should I move to DMARC p=reject to avoid anti-spoofing rejections?
How long does DMARC configuration take to reflect in delivery success?
Stop 550 bounces before they happen.
SMTPing catches invalid addresses, disposables, catch-all traps, role accounts and dead mailboxes before you send. Fewer bounces means less firefighting and a healthier sender reputation. 13 validation types, 25 free daily, no card required.
๐ Deep dive on related codes
550 5.4.1Office 365 tenant policyRecipient address rejected at Microsoft โ auth or reputation cause
550 5.7.1Relaying deniedSender-side SMTP AUTH failure โ fix your outbound config
550 5.7.606Microsoft IP banPermanent Microsoft ban with mitigation form
550 5.7.25PTR reverse DNS missingFCrDNS setup coordination with hosting provider
About the Author
Alaa ยท LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. Iโve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
