Your domains. Clearly connected.
Sending and receiving are separate choices. Start with the records your own Mailat instance generates.
For sending-only setup, leave the root domain’s MX records with your existing provider. A MAIL FROM MX record on a subdomain such as bounce.example.com is for SES feedback routing, not your inbox.
1. Add a domain you own
- Open your deployed Mailat instance from the hosting dashboard.
- Go to Domains → Add Domain and enter a domain you control.
- Choose sending-only setup if another service receives mail for that domain.
- Copy the exact DNS names and values generated for your domain, account and region.
- Add the records at your authoritative DNS provider, or use Mailat’s supported DNS-provider connection after reviewing the proposed changes.
Sample hostnames in this guide explain the structure. They are not values to paste into your own DNS zone.
2. Configure sending authentication
DKIM: sign with your domain
Add the DKIM CNAME records shown by Mailat and SES. Preserve the exact selector and destination. Some DNS providers append your domain automatically, so check that it is not duplicated in the hostname.
Custom MAIL FROM: a separate subdomain
Mailat’s SES setup uses a dedicated MAIL FROM subdomain, commonly bounce.example.com. It has its own MX and SPF TXT records. Use the region-specific destination shown in your instance.
| Record | Where it belongs | Purpose |
|---|---|---|
| CNAME | Generated DKIM selectors | Domain verification and signing |
| MX | MAIL FROM subdomain | SES feedback routing |
| TXT (SPF) | MAIL FROM subdomain | Authorize SES for this envelope sender |
| TXT (DMARC) | _dmarc policy hostname | Domain-wide authentication policy |
Do not replace an existing root SPF policy with an SES-only policy or add a second SPF record at the same hostname. The MAIL FROM subdomain has its own SPF record. Read AWS’s custom MAIL FROM guide for the exact regional record format.
3. Enable receiving only if you want it
Receiving through Mailat requires an explicit receiving setup, including a supported SES receiving region, receipt rules, storage and notifications. Sending verification by itself does not activate a Mailat inbox for the domain.
Replacing your current provider’s root MX records changes where new mail goes. Review the receiving instructions and your current provider before making that change. Adding different providers’ MX records does not create two synchronized inboxes.
Use the receiving destination supplied by your Mailat instance. Do not point mail MX records at your control-panel website or assume an A record enables receiving. See AWS’s receiving MX documentation.
4. Respect existing DMARC policies
DMARC is a policy for your whole sending domain, including mail sent through other services. Mailat checks for an existing direct or inherited policy before offering a new record.
- Existing valid policy: keep it. Review its reporting addresses, alignment and enforcement settings together with your other sending services.
- Inherited policy: review the parent domain’s policy before adding an override.
- No policy found: Mailat can offer a single
v=DMARC1; p=quarantine;record after a successful check. - Conflicting records or an uncertain lookup: resolve the issue and recheck instead of adding another record.
Do not concatenate multiple DMARC policies or publish duplicate DMARC TXT records. A quarantine policy can affect legitimate mail from another service if that service does not authenticate in alignment with your domain. Review all senders before changing enforcement.
Reporting addresses are optional policy settings. Only add a reporting mailbox you control and intend to use. Mailat can organize supported aggregate reports into its DMARC Reports folder when that feature is enabled in the email app.
5. Verify, then test
- Wait for your DNS changes to propagate and recheck each status in Mailat.
- Confirm the SES identity and DKIM state in the same AWS region.
- Test sending to an address you control and inspect authentication results at the receiving provider.
- If receiving is enabled, send a separate inbound test and check that it reaches your Mailat inbox.
Authentication is necessary, but it does not guarantee inbox placement. Sender reputation, recipient engagement, message content and the receiving provider’s rules still matter. A DNS check that is pending should stay pending until its result is confirmed.