Email DNS and deliverability

This guide shows how to bring your domain’s email in line with the Gmail, Yahoo and Microsoft sender requirements. That raises the chances of a message arriving quickly and landing in the inbox. No server can guarantee inbox placement: the final decision belongs to the recipient’s provider and also depends on your IP reputation and on the content.

Examples use example.com and 203.0.113.10. Replace them with your own values.

Why the first email can take a few minutes

With a new IP and domain, Gmail often answers “try again later” (codes 421 4.7.28 or 4.7.0). The server keeps the message and retries; the first retry is about 2 minutes later. This fades after weeks of regular sending, at a low and growing volume, without complaints. The panel shows the cause under Email sending health, in the “Sending queue” item.

Note: if the reason is 4.7.26, 4.7.27, 4.7.30 or 4.7.32, it is not a rate limit. It is an authentication failure (SPF, DKIM or sender domain alignment) and waiting does not fix it: check SPF and DKIM below and the domain used as the sender.

Note

Registering a domain restarts the mail server for a few seconds, because Stalwart only signs with the new DKIM key after a restart. Open connections drop and come back; the sending queue is kept. If the restart fails, the panel shows DKIM as attention (restart pending), and messages go out unsigned until the next sync.

1. Set up DNS in order

Open the domain on the Email page. The Email sending health card has the DNS step by step, with the records in order and copy buttons:

1. A for mail.example.com pointing to the server IP.
2. MX for the domain pointing to mail.example.com.
3. SPF (TXT) authorizing the server IP.
4. DKIM (TXT at paas._domainkey), the public key generated by the panel.
5. DMARC (TXT at _dmarc), starting at p=none and tightening later.
6. Optional: TLS-RPT and MTA-STS.

Cloudflare: gray cloud

In the Cloudflare dashboard, under DNS, the A records for mail (and autoconfig, if you have it) must be gray cloud (“DNS only”). With the orange cloud (proxy), other servers see Cloudflare’s IP, which does not receive email, and MX and SPF stop matching. MX and TXT records are never proxied. In the MX field the mail server is mail.example.com and the priority is 10.

PTR (reverse DNS) at the VPS provider

The PTR is not in your domain’s DNS. You set it in the VPS provider’s dashboard (a “reverse DNS” or “rDNS” field on the IP screen). It must point to the server name shown in the panel, for example mail.example.com, and that name needs an A record for the same IP. Without a PTR, many providers delay or reject the message.

The PTR is per server IP, not per project or domain: a single PTR, pointing to the mail server name (the same one used in HELO/EHLO, which must have an A record back to the IP), covers every project. On Contabo: Customer Control Panel, open the Reverse DNS Management menu, choose the IP, type the name and save. On other hosts look for “Reverse DNS”, “rDNS” or “PTR”; if there is none, open a ticket. The panel shows the expected name, the value found and ready-made text (“Please set the reverse DNS (PTR) of IP X to the name Y”) filled in with your own VPS data.

Why this is important attention and not critical: with SPF, DKIM and DMARC passing, Gmail accepted messages without a PTR. Microsoft, Yahoo and corporate servers may delay or refuse, so fix it before sending in volume.

2. Read the health panel

Click Check health now (limit of 6 per minute). Each item has a state:

• OK: in line.
• Attention: works, but may hurt delivery (1024-bit DKIM key, inherited DMARC, certificate close to expiry, DNS still propagating).
• Critical: likely to block or badly hurt sending (blocked port 25, SPF, DKIM or DMARC failure, stopped server). A red notice lists these items. Attention items that also affect delivery (like the PTR) appear in an orange notice.

Items come in two groups: Server (IP, reverse DNS, port 25, certificate and blocklists, which apply to every project) and Domain (A, MX, SPF, DKIM, DMARC, propagation, MTA-STS, TLS-RPT and that domain’s sending queue, per domain). On the page of each project with email, the Sender tab shows the worst level between domain and server, with the count of each, and highlights in red any server-level critical item.

Every item that is not in order has a What to do button with short steps and values to copy. When DMARC is p=none and all is well, the panel suggests, without forcing, moving to p=quarantine only after 2 to 4 weeks of good reports; the risk is a legitimate message that fails going to spam, and you can go back to p=none. Optional items (MTA-STS, TLS-RPT) show as Optional · not configured or Optional · incomplete: they stay visible and say what they improve, but they do not count as “needs attention” and do not change the domain badge or the overall one.

