Understanding and verifying your email DNS records

Email DNS records tell other mail services where to deliver messages and how to check mail sent from your domain. Use this guide to read the records Cedros generates, publish them in the right place, and understand a verification result.

This guide covers Cedros-hosted email. If your mailbox stays with Google Workspace, keep its receiving records and follow Connecting your Google Workspace account. For the full domain and first-address workflow, start with Setting up Cedros email on your domain.

Open the records for the correct domain

1. Open Settings → Site → Mail.
2. Find Mail domain and confirm the domain. If Manage domain appears, select the domain you are checking.
3. If the records are collapsed, open the ⋯ menu beside Recheck DNS and choose Show DNS records. Incomplete records can already be visible.
4. During initial setup, open Set up mail → Add DNS records at your registrar instead. The verification button there is Check records.
5. Read each record's type, host, value, purpose, status, and any priority or TTL. Use Copy beside a value to avoid transcription mistakes; copy its host and other fields separately.

The record list belongs to that domain and installation. Do not copy values from another customer's screenshot, an old setup, or the examples in this guide. If a value has not been generated yet, finish the reported provider or mail-service setup before trying to publish it.

Confirm who hosts the domain's authoritative DNS: the service named by its active nameservers. This is not always the registrar where you bought the domain. A correctly entered record in an inactive DNS account will not affect public mail delivery.

Understand what each record does

• Incoming MX — Directs mail for your addresses to the receiving mail server. Copy the destination hostname and priority shown by Cedros.

• SPF — A TXT record that lists which senders are authorized for a particular sending domain. A policy at the root and one at a bounce subdomain apply to different names.

• DKIM — Lets recipients check a message's digital signature. Cedros's SES setup supplies generated CNAME records under names containing _domainkey.

• DMARC — A TXT policy that connects authentication to the visible From domain and states how receivers should handle messages that fail that check.

• SES MAIL FROM — MAIL FROM MX and TXT records support the separate bounce/return-path domain used for outgoing mail. They do not route normal incoming messages to your Cedros inbox.

• MTA-STS and TLS reporting — MTA-STS and TLS reporting records support secure incoming transport and delivery reports. Use the generated records and the installation's associated HTTPS policy setup.

A mail server hostname must also resolve to its correct public address. Depending on the installation, that hostname may be on your domain or managed elsewhere. Ask the mail administrator for the expected address; do not point it at the website's IP simply because the website works.

Two MX records can have different jobs. For example, the MX at your mail domain routes incoming messages, while an MX at the configured bounce subdomain supports SES feedback. Check the host, not just the record type. AWS's custom MAIL FROM guidance explains that separate domain and requires exactly one MX at the custom MAIL FROM name.

Enter the records without changing their meaning

If managed DNS or a connected Cloudflare account handles the records, review its status before adding duplicate manual entries. Cedros can publish records automatically as setup becomes ready. Coordinate an existing-mail migration before enabling automation or creating the mail domain, since incoming routing can change once the service and an address are ready.

For manual entry:

1. Open the active DNS provider's record editor for the correct zone. Save a copy of the existing mail records before changing them.
2. Select the exact type shown by Cedros. SPF is entered as TXT; SES DKIM instructions use CNAME.
3. Enter the host/name in the provider's expected format. For a zone called example.com, @ means the zone root and _dmarc means the name _dmarc.example.com. Some providers want the full name; others append the zone automatically. Check the resulting name so the domain is not added twice.
4. Paste the complete value. Preserve TXT policy syntax and the full generated DKIM target. Follow the DNS provider's instructions for quotation marks; do not add extra quotes as literal text.
5. For MX, enter the displayed priority in the priority field if the provider separates it from the server name. Enter a hostname as the destination, not an email address, IP address, or website URL.
6. Apply the displayed TTL where supported, or the provider's appropriate default. Save the record, then compare the saved type, full name, value, and priority with Cedros.

Only change the records involved in the setup. Preserve website records, verification TXT records, and authorizations for other services you still use. Switching incoming MX does not copy historical mail or automatically create missing recipient addresses; prepare those before the switch.

If you use Cloudflare, an email server hostname must resolve through DNS only, not its website proxy. MX records themselves are already DNS-only. Keep generated DKIM CNAME records DNS-only as well so recipients can resolve their targets. See Cloudflare's email DNS troubleshooting guidance.

For DNS access and automation, see Connecting Cloudflare to manage your DNS. For manual provider entry, see Setting up a domain with another DNS provider.

Check SPF and DKIM without breaking other senders

Publish one SPF policy at each hostname. If you already have a TXT record beginning with v=spf1 at that name, do not add a second SPF record beside it. Have the administrator reconcile the services that need to send into one valid policy, then align the provider configuration and expected records in Cedros.

Other TXT records can coexist with SPF. A website verification TXT record is not a duplicate SPF policy and should not be removed to clear an SPF conflict.

