Skip to content
MailHaap
[06]Domains

Adding a domain

Add a domain, publish the records we generate, and verification starts polling automatically. We read your existing DNS first and adapt — the wizard will never tell you to publish something that breaks the email you already have, and it can physically not generate an instruction to add a second SPF record.

The record set
KindTypeHostRequired
ownershipTXT_mailhaap.{domain}Yes
dkim (×3)CNAME{selector}._domainkey.{domain}Yes
spfTXT{domain}Yes — merged, never a second record
mail_from_mxMXbounce.{domain}Yes for sending
mail_from_spfTXTbounce.{domain}Yes for sending
dmarcTXT_dmarc.{domain}Strongly recommended
trackingCNAMEtrack.{domain}Optional, strongly advised
mx (×2)MX{domain}Only if you host mailboxes with us
autodiscoverCNAMEautodiscover.{domain}Mailbox only
tls_rptTXT_smtp._tls.{domain}Optional

Why the custom MAIL FROM subdomain is not optional

The bounce.{domain} records give you a Return-Path aligned with your own domain. Without them the Return-Path belongs to the sending provider, SPF alignment under DMARC fails, and you can never move to p=reject. Two records, permanent benefit.

How verification works

Every check queries four sources in parallel and requires agreement from at least two: Cloudflare, Google and Quad9 over DNS-over-HTTPS, plus the domain's own authoritative nameservers found via an NS lookup. Querying the authoritative server is what makes propagation messaging accurate — it lets us say “the record exists, your resolver has not caught up” instead of “missing”.

  1. Every 10 seconds for the first 5 minutes
  2. Every 60 seconds for the next 55 minutes
  3. Every 15 minutes for the next 24 hours
  4. Hourly for 72 hours, after which the domain is marked failed

Proxied DKIM records break DKIM

If a DKIM CNAME sits behind Cloudflare's proxy (the orange cloud), the record resolves to Cloudflare rather than to the key, and signing fails. Switch it to DNS only. We detect this specific case and say so by name.