MTA-STS: the panel publishes the policy file by itself at https://mta-sts.yourdomain/.well-known/mta-sts.txt, with its own certificate (testing mode, which only reports). To turn it on, create two DNS records: the A record of mta-sts.yourdomain pointing to the VPS IP (DNS only, gray cloud on Cloudflare; a CNAME to mail.yourdomain also works) and the _mta-sts TXT with the value shown on screen. The item checks both records and the file and tells you what is missing: the A, the TXT, a file that does not open or a certificate that is still being issued (a few seconds to a few minutes after the A exists). If the policy already opens and is valid (even when hosted outside the panel), the A record is not required. If the mail server changes, the policy text changes and so does the TXT value: the screen shows the new value. Automatic publishing needs the panel domain configured (Settings → Panel domain); without it the item says so. If you publish an enforce policy that does not list the domain’s real mail server (the MX in DNS, which may belong to another provider), senders refuse delivery: in that case the item stops being optional and lights up, naming the MX that was left out. The *.example.com wildcard matches one level only. If a policy that was in enforce stops opening, the item warns with attention, because senders keep using their stored copy until it expires. A domain whose MX is not this panel’s should not use the policy the panel publishes (it lists the panel’s server): the item warns.

MTA-STS, what the panel does by itself and what stays with you:

• Panel side (automatic, for every mail domain): when you create the domain, the panel registers mta-sts.yourdomain in the proxy and, if DNS already points to the VPS, opens its own policy URL so the certificate is issued right away. On panel start and every 30 minutes the same runs for domains whose policy is not active yet, a few at a time and within the certificate limits. In the domain list each domain shows MTA-STS: waiting for DNS, issuing or active.
• Your DNS side (you): the A record for mta-sts.yourdomain and the _mta-sts TXT. The panel does not create them: it has no access to your DNS provider (no Cloudflare token). The DNS checklist tab lists them next to A, MX, SPF, DKIM and DMARC, with an Optional badge and a found or missing status; they do not count in the “x/y OK” summary.
• When it works: it only counts as Active when the policy opens over HTTPS, is valid and the _mta-sts TXT exists with the right id (a wildcard DNS pointing the A record to the VPS is not enough: without the TXT no sender uses the policy, and the list shows “MTA-STS: TXT missing”). The item shows the Active badge and “MTA-STS active in testing mode”. The setup steps disappear; only a collapsed Details section with the values remains.
• When something is missing: What to do shows the situation (A, TXT and policy, each with a check or cross and the word “Ready” or “Missing”) and only the steps for what is missing: if the A record exists and the TXT is missing, only the TXT appears.
• Verify button (inside the box, admins only): runs only this item right away. It queries A and TXT; registers the name in the proxy if needed; if DNS points and the certificate is missing, triggers issuance and follows it (“issuing…”, re-checking every few seconds up to a limit); if DNS is missing, it shows exactly which record, with the right id value and a copy button. The result is the health item itself, evaluated by the same rule as the full check (real MX records, enforce, invalid policy), and the top alert and counts update with it. It is rate limited, has its own hourly quota of issuance attempts (when used up, the box says “try again at HH:MM”) and is audited whenever the panel reloads the proxy or triggers an issuance.
• Outdated TXT id: when the mail server changes, the policy and its id change. Per RFC 8461, senders that cached the old policy keep using it until max_age (1 day), so the panel accepts the TXT with the previous id for 24 hours: the item stays Active and only reminds you to switch to the new value. After that it becomes “outdated id”.

Mark as acknowledged: some items depend on the VPS provider and not on the panel, such as reverse DNS (PTR) and outbound port 25. Each has a Mark as acknowledged button (with an optional reason; administrators only). The item stays visible with the Acknowledged badge, does not count as “needs attention” and leaves the warning at the top. It only applies to an item in attention: a critical one, such as blocked port 25 (no mail goes out), cannot be silenced. If the problem changes (the PTR now points to another name, or port 25 becomes blocked) it counts again by itself; Unmark also restores it. For the PTR, the Contabo steps still apply: it can be set in the Customer Control Panel; “acknowledged” is for when you decided not to do it now.

Items: A, MX, SPF (including the 10 DNS lookups limit), DKIM, DMARC, PTR, outbound port 25, queue, TLS certificate, blocklists, propagation and, as a bonus, MTA-STS and TLS-RPT. The panel repeats the check every day. IP reputation and complaints cannot be measured from here: use Google Postmaster Tools and Microsoft SNDS.

Changed DNS? Wait: it can take minutes to hours. The “Propagation” item warns when resolvers still disagree.

3. Test and check in Gmail

Under Send test email, type an address of yours and send (at most 60 per day). After “delivered”:

1. Open the message in Gmail.
2. Click the three dots and Show original.
3. Check that SPF, DKIM and DMARC show PASS.
4. See whether it landed in Spam; if so, mark it “Not spam” to help.

The panel does not read your mailbox; it only reports the server-side send result.

If something does not add up

See Troubleshooting for blocked port 25 and email in spam.

A project’s email did not arrive? See My app’s email did not arrive.