--- title: "Being trusted by the servers you send to" url: https://www.hmailserver.co.uk/topic/28188/being-trusted-by-the-servers-you-send-to author: "Progressiverobot" published: 2026-09-23T01:45:00.000Z updated: 2026-09-23T01:45:00.000Z category: "TLS, certificates & deliverability" tags: ["deliverability","dns","tls"] site: hMailServer Community Forum --- # Being trusted by the servers you send to *Written for 6.3.4. hMailServer 6.3.7 (17 October 2026) signs a message as a hosted domain only when the server is entitled to: mail from outside whose From names a domain hosted here is no longer signed with that domain's DKIM key, and an authenticated submission is signed as another hosted domain only when its account may send as the address its From names (CVE-2026-107567); the upgrade stops the signing, and only rotating the domain's key ends the signatures already made. A forward of outside mail whose From names the forwarding domain's own organisation is given an SRS or rewritten envelope sender only when the message passed DMARC for it on arrival; with SRS on, mail to an SRS address this server handed out is held to the relay rules unless it is a bounce; and an ARC seal this server makes attests its own SPF result and names the domains its results are for. See [the 6.3.7 announcement](/topic/28277).* Getting mail accepted is mostly DNS. hMailServer does the cryptography and the protocol work. It cannot publish records for you. This is the split. ## What the server does on its own **DKIM signing.** Open the domain's DKIM tab in the Control Panel and click Generate key. It creates an RSA-2048 key, saves the private key, fills in the path and shows the exact TXT record with a Copy button. Once the record is published it signs the domain's outgoing mail - a signed-in account's submission and every copy of it, a message the server makes itself, and mail an IP range lets in as one of this server's domains - but since 6.3.7 not mail from outside whose From names the domain: such mail leaves with the signature it came with. Since 6.3.7 an authenticated submission is signed as another hosted domain only when its account may send as the address its From names (CVE-2026-107567). Ed25519 DKIM (RFC 8463) is supported alongside RSA, for shorter keys. Since 6.3.4 a domain's DKIM keys can also rotate on a policy, off by default. `DkimOversignHeaders` over-signs the header fields you name. `DkimAcceptSha1=0` refuses rsa-sha1 signatures on inbound mail. **SPF and DMARC inbound.** SPF is checked as part of anti-spam scoring, with `SpfVoidLookupLimit=2`. Since 6.3.4 it follows RFC 7208: mail from 127.0.0.0/8 and `::1` no longer passes unconditionally, so a content filter that hands mail back should authenticate, or connect from an IP range with anti-spam off. DMARC policy is evaluated on inbound mail and the DMARCbis tree walk is on by default (`DmarcTreeWalkEnabled=1`). Aggregate reporting stays off until you set `DmarcRptFromAddress`. **Outbound transport security.** `MtaStsEnabled=1`, `DaneEnforcementEnabled=1` and `DnssecValidationEnabled=1` are all on by default, under TLS & certificates → Transport security. A recipient whose DNSSEC chain is bogus does not receive your mail rather than receiving it unencrypted. That is the point of enforcement, so read the logs before you reach for the switch. **TLS-RPT.** Off until you set `TlsRptFromAddress`. After that the server sends daily reports to recipient domains about TLS failures it hit delivering to them. **SRS and BATV.** Off by default. If you forward mail, set `SRSEnabled=1` and a `SRSSecret` to keep forwarded mail SPF-aligned. The secret must be stable. Outstanding SRS addresses remain valid for 21 days, so changing it loses bounces for mail you forwarded recently. BATV (prvs) signs your envelope sender so you can recognise and drop backscatter. Neither ever became an RFC. Both follow the widely deployed drafts, as does everything that interoperates with them. ## What you must publish yourself PTR, and your ISP sets that one, not you. Missing PTR is the single biggest cause of spam-foldering. Then SPF, the DKIM TXT record, and DMARC. For MTA-STS on the inbound side, point `mta-sts.` at the server, set `MtaStsHostingEnabled=1` and `WebServicesHttpsPort=443`, and publish the `_mta-sts.` TXT record. If you publish TLSA records for inbound DANE, keep `AcmeReuseKey=1` so renewals do not invalidate them. Start DMARC at `p=none`. Read the reports for a few weeks and confirm all your legitimate mail passes SPF and DKIM before moving to `p=quarantine`, then `p=reject`. Starting at `p=reject` silently loses mail from the sender you had forgotten about. ## Still incomplete ARC sealing (RFC 8617) covers mail from hosted DKIM-enabled domains. Relayed third-party mail is not sealed yet. Chapter 8, the DNS records with example syntax: https://www.progressiverobot.com/hmailserver-documentation/#8-making-the-internet-trust-you-dns Chapter 9.4, outbound transport security: https://www.progressiverobot.com/hmailserver-documentation/#94-outbound-transport-security Chapter 17.6, SRS and BATV: https://www.progressiverobot.com/hmailserver-documentation/#176-srs-and-batv