Mailcow guide series: Part 4 of 7. Start with Part 1.
Next: Send Mailcow Mail Through Oracle Cloud Email Delivery
This is Part 4 of the Mailcow self-hosted email series. DNS is the public address book for your domain. Mail servers look up these records to learn where to connect, which senders you trust, and which signatures prove a message is genuine.
Confirm Route 53 is authoritative
A domain may be registered at one company and use DNS at another. Route 53 controls the records only when the domain’s registrar delegates its nameservers to the Route 53 hosted zone. In Route 53, open Hosted zones, select your domain, and compare its four name servers with the nameservers configured at the registrar. If they do not match, update DNS at the provider that actually hosts the authoritative zone.
Before editing existing records, save a copy or screenshot of the current zone. If the domain already receives mail, do not delete its current MX or SPF record yet. Lower the existing MX TTL to about 300 seconds a day or more before a planned migration; TTL is how long other mail systems may cache an answer.
Add the mail host address
In Route 53, open the hosted zone and choose Create record. Add:
| Record name | Type | Value | Why |
|---|---|---|---|
mail |
A | Your reserved public IPv4 | Connects mail.example.com to the Mailcow VM |
autoconfig |
CNAME | mail.example.com |
Helps some email clients discover settings |
autodiscover |
CNAME | mail.example.com |
Helps Outlook-compatible clients discover settings |
Use a modest TTL such as 300 seconds during setup. Create an AAAA record only if the VM has working public IPv6, the provider routes it, Mailcow supports it, and the IPv6 firewall rules are open. A broken AAAA record can make some mail servers connect to a dead address even when IPv4 is fine.
A CNAME cannot coexist with another record of the same name. If autoconfig or autodiscover already has an A record, decide which value is correct before replacing it.
Publish the MX record only at cutover
When the new server is ready to receive production mail, add or replace the domain’s MX record:
Record name: (leave blank for the hosted-zone apex)
Type: MX
Value: 10 mail.example.com
TTL: 300 during migration
The number 10 is a priority; lower values are tried first. The MX target must resolve directly to an A/AAAA record, not a CNAME. Route 53’s MX record guide explains the priority and target format. Leave the old mail service active while the change propagates and while you check delivery.
Add SPF without breaking other senders
SPF is a TXT record that names services allowed to send mail using your domain. If you use OCI Email Delivery in Asia-Pacific, Oracle’s example is:
v=spf1 include:ap.rp.oracleemaildelivery.com ~all
This must be the domain’s only SPF policy. If Google Workspace, a website host, a marketing service, or another provider also sends mail for the domain, combine each provider’s documented include: or ip4: mechanism into the same v=spf1 record. Do not create multiple SPF TXT records starting with v=spf1; receivers may treat that as a permanent error. Do not copy an example policy over your current one until you have listed every legitimate sender.
~all means “soft fail” for sources not listed. After testing every sender, you may choose a stricter -all. Oracle’s SPF instructions give the right include for each region.
Add two different DKIM records when using a relay
DKIM signs outgoing messages so receiving systems can check that they were not changed and that a permitted service sent them.
- In Mailcow, open the domain settings and generate its DKIM key. Mailcow displays the selector and the exact TXT name/value. Add that record to Route 53 exactly as shown. A common selector is
dkim, but use the selector your own Mailcow UI displays. - In OCI Email Delivery, configure DKIM for your sending domain. OCI displays one or more CNAME records. Add those exact names and target values to Route 53.
These records have different purposes: Mailcow signs the message when it leaves your mail server; OCI can sign again when its relay sends it onward. Do not overwrite one provider’s record with the other. Route 53 supports long TXT values split into quoted strings; follow the console’s formatting instructions if the Mailcow public key is longer than 255 characters.
Start DMARC in observation mode
DMARC tells receivers how to handle mail that claims to be from your domain but fails authentication. Start by monitoring rather than rejecting:
Record name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
Create the report address or alias before publishing this record. Reports show who is sending mail for your domain. Review them for at least a few weeks and fix legitimate senders before changing p=none to p=quarantine, then eventually p=reject. Do not start with p=reject if you have not inventoried the website, devices, and services that send mail.
Request PTR from the IP provider
A PTR record, also called reverse DNS, maps the public IP back to a host name. For this design the intended pair is:
Forward: mail.example.com -> 203.0.113.10
Reverse: 203.0.113.10 -> mail.example.com
The PTR belongs to whoever controls the public IP, not necessarily the DNS provider. For an OCI address, first publish the A record, then open an OCI support request with the IP and mail.example.com and ask for that PTR. Oracle validates the forward record before creating it; see OCI reverse DNS instructions. PTR is not itself a reputation score, but a consistent host name is an important mail-server identity check.
Check DNS from a terminal:
dig +short A mail.example.com
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig -x 203.0.113.10
On Windows PowerShell, use Resolve-DnsName mail.example.com, Resolve-DnsName example.com -Type MX, and Resolve-DnsName 203.0.113.10 -Type PTR. Continue with Part 5: OCI outbound relay.
Official references: Mailcow DNS requirements, Route 53 MX/TXT record types, OCI DKIM setup.