Why Your Emails End Up in Spam: The Complete Diagnostic Guide
By CaptainDNS
Published on February 4, 2026
Updated on November 10, 2026
- 5 main causes: authentication (SPF/DKIM/DMARC), IP/domain reputation, suspicious content, poor engagement, technical configuration
- Priority check: test your IP against major blocklists and audit your authentication
- Since 2024: Gmail and Yahoo require SPF, DKIM, and DMARC for bulk senders
- Outlook.com rejections of November 2026 (AS9031519): without an applicable DMARC record, adding
p=noneis the reported workaround. Rejections are also reported with SPF, DKIM, and DMARC passing: if your authentication is already correct, don't rewrite your records, and follow the reporting procedure in the Outlook.com section - Starting November 2026: Spamhaus is gradually rolling out a requirement for a valid HELO and matching PTR and A records on every sending IP, and non-compliant IPs risk being listed
- Critical threshold: a complaint rate above 0.1% triggers spam classification
- Quick diagnostic: analyze your email headers to identify the exact problem
Why Your Emails Are Being Classified as Spam
Every day, billions of emails are filtered by anti-spam systems. One in six emails never reaches the recipient's inbox. For businesses, this is a critical issue: invoices not received, order confirmations lost, customer communications ignored.
Spam classification isn't random. Email providers (Gmail, Outlook, Yahoo) use hundreds of signals to decide the fate of each email. Understanding these signals is key to solving the problem: they come down to five measurable pillars (authentication, reputation, transport security, BIMI, engagement) that our guide to the email deliverability score breaks down one by one.
This guide analyzes the 5 main causes of spam classification and gives you a concrete action plan for each situation. Whether you're a system administrator, marketing manager, or developer, you'll find the answers you need.
Cause 1: Missing or Incorrect Email Authentication
Email authentication became mandatory in 2024. Gmail, Yahoo, and Apple announced that unauthenticated emails would be systematically rejected or classified as spam.
The 3 Authentication Protocols
| Protocol | Function | Impact if Missing |
|---|---|---|
| SPF | Lists servers authorized to send for your domain | Rejection or spam |
| DKIM | Cryptographically signs each email | Spam or distrust |
| DMARC | Defines the policy when SPF/DKIM fails | No protection against spoofing; Outlook.com rejections reported since November 2026 (not the only situation reported) |
Check Your Configuration
Use a domain email audit to instantly verify if your domain is properly configured:
- Enter your domain name
- Review the SPF, DKIM, and DMARC results
- Follow the correction recommendations
Common SPF Errors
| Error | Consequence | Solution |
|---|---|---|
| No SPF record | Emails classified as spam | Create a TXT record with v=spf1 |
| Too many includes (>10 lookups) | Invalid SPF (PermError) | Optimize or use a flattening service |
| Missing IP | SPF failure for some sends | Add the IP or the service's include |
| ~all vs -all | Policy too permissive | Use -all in production |
Common DKIM Errors
| Error | Consequence | Solution |
|---|---|---|
| No signature | Email not authenticated | Configure DKIM on the mail server |
| Key too short (<1024 bits) | Signature considered weak | Generate a 2048-bit key |
| Incorrect selector | Verification failure | Check DNS and server configuration |
| Modified body | Invalid signature | Check intermediate relays |
DMARC: The Game-Changing Policy
DMARC is the conductor of authentication. Without it, even with valid SPF and DKIM, your emails can be classified as spam, or refused during the SMTP transaction. A refusal puts nothing in the junk folder: the sender gets a non-delivery report and the message is not delivered. Since early November 2026, operators have reported this kind of refusal at Outlook.com for domains with no DMARC record. The November reports also involve domains whose SPF, DKIM, and DMARC are reported as correct: a missing DMARC record doesn't explain every case (details in the Outlook.com section below).
# DMARC record with p=none and aggregate reports
_dmarc.captaindns.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com"
# Strict DMARC record (recommended for production)
_dmarc.captaindns.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@captaindns.com"
| Policy | Behavior | Recommendation |
|---|---|---|
p=none | Monitoring only | Initial phase (2-4 weeks) |
p=quarantine | Suspicious emails to spam | Intermediate phase |
p=reject | Suspicious emails rejected | Secure production |
Cause 2: Degraded IP or Domain Reputation
Even with perfect authentication, your emails can land in spam if your reputation is poor. Email providers maintain reputation scores based on sending history.
Understanding Reputation
Reputation consists of two elements:
- IP reputation: Score of the IP address sending the emails
- Domain reputation: Score of the sending domain (From)
| Factor | Impact on Reputation |
|---|---|
| Spam complaint rate | Very high (threshold: 0.1%) |
| Bounce rate | High (threshold: 5%) |
| Engagement (opens, clicks) | Moderate |
| Domain history | Moderate |
| Blocklists | Critical |
Check If Your IP Is Blocklisted
An IP on a major blocklist (Spamhaus, Barracuda) will see its emails systematically rejected by Gmail, Outlook, and Yahoo.
To check if your IP is listed, test it against the main DNSBLs:
- Spamhaus ZEN: Used by the majority of major providers
- Barracuda BRBL: Very common in enterprise environments
- SpamCop: Based on user reports
Priority Blocklists to Monitor
| Blocklist | Impact | Used By |
|---|---|---|
| Spamhaus ZEN | Critical | Gmail, Yahoo, Outlook |
| Barracuda BRBL | Critical | Enterprises, Barracuda filters |
| SpamCop | High | Many providers |
| UCEProtect | Moderate | Anti-spam filters |
Improving Your Reputation
| Action | Impact | Timeline |
|---|---|---|
| Request delisting from blocklists | Immediate | 24-72h |
| Reduce complaint rate | High | 2-4 weeks |
| Remove hard bounces caused by the address itself (unknown user, mailbox does not exist). When the rejection is about your domain, IP, or authentication, fix it at the source without removing the recipient | High | Immediate |
| Gradually warm up new IPs | Preventive | 4-6 weeks |
Cause 3: Problematic Content
Anti-spam filters analyze the content of each email. Certain elements automatically trigger spam classification.
Words and Phrases to Avoid
Anti-spam filters use lists of suspicious words. Here are the riskiest categories:
| Category | Examples | Risk |
|---|---|---|
| Excessive urgency | "URGENT", "Act now", "Last chance" | High |
| Financial promises | "Free", "Make money", "No cost" | High |
| Sales pressure | "Limited offer", "Only 24h left", "Out of stock" | Moderate |
| Suspicious phrases | "Click here", "100% guaranteed", "No obligation" | Moderate |
Email Structure
| Problem | Why It's Filtered | Solution |
|---|---|---|
| 100% image email | Hidden text, spammer technique | 60% text / 40% images ratio |
| Shortened links (bit.ly) | Mask destination | Use full URLs |
| Too many links | Typical spam behavior | Maximum 3-5 links per email |
| No text version | HTML only = suspicious | Always include text/plain |
| Embedded forms | Phishing technique | Link to website |
Optimal HTML/Text Ratio
Recommended content:
- Text: 60-80%
- Images: 20-40%
- Links: 3-5 maximum
- Total size: < 100 KB
Cause 4: Poor Recipient Engagement
Email providers measure how recipients interact with your emails. Low engagement signals unwanted content.
Negative Engagement Signals
| Signal | Impact | Critical Threshold |
|---|---|---|
| Spam complaints | Very high | >0.1% triggers spam |
| Hard bounces | High | >5% degrades reputation |
| Repeated soft bounces | Moderate | >10% over 30 days |
| Low open rate | Moderate | <10% on active lists |
| High unsubscribes | Moderate | >1% per campaign |
The Spam Vicious Cycle
Low engagement → Spam classification → Even less engagement → Degraded reputation
To break this cycle:
- Clean your lists: Remove addresses inactive for more than 6 months
- Segment: Send relevant content to each segment
- Respect consent: Double opt-in required
- Make unsubscribing easy: Visible link, 1-click process
List Hygiene Best Practices
| Action | Frequency | Impact |
|---|---|---|
| Remove hard bounces caused by the address itself (unknown user, mailbox does not exist). When the rejection is about your domain, IP, or authentication, fix the cause and resend without touching the list | Immediate | Critical |
| Remove spam complaints | Immediate | Critical |
| Clean inactive (>6 months) | Monthly | High |
| Re-engage lukewarm contacts | Quarterly | Moderate |
| Validate emails at signup | Ongoing | Preventive |
Cause 5: Poor Technical Configuration
Technical configuration issues can sabotage all your efforts.
Server Configuration Checklist
| Element | Verification | Command |
|---|---|---|
| Reverse DNS (PTR) | IP must resolve to an FQDN | dig -x <IP> |
| FQDN to IP | FQDN must resolve to the IP | dig A <fqdn> |
| HELO/EHLO | Must resolve to the sending IP and stay the same | Server logs |
| Port 25 open | No ISP blocking | telnet mail.server.com 25 |
| TLS enabled | STARTTLS required | Connection test |
Reverse DNS: Why It's Critical
Reverse DNS (PTR record) is checked by all major providers. Without a valid PTR, your emails are immediately suspicious.
# Check your IP's PTR
dig -x 192.0.2.1
# Expected result
1.2.0.192.in-addr.arpa. 3600 IN PTR mail.captaindns.com.
# The FQDN must resolve to the same IP
dig A mail.captaindns.com
# Result: 192.0.2.1
HELO/EHLO Configuration
The mail server identifies itself with HELO or EHLO. The name it announces must:
- Be a valid FQDN (not an IP, not "localhost", not a hosting provider's default name)
- Resolve to the IP sending the email (A record)
- Stay the same from one connection to the next from that IP
The PTR of that IP, for its part, points to an FQDN that resolves back to the same IP: this is FCrDNS (forward-confirmed reverse DNS).
# Bad
EHLO localhost
EHLO [192.0.2.1]
EHLO server1
# Good
EHLO mail.captaindns.com
Spamhaus, November 2026. Starting November 2026, Spamhaus is gradually rolling out a requirement for every sending IP: a valid HELO, a reverse DNS (PTR) record, and a matching A record. An IP that doesn't meet it risks being listed. Spamhaus gives no specific day and no timeline. For IPv6, the sending address must belong to a /64 block or larger with valid reverse DNS. Check the PTR and A record of each sending IP now with the dig commands above, then the name announced in HELO in your server logs. For a hands-on check, send a message to an external mailbox and read the Received header added by the receiving server: the name after from is usually the one your server announces in HELO/EHLO. Depending on the receiving server, it may instead appear in parentheses, after helo= or HELO. The email header analyzer covered below shows it. If your sending servers are also your MX, the SMTP/MX tester flags a banner whose name doesn't match the MX name.
Diagnosis by Provider
Each provider has its own specifics. Here's how to diagnose problems for the main ones.
Gmail
Diagnostic tools:
- Google Postmaster Tools: domain and IP reputation
- Gmail headers: look for
X-Gm-SpamandX-Gm-Phishy
Gmail 2024 Requirements:
| Criterion | Volume <5,000/day | Volume >5,000/day |
|---|---|---|
| SPF or DKIM | Required | Required |
| DMARC | Recommended | Required |
| Complaint rate | <0.3% | <0.1% |
| TLS | Recommended | Required |
| 1-click unsubscribe | - | Required |
Common error codes:
| Code | Meaning | Action |
|---|---|---|
421 4.7.0 | Too many connections | Reduce rate |
550 5.7.1 | DMARC policy | Fix SPF/DKIM |
550 5.7.26 | Authentication failure | Check SPF, DKIM |
Outlook.com and Microsoft 365: Telling the Diagnoses Apart
Microsoft receives email through two separate services, which don't always react the same way. Outlook.com is the consumer mail service (outlook.com, hotmail.com, live.com, msn.com addresses). Microsoft 365 hosts business mail, under each customer's own domain. The name of the refusing server, in the non-delivery report (NDR), helps tell which one is answering: MailRoute describes the Outlook.com servers as olc.protection.outlook.com, and the Microsoft 365 domain tested by Spam Resource went through a mail.protection.outlook.com server.
Diagnostic tools:
- SNDS (Smart Network Data Services): IP reputation
- JMRP: feedback loop
Outlook specifics:
- Uses Spamhaus and proprietary blocklists
- Aggressive filtering of new domains (<30 days)
- SNDS program to monitor reputation
Outlook.com (Consumer)
The rule Microsoft has published targets high-volume senders. A domain that sends more than 5,000 messages a day to Outlook.com must pass SPF and DKIM, publish a DMARC record (at least p=none), and pass DMARC through an SPF or DKIM result aligned with the From domain. The announcement on the Outlook.com Postmaster site set the start date at May 5, 2025, first with junk-folder placement and then with rejections; the associated rejection is 550 5.7.515.
The reported rejection looks like this (MailRoute also reports a variant without the code in parentheses):
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
In the non-delivery report published on Microsoft Q&A on November 6, this refusal arrives inside another code. The "Error Details" line reads, with personal data removed by the moderator:
Error: 550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records
The report shows 550 5.7.23 as the status code, under the heading "SPF validation error". The help text that comes with it talks only about SPF: check the record, publish only one, include spf.protection.outlook.com in it. The detailed diagnostic comes after the arrow: it is the 550 5.7.1 "Message lacks SPF/DKIM/DMARC Auth Records", which Hornblower409 ties to AS9031519. This template doesn't prove your SPF is wrong. On the same thread, Martin reports this same pair of codes while stating that SPF, DKIM, and DMARC have been correct for years.
If you receive this rejection, first read and keep the full report: outer code, inner text, refusing server, and any AS9031519. Then look for the DMARC record at _dmarc.<domain>. For a subdomain, also check the parent domain's record, whose policy may apply. You can check the published DMARC record without a command line. A DNS lookup that doesn't complete (timeout, server error) doesn't prove the record is missing: try again before drawing a conclusion. This check shows what is published, not the SPF or DKIM result of a given message.
If no DMARC record applies to the domain:
- Publish a TXT record at
_dmarc.<domain>with the valuev=DMARC1; p=none. Many DNS hosts append the domain themselves: in that case, enter just_dmarcas the name. A domain has only one DMARC record, so don't create a second one with the same name, and don't replace a stricter policy that already works. - Check that at least SPF or DKIM passes and is aligned with the domain of the visible sender address (From). A DMARC record without aligned authentication still fails. To check alignment, send a message to another mailbox and read its
Authentication-Resultsheader (see how to read email headers). - Wait for DNS caches to expire: servers keep the old record in memory for a while, or the fact that none existed. For an old record, that delay is its TTL, set in your DNS zone. If no record existed, how long servers remember that absence depends on your zone's SOA record (negative caching, RFC 2308), not on the TTL of the new record. Then resend the refused messages. A 550 is a permanent failure, so your server won't retry the send.
Adding p=none is reported as a workaround for some domains without DMARC (Hornblower409 and Cameron Scott on the Microsoft Q&A thread), not as a fix for the Microsoft service. p=none asks for neither quarantine nor rejection under the DMARC policy. That doesn't guarantee acceptance by Outlook.com, or delivery to the inbox.
If SPF, DKIM, and DMARC are already correct and your messages pass authentication:
- Don't rewrite a correct configuration just to answer the text of the report. Don't publish a second SPF record: two SPF records cause a PermError (see the SPF PermError guide). Don't add
include:spf.protection.outlook.comjust because the report suggests it either: your SPF must authorize the services that actually send for your domain. - Keep the full report and the technical details, then report the rejection to Microsoft Sender Support. That is the step Hornblower409 recommends when messages refused with AS9031519 pass authentication.
- For businesses, Daniel-Vo asked on November 9 for recent Network Message IDs, logs of the affected messages, and samples in .eml format to be provided to Microsoft 365 support. These go to support, not to a public forum.
- Try again later, with no guarantee of success. The rejections are reported as intermittent, but a 550 is still a permanent failure: your server won't retry the send, so resending the message is up to you.
A pass on another message, or at another recipient, helps the diagnosis without proving the verdict of the Outlook.com server that refused yours. Because the rejections are partial, an accepted resend doesn't prove the configuration is correct either, MailRoute warns: check the records rather than the result of a single send.
Microsoft 365 (Business)
Microsoft 365 applies its own filtering mechanisms. It adds a proprietary compauth verdict in the Authentication-Results header; a compauth=fail raises the risk of landing in junk (see the Microsoft 365 compauth guide). In the test Al Iverson (Spam Resource) ran on November 7, 2026, the message refused by outlook.com was accepted by the Microsoft 365 domain tested. This single test doesn't show that recipients hosted on Microsoft 365 are safe, or that they are hit by the same incident. Microsoft 365 customers can, however, be affected as senders when they write to Outlook.com: Daniel-Vo's support request quoted above is addressed to them. Always read the full text of the NDR.
Outlook.com and Microsoft 365 Error Codes
| Code | Meaning | Action |
|---|---|---|
550 5.7.1 | Generic refusal: read the full text of the NDR | Request delisting only if the text points to an IP block, following the procedure it gives |
550 5.7.1 with "Message lacks SPF/DKIM/DMARC Auth Records" | Outlook.com rejection reported since November 2026 for domains without DMARC, but also for domains whose authentication passes | Check the DMARC record and SPF or DKIM alignment without concluding from the wording alone that they are broken. Without DMARC: publish p=none, then resend. If everything passes: report to Microsoft Sender Support |
550 5.7.23, when it comes with the AS9031519 diagnostic | SPF-oriented envelope around the 550 5.7.1 "Message lacks SPF/DKIM/DMARC Auth Records" refusal (reports published on Microsoft Q&A, November 2026). On its own, this code signals an SPF failure and doesn't prove this incident | Read the diagnostic after the arrow before touching SPF, then follow the matching situation (DMARC missing or authentication already correct) |
550 5.7.515 | Required authentication level not met (high-volume senders to Outlook.com) | Valid SPF and DKIM, published DMARC, alignment with the From |
550 5.7.606 | Low reputation IP | Check SNDS and follow the delisting procedure given in the NDR. The refusal targets the IP: don't remove the refused recipients |
421 4.7.0 | Rate limit | Reduce sends |
Yahoo / AOL
Diagnostic tools:
- Yahoo Sender Hub: reputation and guidelines
- Complaint Feedback Loop: real-time complaints
Yahoo 2024 Requirements:
| Criterion | Required |
|---|---|
| SPF | Required |
| DKIM | Required |
| DMARC | Required for >5,000 emails/day |
| 1-click unsubscribe | Required |
| Complaint rate | <0.3% |
Recommended Action Plan
Step 1: Immediate Diagnosis (30 minutes)
- Test your IP against major blocklists
- Check authentication (SPF, DKIM, DMARC) for your domain
- Analyze a problematic email via its headers with the email header analyzer
If your messages are refused rather than classified as spam, start from the exact text of the NDR before any delisting request. The same 550 5.7.1 code covers several causes. "Message lacks SPF/DKIM/DMARC Auth Records" doesn't target your IP: check DMARC and alignment, without concluding from the wording alone that they are broken. Rejections are also reported with authentication passing; in that case, follow the "authentication already correct" procedure in the Outlook.com section. Delisting only makes sense if the text names the IP or a blocklist.
Step 2: Priority Fixes (1-2 days)
- Request delisting if blocklisted (Spamhaus, Barracuda first)
- Fix authentication errors detected
- Configure reverse DNS if missing
Step 3: Continuous Improvement (2-4 weeks)
- Sign up for feedback loops (Gmail, Outlook, Yahoo)
- Monitor complaint rates (target <0.1%)
- Clean your lists: remove addresses inactive for more than 6 months and hard bounces whose refusal concerns the address (unknown user, mailbox does not exist). If the refusal targets your domain, your IP, or your authentication, fix the cause and resend, without removing the recipient
- Set up regular monitoring of blocklists
Step 4: Long-Term Prevention
- Double opt-in for all signups
- Easy unsubscribe (1-click, list-unsubscribe header)
- Automated monitoring of blocklists and reputation
- Quarterly audit of email configuration
FAQ
Why are my emails going to spam even though I've configured SPF and DKIM?
SPF and DKIM alone aren't enough. Since 2024, Gmail and Yahoo also require DMARC from bulk senders. At Outlook.com, rejections have been reported since early November 2026 for domains without DMARC, including at low volume, but also for domains whose authentication passes; on November 9, a Microsoft Q&A moderator tied them to a service degradation (see the next question). Also check that your IP isn't on a blocklist and that your complaint rate is below 0.1%. Failure on any of these points can trigger spam classification, even with partial authentication.
Why does Outlook.com reject my emails with AS9031519 despite valid SPF and DKIM?
Two situations have been reported since early November 2026. Operators (Mailop list, MailRoute, Spam Resource) see this rejection on domains with no DMARC record; participants in the Microsoft Q&A thread "SPF Validation Error" also report it, intermittently, with SPF, DKIM, and DMARC passing. On November 9, 2026, Daniel-Vo, identified on that thread as "Microsoft External Staff" and a moderator, described an Exchange service issue affecting mail to Outlook.com, Hotmail.com, and Live.com, classified as "service degradation", with the cause still under investigation. This is neither a Service Health entry nor a newly published rule. The non-delivery report may show 550 5.7.23 and the heading "SPF validation error": read the diagnostic after the arrow before touching SPF. If no DMARC record applies, publish a TXT record v=DMARC1; p=none at _dmarc.<domain>, check that SPF or DKIM passes and stays aligned with the From domain, then resend the refused messages: a 550 is final, and your server won't retry it. p=none is a reported workaround, with no guarantee of acceptance. If authentication already passes, don't rewrite your records: keep the full report and report the rejection to Microsoft Sender Support.
How do I know if my IP is on a blocklist?
Use a blocklist checker that tests your IP against the main lists (Spamhaus, Barracuda, SpamCop). The test covers 25+ blocklists simultaneously and provides delisting links for each affected list. Test your IP immediately if your emails are being rejected or classified as spam.
How long does it take to get off a blocklist?
Timelines vary by blocklist: SpamCop automatically delists in 24-48h without new reports. Spamhaus processes manual requests in 24-48h. Barracuda responds in 12-24h. UCEProtect has a 7-day delay. In all cases, the issue that caused the listing must be fixed before requesting delisting.
My emails only go to spam at Gmail, why?
Gmail has been particularly strict since February 2024. Check the following: (1) Is DMARC configured with at least p=none? (2) Is the complaint rate below 0.1%? (3) Is 1-click unsubscribe implemented for bulk emails? Use Google Postmaster Tools to see your domain reputation at Gmail.
How can I improve my deliverability quickly?
Immediate actions: (1) Check and fix your SPF/DKIM/DMARC authentication. (2) Test your IP against blocklists and request delisting if needed. (3) Remove from your list the hard bounces whose refusal concerns the address (unknown user, mailbox does not exist), along with contacts inactive for more than 6 months. If the refusal targets your domain, your IP, or your authentication, fix the cause and resend before touching the list. (4) Reduce sends to addresses that never open. These actions can improve deliverability in 1-2 weeks.
What is an acceptable complaint rate?
The critical threshold is 0.1% (1 complaint per 1,000 emails). Beyond this, Gmail and Yahoo start classifying your emails as spam. Google recommends staying below 0.05% for optimal deliverability. Monitor this rate via feedback loops and Google Postmaster Tools.
My mail server is properly configured but my emails still go to spam?
If technical configuration is correct, the problem is likely related to: (1) Reputation of your IP or domain (check blocklists). (2) Content of your emails (trigger words, image/text ratio). (3) Engagement of recipients (low open rate, complaints). Analyze your headers to identify the triggering factor.
How do I warm up a new IP for email sending?
IP warming involves gradually increasing send volume over 4-6 weeks. Start with 50-100 emails/day to your most engaged recipients, then double the volume each week. Monitor bounces and complaints. Never go from 0 to thousands of emails/day or you'll trigger anti-spam filters.
What does the Spamhaus HELO/PTR requirement of November 2026 change?
Starting November 2026, Spamhaus is gradually rolling out a requirement for every sending IP: a reverse DNS (PTR) record pointing to an FQDN, that FQDN resolving to the same IP (A record), and a HELO/EHLO name that resolves to the sending IP and stays the same from one connection to the next. According to Spamhaus, missing or mismatched reverse DNS is one of the most common reasons for considering listing an IP. Spamhaus has published no specific day and no timeline: this is a gradual rollout, not a cutoff on a fixed date. For IPv6, the sending address must sit in a /64 block or larger, with valid reverse DNS.
Glossary
- DNSBL (DNS-based Blackhole List): IP blocklist queryable via DNS. Also called RBL (Realtime Blackhole List).
- SPF (Sender Policy Framework): DNS record listing servers authorized to send emails for a domain.
- DKIM (DomainKeys Identified Mail): Cryptographic signature added to emails to prove their authenticity.
- DMARC (Domain-based Message Authentication, Reporting & Conformance): Policy defining how to handle emails failing SPF/DKIM.
- Hard bounce: Permanent delivery failure (5xx code). The address may not exist, but the rejection can also be about your domain or your authentication. The sending server doesn't retry: once the issue is fixed, resend the message. Before removing an address from your lists, check that the refusal really concerns it.
- Soft bounce: Email temporarily rejected (full mailbox, unavailable server).
- Feedback loop: Program allowing senders to receive spam reports from recipients.
- Reverse DNS (PTR): DNS record associating an IP address with a domain name.
- FQDN (Fully Qualified Domain Name): Complete domain name (e.g., mail.captaindns.com).
- IP reputation: Score assigned to an IP address based on its sending history.
Related Blocklist Guides
- How to Remove Your IP from a Blocklist: The Complete Delisting Guide: Detailed procedures for Spamhaus, Barracuda, SpamCop, and more
- Spamhaus vs Barracuda vs SpamCop: Comparison: The 3 major blacklists explained
Sources
- Google Email Sender Guidelines (2024) (official Gmail requirements)
- Yahoo Sender Best Practices (Yahoo/AOL guidelines)
- Microsoft 365 Anti-Spam Protection (Outlook documentation)
- Microsoft Support - Fix NDR error 550 5.7.515 in Outlook.com (official rule for high-volume senders to Outlook.com)
- Outlook.com Postmaster (announcement of the requirements for high-volume senders, start date May 5, 2025, consulted on November 8, 2026)
- Spam Resource - Microsoft newly rejecting mail lacking DMARC? (November 7, 2026) (observations and tests by Al Iverson)
- Mailop - Microsoft requiring DMARC now or just us? (operator reports, November 2026)
- MailRoute - 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records (November 6, 2026) (operational feedback from a relay provider)
- Microsoft Q&A - SPF Validation Error (thread opened November 6, 2026) (support exchange, not normative documentation: November 9, 2026 statement by Daniel-Vo, Microsoft External Staff and moderator, reply from volunteer moderator Hornblower409, and user reports; consulted on November 10, 2026)
- The Register - Outlook.com bounces legit emails as Microsoft's authentication crackdown goes sideways (November 9, 2026) (news article)
- RFC 7489 - DMARC (technical specification)
- Spamhaus - Understanding DNSBLs (how blocklists work)
- Spamhaus Sender Guidelines (HELO, PTR, and A requirements for sending IPs)
