You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

AWS WorkMail邮箱无法接收邮件:550 5.1.1收件人不存在报错求助

Troubleshooting "550 5.1.1 The email account that you tried to reach does not exist" with AWS WorkMail & Route53

Hey there, since you're new to AWS and hitting this email receiving snag, let's break down the most likely causes and fixes step by step—this error almost always ties to DNS routing or service configuration mismatches between WorkMail, SES, and Route53.

1. Verify Your Route53 MX Records Are Pointing to WorkMail (Not SES)

The #1 culprit here is incorrect MX records. WorkMail requires its own dedicated MX servers, and if you accidentally set up SES's MX records instead, the receiving server won't recognize your WorkMail mailbox.

  • Go to the AWS WorkMail console, navigate to your organization, and check the Domain settings tab. You'll see the official MX records provided by AWS (they look something like 10 inbound-smtp.<your-region>.amazonaws.com for WorkMail, distinct from SES's MX endpoints).
  • Head over to Route53, open your hosted zone for domain.es, and confirm the MX records match exactly what WorkMail provides. Make sure there are no conflicting MX records (like leftover SES MX entries) that might override WorkMail's routing.
  • Test this with a DNS lookup: run dig domain.es MX in your terminal—you should only see WorkMail's MX servers in the results.

2. Confirm Your Domain Is Fully Verified in WorkMail

Even if you created the mailbox in WorkMail, if your domain.es isn't properly verified, WorkMail won't accept incoming emails for it.

  • In the WorkMail console's Domain settings, check that the domain status shows Verified. If it's pending, complete the verification process (usually by adding a TXT record to Route53 as instructed).
  • Double-check that the mailbox example@domain.es is in an Enabled state in WorkMail's Users tab—no accidental deactivations or typos in the email address.

3. Check for SES Receiving Rule Conflicts

If you set up SES to handle incoming emails, it might be intercepting messages before they reach WorkMail.

  • Go to the SES console, navigate to Email Receiving > Rules. If you have any rules set up for domain.es, ask yourself: do these rules forward emails to WorkMail, or are they storing them in S3 instead?
  • If you want WorkMail to handle all incoming emails, you should either delete SES receiving rules for domain.es or configure them to forward messages to your WorkMail mailbox's SMTP endpoint.

4. Validate Your SPF Record

A missing or incorrect SPF record can sometimes cause deliverability issues (though less likely to trigger a "does not exist" error)—but it's still worth checking.

  • In Route53, look for a TXT record for domain.es starting with v=spf1. It should include both WorkMail and SES if you're using both services:
    v=spf1 include:amazonses.com include:<your-workmail-org-domain>.awsapps.com ~all
    
    Replace <your-workmail-org-domain> with the domain provided in your WorkMail organization settings (e.g., d-1234567890.awsapps.com).
  • Test this with dig domain.es TXT to ensure the SPF record is correctly published.

5. Rule Out Nginx Configuration Issues (Unlikely, But Quick Check)

Your Nginx config is for web traffic, so it shouldn't affect email routing—but just to be thorough:

  • Ensure you haven't accidentally added any mail-related directives (like smtp_proxy) to your Nginx config that might interfere. Your current config looks standard for WordPress, so this is probably not the issue, but it's good to confirm.

Final Testing

After making any changes, wait 10-15 minutes for DNS records to propagate, then send another test email from Gmail to example@domain.es. If the issue persists, check the WorkMail console's Mail flow logs (if enabled) to see if the email is being rejected or routed elsewhere.


内容的提问来源于stack exchange,提问作者Robert Blasco Villarroya

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.14 06:51:42