The root domain and bounce subdomain are separate. Cedros may show a root policy of v=spf1 -all while the bounce subdomain authorizes SES. The root policy says that no senders are authorized by SPF for that root name; it does not cancel a different policy on the bounce subdomain. If another service sends using the root domain, review its requirements before replacing its existing policy. Do not add an SES include to every SPF record without checking which domain the service actually uses.

For DKIM, publish every generated record for the current sending setup. Keep each selector name paired with its own target; do not reuse another row's target or turn the CNAME into a TXT record. Several DKIM selectors can legitimately exist for different services or key rotations, unlike duplicate SPF policies at one name. Preserve another active sender's selectors unless its owner confirms they are no longer needed.

If the expected SPF value in Cedros still disagrees with a deliberately combined policy, take that mismatch to the administrator. Do not alternate between conflicting policies just to make a status badge green.

Choose a DMARC policy deliberately

DMARC checks whether a passing SPF or DKIM result aligns with the domain readers see in the message's From address. A DNS record existing is not proof that every service sending as your business passes that check. AWS describes this relationship in its DMARC authentication guidance.

In Mail domain → ⋯ → DMARC enforcement…, Cedros offers:

• Monitor only: requests monitoring without asking receivers to quarantine or reject mail because of DMARC failure.
• Quarantine suspicious mail: asks receivers to treat failing mail as suspicious, often placing it in spam.
• Reject spoofed mail: asks receivers to reject mail that fails the policy.

Receivers apply their own handling rules. Even with Monitor only, ordinary spam filtering still applies.

Start with an authentication review of all legitimate senders, including newsletters, receipts, support tools, and any service used during migration. Confirm their alignment and inspect reports before moving to enforcement. A stricter policy can affect genuine mail as well as spoofing.

If you intentionally change the setting, choose the policy and select Save policy, then publish and recheck the revised DNS record. With automation, confirm what was actually published. Keep one DMARC policy at the displayed _dmarc name; do not leave the old policy beside the new one. Check that any report destination in the policy is usable and monitored rather than assuming DNS creates that mailbox.

Run verification and read the result

1. After saving the DNS changes, return to the same domain in Cedros.
2. Select Recheck DNS, or Check records in the initial setup flow.
3. Read each row's status and any error. Where Found: appears, compare those observed values with the expected value above it.
4. Check both the required-record count and the individual optional rows. Resolve the relevant failures before testing the associated service.
5. If records changed during the check, reopen the current list and check again. Otherwise, allow for the DNS provider's update time and cached records' TTL before repeating verification.

Verified means the check accepted that record's DNS result. Pending, Unknown, or Not configured does not establish that the record is correct; read the accompanying reason. Failed needs comparison with the expected entry, not an automatic deletion of everything at that name.

Inbound DNS verified reflects the required incoming-mail records. Rows marked Optional do not block that required count, but they can still be necessary for outgoing authentication, reporting, or transport protection. A green incoming badge can coexist with unfinished SES setup.

SES verified is a separate sending-domain status. It does not guarantee that the site's outbound service is connected or that a message will reach a recipient's inbox. Complete Setting up outgoing email delivery for provider, sender, and delivery checks. Likewise, verifying an MTA-STS DNS row does not test every part of its HTTPS policy service.

Resolve a failed or uncertain check

Result or symptom	What to do next
Missing record	Check the active DNS provider, record type, and full host name. Confirm the entry was saved, then allow for DNS caching and recheck.
A different value is found	Compare the exact target or TXT policy and any MX priority. Identify the owner of an existing value before replacing it.
Multiple SPF or DMARC records	Reconcile to one policy at that name. Keep the authorizations and reporting settings that are still required.
Public DNS cannot be reached	Retry verification later. That lookup failure alone is not evidence that you should change DNS.
The value has not been generated	Complete the reported mail-service or sending-provider setup. Do not publish placeholder text.
Cloudflare automation failed	Follow Reconnect Cloudflare or Open Cloudflare setup, if offered, or coordinate manual entry with the DNS administrator.
MX looks correct but mail is missing	Follow Why aren’t my emails arriving? to check the mailbox, folders, storage, old provider, and receiving service before changing DNS.
Incoming records verify but sending fails	Follow Why can I receive email but not send it? to identify the sending failure. Changing incoming MX will not fix an outbound provider restriction.

If settings keep reverting, check whether another DNS automation or mail-routing service owns those records. Agree on the intended configuration before making repeated manual edits.

For unresolved problems, provide the domain, record type and host, expected and found values, error text, and time of the last check. Include which DNS provider is authoritative and whether automation is enabled. Do not send provider passwords or API credentials.

Confirm mail works after DNS verifies

Finish with a real delivery check: send from an independent address to the Cedros mailbox, open the message, reply from the intended Cedros address, and confirm the reply arrives. Check important aliases and other recipients during a migration. Use the external send-and-reply checklist for the full sequence.

For authentication review, inspect the received message's authentication results with the sending administrator, especially before enforcing DMARC. Successful DNS verification supports that review; it does not promise delivery, spam-folder placement, or readiness of every sender using the domain.