目录
- 一、背景
- 二、自有域名和解析要求
- 三、创建Workmail邮箱
- 四、创建用户并使用企业邮箱发送和接收
- 五、参考文档
一、背景
在跨境电商等许多业务场景中,需要使用海外邮箱服务器用于海外分支机构员工、海外客服等相关业务联系。此时使用国内邮箱服务器,可能存在发信延迟、收信延迟、正常邮件被投递到异常垃圾邮件箱等情况。因此,在海外搭建一套企业自己的邮件服务是这个场景的最佳选择。
企业邮件服务通常可选的方案包括:一是购买商用版本的企业邮件服务器软件并在云上私有化部署,二是使用开源邮件服务器私有化部署,三是购买第三方SaaS方式的企业邮箱。在亚马逊云科技的云端服务中,针对此场景提供的云服务是Amazon Workmail。
Amazon Workmail的底层是基于Amazon Simple Email Service服务(SES)构建,但是在上层为用户提供了完整的、友好的WEB UI,包括了日历、联系人、便签功能,还为PC端和移动设备提供了IMAP、POP3、ActiveSync等协议的支持,可进行移动端设备同步。用户在整个使用过程中,对Workmail底层架构无感。除去标准邮件功能外,Workmail还提供了面向企业邮箱管理的功能,包括邮箱保留周期规则、审计合规(Journaling)、邮件转发规则、关联Lambda等功能。目前,Amazon Workmail在us-east-1,us-west-2和eu-west-1三个区域可用。
需要注意的是,本场景使用Workmail是企业自用邮件服务器,发送和接受在同等重要的地位,甚至接受外部邮件的重要性大于发送。如果您是需要向外发送海量的注册通知、确认信、广告、营销等类型的邮件,那么您应选择直接使用Amazon Simple Email Service服务(SES),而不是通过Workmail发起。虽然Workmail底层也是通过SES实现发送和接收,但是Workmail是面向企业自用场景,不提供批量发送营销邮件的专用功能。这些功能包括用于发送邮件的独立IP、邮件信誉管理、日志、模版等,他们仅在SES服务中提供。
本文介绍如何在数分钟内配置好一个Workmail企业邮箱并投入使用。
二、自有域名和解析要求
1、准备自有域名
为使用企业邮箱,您需要注册并拥有自己的域名。在配置邮箱过程中,会要求为您的域名添加一系列DNS解析记录,包括CNAME记录,MX记录,TXT记录等多种记录,分别用于域名所有人验证、反垃圾签名等用途。
域名的注册和解析是两个独立的行为。您可以在任意域名注册商完成域名注册,然后在任何提供标准DNS服务的云上进行域名解析。此配置过程,请参考Amazon Route 53相关文档。本文的例子中,域名已经在其他域名注册商注册好,其域名解析功能由Amazon Route 53服务提供。
2、Workmail需要的相关域名记录
配置Workmail的过程中需要添加如下解析:
- 用于验证域名所有人的TXT记录
- 用于接收邮件的MX记录/用于接收邮件配置的CNAME记录
- 用于外发邮件的DKIM认证等CNAME记录和TXT记录
- 用于表示自己身份的DMARC协议的TXT记录
此外,当在Workmail界面上配置时候,域名本身也会成为SES验证的域名,因此后续SES可以直接使用。
3、Workmail与SES共存时候的域名配置说明
Workmail服务底层是基于SES构建的,可以和SES服务使用同一个域名。二者分工如下:
SES发送邮件:
- SES负责外发验证码、广告和营销类,配置过程中主要验证方式是CNAME验证;
Workmail发送和接收邮件:
- Workmail负责企业邮箱场景接收外部来信,配置过程分别要配置CNAME和MX记录;
- 对外发送时候,通过Workmail的Web UI、移动端设备等方式发出的邮件,都会被Workmail交给底层的SES发出,这个过程是透明的,用户无感知;
- 接收邮件时候,外部发来的邮件会通过MX记录查询落地到SES底层,然后Workmail会识别出来,通过Web UI或者移动端同步的方式展现给用户,这个过程是透明的,用户无感知;
以上过程可以看出,一个域名可以同时绑定到Workmail和SES。不过,由于CNAME不唯一性,每个Region使用SES配置的CNAME都不一样,因此同一个域名可用于多个AWS Region上使用SES服务。但是由于接收邮件使用的MX记录的唯一性,同一个域名只能添加一个MX记录,配置Workmail接收邮件只能在唯一的AWS区域。
三、创建Workmail服务
1、创建组织
进入Workmail服务,以us-west-2区域为例。点击创建组织。如下截图。
在组织类型中,选择External domain
,表示解析是独立管理的,可以是AWS Route53,也可以是在其他的管理平台进行解析。然后在域名位置输入要提供邮件服务的域名。如下截图。
在域名位置填写上邮箱要绑定的域名。然后继续向下滚动屏幕。如下截图。
点击Advanced settings
高级设置,下边的两个默认选项保留默认即可,可用不用调整。第一个选项Create Amazon WorkMail Directory
表示使用Workmail自动创建的目录服务,如果您要使用自己管理的微软Active Directory服务请选择第二个选项Use existing directory
即可对接自己的与控制器。在加密位置,选择默认的Use Amazon WorkMail managed key
即可。如下截图。
创建完毕,屏幕上显示组织创建中。等待3-5分钟后,显示Active
即表示创建完成。此时页面会提示,尚未经过域名验证,这时候需要点击左侧的Domains
菜单进行域名验证。如下截图。
进入Domains
菜单后,可以看到屏幕上有两条记录,其中一条是上一步输入的域名本身,显示Pending Verification
,未经验证。另外还有一条xxxxx.awsapps.com
,这条是别名,创建后就立刻可以使用,已经是绿色的Verified
状态。不过,由于这个域名是别名,不是客户自己的域名,因此只在测试阶段会测试登录等用户,一般不会用于正式的使用。接下来还是完成域名验证。点击域名进入详情。如下截图。
进入域名验证详情后,可以看到屏幕上给出了多种类型的认证,他们包括如下几类:
- 1、域名所有人验证:TXT记录
- 2、邮件服务:MX记录和CNAME记录
- 3、安全DKIM认证:CNAME记录和TXT记录
- 4、设置发件人(自定义Mail From)的DMARC认证:需要在SES服务中完成。
点击屏幕上方的Copy all
按钮可以复制所有的解析到剪贴板。如下截图。
下文将先进入Route53配置1、2、3这三种类型的认证,然后再进入SES配置配置类型四所需要的DMARC认证。
2、在Route53上配置域名所有人、邮件服务、安全DKIM认证
配置域名所有人、邮件服务、安全DKIM认证的流程是完全相同的,现在以配置域名所有人为例。
首先从上一步的Workmail的Domain配置界面中,搜索获得对应的解析记录。例如复制出来结果如下:
- 记录(Record Name):_amazonses.bitipcman.com.
- 值(Value):nPFx6OKIWyyRlOOmOmVpPWSXe28k0lNTFz819+MFlDo=
进入Route53服务。点击左侧的Hosted zones
菜单,找到要添加解析的域名。如果不存在的话,可以点击Create hosted zone
。如果要解析的域名已经存在了,那么点击名称,即可进入解析记录配置界面。如下截图。
在解析记录界面,点击右上角的Create record
按钮创建新的解析记录。如下截图。
在左上角的名称位置,输入的要增加的域名解析的_amazonses.bitipcman.com.
的子域名,也就是不包含域名本身的部分。在本例中,在Record name
的位置填写_amazonses
。然后,在解析类型Record type
位置从下拉框中选择类型是TXT
,在Value
输入完整的解析,本例中就是从一开始的解析记录复制下来的nPFx6OKIWyyRlOOmOmVpPWSXe28k0lNTFz819+MFlDo=
。输入完毕,在TTL生存期位置保持默认的300秒无需修改,然后点击右下角的Create records
按钮创建解析。如下截图。
创建完成后,页面显示创建成功。在下方的Records
搜索过滤框中,输入关键字,就可以看到刚才创建好的子域名。如下截图。
至此第一个子域名配置完成。配置完成后,等待约5分钟。回到域名清单界面,可以看到第一个子域名已经显示为绿色的Verified
通过认证。
接下来重复上述步骤,配置邮件服务所需要的MX记录和CNAME记录、以及安全DKIM认证所需呀的CNAME记录和TXT记录配置完成。
配置注意事项:
- 包括CNAME记录在内,解析Record的值(Value)最后结尾有一个小圆点,复制时候请复制整条(包含小圆点)一起粘贴到域名解析位置。
- 其中有一条是根域名的TXT记录,配置这条记录的时候,再填写子域名留空。如下截图。
在Workmail服务的Domain可看到是安全认证部分的根域名的TXT记录。如下截图。
配置Route53域名解析时候,子域名部分留空,直接填写记录类型和记录值即可。如下截图。
配置完成,可能最多需要等待1小时,在通过Workmail服务的Domain界面,可看到刚才显示未经认证的域名都认证完毕。
3、为SES的Send from Custom Domain配置DMARC认证
在上一步完成后,可以看到在Workmail服务的Domain内前三项认证都通过,只剩下最后一条Custom MAIL FROM domain
显示尚未认证。此时提示可点击跳转到Amazon SES服务。如下截图。
点击后进入SES服务。找到左侧Verified Domains
菜单,在当前域名下,点击第一个标签页Authentication
,然后向下滚动页面。如下截图。
在页面最下方Custom MAIL FROM domain
位置,可以看到显示Not started
。此时点击右侧Edit
编辑按钮修改配置。如下截图。
在启用自定义发送位置选中对话框表示开启,在外发子域名位置,输入workmail
作为子域名,在Behavior on MX failure
位置选择第一项默认的。然后点击保存配置按钮。如下截图。
配置完毕后,可看到SES服务又给出了两个需要添加认证的记录,这两个记录的配置过程,需要仿照上述步骤,在Route53上完成子域名解析的设置。如下截图。
配置Custom MAIL FROM domain
所需要的两条子域名解析的操作这里不再赘述。
配置完成。此时可以看到,SES服务的Custom MAIL FROM domain
位置显示认证成功。如下截图。
至此SES服务配置完成。
4、切换Workmail外发时候使用的默认域名
为更好理解的Workmail的默认域名,先来看一个差不多的例子:CDN即CloudFront服务。
例子:当创建好CloudFront发布点后,CloudFront 默认会分配一个AWS的域名例如d123456.cloudfront.net
,然后用户需要将自己的域名www.abc.com
以CNAME记录的方式解析过去,即可实现使用用户自定义域名作为入口。此时,用户自己的CNAME域名和AWS自动生成的d123456.cloudfront.net
是可以同时访问的。
在Workmail配置中,如同刚才CloudFront的例子,Workmail也会默认分配一个使用xxxx.awsapps.com
样式域名,他和用户自定义的域名也是可是同时使用的,这里需要切换下默认值,将认证完毕的用户自定义域名作为发送时候的默认域名。
现在回到Workmail服务的Domain详情标签页。在详情标签页下,可看到所有的四种类型的解析终于都成为了绿色状态。如下截图。
现在返回上一级菜单Domains
清单,可看到四种Domain认证方式都配置完成后,自定义域名的状态也变成了绿色。现在需要将其设置为默认域名。如果不完成这个步骤的设置,那么发出邮件后,别人看到的发件人将不是您自己绑定的域名,而是AWS默认分配的xxxx.awsapps.com
域名。
点击选中自己的域名,点击右上角的Set as default
。如下截图。
设置成功。如下截图。
至此后台需要的配置完成。
另外请注意,在以上配置完成后,在SES服务控制台的左下角菜单Email receiving
内,能看到Receipt rule sets
下,将会自动生成一条INBOUND_MAIL
的规则。这条规则就是负责将SES接收邮件与Workmail集成的。请勿删除这一条,否则绑定本域名的Workmail将不能正确接收邮件。
下一步开始增加用户。
四、创建用户并使用企业邮箱发送和接收
1、新建用户
进入左侧组织菜单下的Users
菜单。点击右上角的添加用户按钮。如下截图。
我们以张三为例。输入邮箱名zhangsan
,姓(Lastname)和名(Firstname)为可选输入,在下边友好显示名称Display name
位置输入Zhang San
。如下截图。
在用户id部分输入对应的邮箱,以及域名后缀。在Show in global address list
位置选中。在Remote user
位置留空。然后输入两次密码。点击右下角Add user
按钮,完成用户添加的过程。如下截图。
创建完成。
2、登录WEB UI并测试发送和接收
现在查询WebUI入口。
进入组织菜单的顶层菜单,从右侧找到Amazon Workmail web application
的位置,其域名就是入口。如下截图。
点击跳转。输入用户名和密码,点击登录。如下截图。
登录成功。
现在测试收发。通过WEB界面,向外部邮箱(例如Gmail)发一份邮件。编写好之后,点击Send
按钮发送。如下截图。
登录到Gmail中,检查是否成功收到来自Workmail自定义域名的发信。可确认收到,且显示发来的来信人的信息正确。如下截图。
起草一封回信,从Gmail向Workmail邮箱的用户张三发送。如下截图。
回到Workmail网页界面,刷新后可看到,接收成功。
至此Webmail的收发测试成功。
3、关于发送到国内邮箱时候显示为代发的说明
Workmail的主要使用场景是海外员工的企业邮箱,因此其发送的目标一般也是Gmail/Outlook等海外邮箱。当发给Gmail/Outlook等海外邮箱时候,Gmail/Outlook识别发件人正常,如本文上一个章节的页面截图。
当发送给国内邮箱的时候,国内邮箱可能会显示邮件由xxxxx.xxx@yourdomain.com代发的字样。这是由于由于国内很多邮箱对DMARC认证后的域名识别不好,即便用户自定义域名通过了包括DMARC在内的多种认证过,邮箱页面上依然会显示邮件由Amazon SES的域名代发的字样。这个问题是国内的邮件服务商造成的,之前测试Gmail时候也可以看到Gmail识别准确,不会显示邮件由Amazon SES代发。如下截图。
本问题是由国内邮件服务商的技术特性造成的,与Workmail无关。今后如果国内的邮件服务商改进对DMARC的识别,就和Gmail/Outlook一样不显示由xxx代发这样的字样了。
4、使用邮件客户端测试
下面测试配置邮件客户端,这里以Windows上Outlook为例。
启动Outlook客户端,在配置界面输入邮箱名称。如下截图。
在邮件服务器类型位置,选择Outlook.com
类型,表示云端在线邮箱。如下截图。
在弹出窗口中,点击Allow
允许自动发现识别邮箱配置。选中下边的对话框,未来将不再提示本信息。如下截图。
输入邮箱名称和密码。如下截图。
配置完成,点击OK按钮启动Outlook。如下截图。
启动Outlook后,同步云端刚才用Webmail测试的邮件完成,邮件已经被同步到Outlook中。
至此客户端配置完成。
5、配置移动端通过Exchange协议实现邮件、日历的同步
Workmail至此多种方式的移动端同步,即包括传统的IMAP方式,也包括兼容Exchange协议的ActiveSync至此。本文使用iOS 17系统为例进行配置。
在移动端配置Workmail的同步又分成手动配置和自动发现配置。自动发现配置需要配置额外的API提供autodiscover.xml
文件的托管和解析,相对步骤较多,本文不展开描述,请参考文本末尾的参考资料进行配置。
手工配置的主要流程如下:
- 进入iOS系统设置,找到
邮件
,找到账户
菜单,点击进入 - 在账户类型中选择
Microsoft Exchange
- 在电子邮件地址中,输入本次配置的邮箱全民,例如本例是
zhangsan@bitipcman.com
,描述部分填写Workmail
等友好名称,点击下一步继续 - 在弹出的对话框中,选择
手动配置
- 在弹出的对话框内,确认邮箱全名正确,然后输入密码
以上操作部分如下截图。
在输入密码后,继续输入如下关键信息:
- 电子邮件输入全名,本例中是
zhangsan@bitipcman.com
- 服务器输入
mobile.mail.us-west-2.awsapps.com
,如果是其他区域,请替换中间的区域代号 - 在域(Domain)位置,留空不需要输入
- 在用户名位置,输入邮箱全名,本例中是
zhangsan@bitipcman.com
- 在密码位置输入密码
- 描述位置保持上一步输入的
Workmail
不变。
点击下一步继续。如下截图。
接下来选择要同步的服务内容,包括邮件
、通信录
、日历
、提醒事项
、备忘录
,默认都是开启同步状态。最后点击存储,即可完成配置。再次点击邮箱,即可查看同步开关、同步日期等选项。
至此iOS手机移动客户端配置完成。接下来可以测试手机发送和接收,以及手机日历同步。
五、参考文档
Setting up email clients for Amazon WorkMail
https://docs.aws.amazon.com/workmail/latest/userguide/clients.html
连接 iOS 设备
https://docs.aws.amazon.com/zhcn/workmail/latest/userguide/mobile-client.html#connectios_device
启用配置 AutoDiscover 终端节点
https://docs.aws.amazon.com/zh_cn/workmail/latest/adminguide/autodiscover.html