Less boo. More booked. Halloween offer: 30 days free on any paid plan. Claim 30 days free
Pick a domain, choose how many mailboxes, and OneMail registers it, publishes MX, SPF, DKIM and DMARC correctly the first time, creates the mailboxes, and hands them to warmup already connected.
Record types published for you: MX, SPF, DKIM, DMARC
The problem
Writing the sequence is easy. Standing up sending domains that are authenticated correctly, separated from your main domain and spread widely enough that one reputation problem cannot take everything down is the job most people get wrong.
See it work
Mailboxes appear in Accounts alongside any you connected yourself, and go straight to warmup at a small volume that rises each day.
Why it matters
MX, SPF, DKIM, DMARC and a bounce subdomain, with one SPF record and one DMARC record enforced rather than duplicated.
Each record is resolved after publishing and checked until it answers correctly. A domain is not Active until it does.
OneMail can register the domain, or generate and verify the full record set for one you already own.
How it works
Register a new domain through OneMail, or connect one you already own.
The record plan goes out, including a DKIM key pair generated for this domain, and each record is checked until it resolves.
They appear in Accounts and begin warming at a small volume that rises each day.
Registered and configured
Setting up a cold-sending domain properly means registering it, pointing MX at a mail host, publishing an SPF record that does not exceed the lookup limit, generating a DKIM key pair and publishing the public half at the right selector, adding a DMARC policy, and creating a bounce subdomain with its own MX and SPF. OneMail does all of it and then verifies that what it published actually resolves.
Or bring your own
You do not have to buy through us. If the domain is somewhere Warmerly can reach (or you would rather publish the records yourself) OneMail generates the exact record set for that domain and checks each one until it resolves, so a typo in a DKIM key surfaces immediately rather than as an unexplained placement problem three weeks later.
Correct by construction
More than one SPF record at a name is a permanent error under RFC 7208, and more than one DMARC record means the policy is discarded entirely and silently. Publishing into a zone that already has records is exactly where this goes wrong. OneMail's publisher treats name plus record type as the identity for these two, merging rather than duplicating, because a second record does not add protection. It removes it.
The hardest part of cold email is not writing the sequence. It is standing up sending infrastructure that is authenticated correctly, separated from your main domain, and spread across enough domains that one reputation problem does not take everything down. OneMail is that job, done for you, in one flow.
Reputation is scored at the domain level. If you send cold outreach from the domain that also carries your invoices, your support replies and your password resets, then every complaint, every bounce and every spam-folder placement from that outreach is charged against the domain your business depends on. Recovering a damaged primary domain is measured in months.
The standard answer is a separate sending domain, a lookalike of your brand, registered specifically for outreach, with its own reputation to build and its own reputation to risk. If it gets damaged you retire it. That is a cost of doing business rather than a crisis.
One domain is not enough either
Concentrating every mailbox on a single sending domain gives you one reputation and one failure that takes all of your capacity at once. Several domains with a handful of mailboxes each is the shape that survives a bad month.
DMARC deliberately starts at p=none. Publishing p=reject on a brand-new domain before you have observed what actually sends as it is the fastest way to have legitimate mail silently disappear. Move to quarantine once the picture is clean.
The most expensive class of DNS bug is the one where the record was written and nobody checked it resolved. A DKIM key truncated on paste, a TXT record wrapped by a control panel, a zone that was not the zone actually serving the domain, all of these look like success in the panel and produce authentication failure at the receiver.
OneMail resolves each record after publishing and keeps checking until every one answers correctly. A domain does not become Active in the interface until it does. The status you see is the resolver's opinion, not the API call's return value.
Each stage is visible while it happens, including the failures. A registration that fails, a DNS record that will not verify, a mailbox that could not be created, all of them show as a state with a reason rather than as a spinner that never resolves.
Related
Correct authentication removes an entire category of problem, but it does not buy reputation. A domain registered today has no history, and providers treat young domains with justified suspicion because throwaway domains are the classic spam pattern. Perfect DNS on a three-day-old domain sending two hundred cold emails will still be filtered.
This is why OneMail starts warmup on every new mailbox as soon as it exists, and why a campaign on young mailboxes starts with the volume ramp rather than at full volume. The domain needs weeks of ordinary, engaged correspondence before it can carry meaningful cold volume, and the ramp counts the days a mailbox has really been warming rather than your launch date. It is the least convenient part of the product and the part most worth respecting.
More from Warmerly
No. OneMail can register one for you, or generate and verify the full record set for a domain you already own. The verification loop is the same either way.
Provisioning and DNS verification usually complete within a few hours, subject to registration and propagation. Being ready for real cold volume is a separate question, plan on two to four weeks of warmup on a newly registered domain.
p=none initially, so you can observe what authenticates before anything gets rejected. Tightening to quarantine once the picture is clean is the right next step.
So bounce handling has its own MX and SPF and does not have to share the apex. It is a small detail that most setup guides skip and that causes odd, hard-to-diagnose failures later.
The domain is yours. The mailboxes are hosted by us, so moving means standing them up on another host and re-pointing MX, the same as any mail migration.
Keep reading
Registered, authenticated, verified and warming, without you opening a DNS panel or generating a DKIM key by hand.
Start free
