What has to be true about your domain before the first campaign leaves

Picture the send. Eight hundred people on a waitlist collected over nine months, and a launch email built the night before. It goes out from the company's main domain on a Friday afternoon because that is when the product was ready. Nothing bounces. The team calls it fine.

What actually happened: a domain with no sending history sent its largest-ever volume to a list where a chunk of the addresses have not thought about you since February. Some of them mark it as spam, which is a reasonable thing for a person to do about an email from a company they half-remember. Gmail now has a first data point about your domain. That is the data point. Everything you send for the next several months is read against it, including the transactional mail your product depends on.

None of this is a technical difficulty. Every item below is a decision. Most take under an hour. The sequence matters more than the individual steps.

If what you want is the mechanics — what each record does, how the three interact, what a selector is, why alignment fails when the signature is technically valid — that is a separate piece and it is better than a summary of it would be. Read SPF, DKIM and DMARC explained once and in full, then come back.

The rest assumes you either did that or your sending platform will handle the records for you, which most will. This is the other half of the problem, and the half that actually goes wrong: the decisions nobody makes explicitly because they are not steps in anybody's setup wizard.

Marketing mail goes from a subdomain. mail.yourcompany.com, or hello.yourcompany.com, or whatever you like — just not the root domain your team emails from. That is the whole decision. Make it before you create the account with your sending platform, because the platform will ask.

The consequence of getting it wrong is specific and it is not about marketing. Mailbox providers score reputation per sending domain. Send campaigns from your root and you have welded your marketing reputation to your ability to email an investor, reply to a customer, or get a contract signed. One campaign that draws complaints, and the person who feels it is your CEO wondering why the board deck email went to spam. That is not a hypothetical failure mode, it is the standard one.

Reversing it later is the painful part. Moving to a new sending domain means starting the reputation build again from nothing, which is weeks of deliberately throttled sending. Choosing correctly on day one costs you one dropdown.

If you send both marketing and product mail — receipts, password resets, alerts — split those too: campaigns on one subdomain, transactional on another. Transactional mail is the mail you genuinely cannot afford to have delayed. It should not share a reputation with the promotional send that went out on a bad day.

Every remaining item is a DNS change, so the practical blocker is almost never technical. It is that the domain was registered on a personal account by a founder who is now on holiday, or an agency did it in 2023 and nobody has the login, or the one person with access is the CTO and this is item nine on their list.

Find out now, not on the afternoon of the send. Two people should have registrar access. One of them should be someone whose week is not on fire. If your domain is at a registrar you cannot log into, that is this week's work and everything else on this list is blocked behind it.

Use a real name at your sending subdomain. Make sure replies reach a human being. Not noreply@.

Two costs to the no-reply address. The first is that reply behaviour is a positive signal in how mailbox providers assess whether people want your mail. A no-reply address opts you out of ever producing one. The second is larger at your stage: a customer who replies to your launch email with a question gets a bounce, concludes you are not interested and does not try a second route. You spent months getting them onto that list.

The other half of this decision is the from-name, and the rule is that it should not change. Your recipients build recognition around a consistent sender identity. A program that alternates between the company name, a product name and a founder's name is three senders as far as recognition is concerned. Pick one and keep it for a year.

The sequencing point that most startups get backwards: authentication is not a thing you tidy up once volume justifies it. It is a precondition of the first send, because the first send is the one creating the record everything else is judged against.

Gmail and Yahoo made this explicit in February 2024, requiring authentication, one-click unsubscribe and a complaint rate under 0.3% for anyone sending more than 5,000 messages a day to their users. You will send below that threshold for a while. It does not matter — the requirements published for bulk senders are a clear statement of what these providers value, and a small sender who ignores them is simply an unauthenticated sender who has not been noticed yet.Source · GoogleEmail sender guidelinesGoogle's published requirements for senders, including the authentication, unsubscribe and spam-rate rules that took effect for bulk senders in February 2024.support.google.com/a/answer/81126

Practically: your sending platform generates the records, you publish them at the subdomain from the first decision and you verify in the platform's own domain screen that it reports verified rather than pending. The step most often skipped is turning on signing with your own domain rather than the platform's default — it is usually one option in the sending-domain setup. Skipping it produces mail that passes its checks and still fails the one that matters. Confirm it is on before you send anything. The SPF checker will tell you whether the sender record you published is valid and within its lookup limit.

Publish DMARC at p=none with a reporting address you will actually read. Not stricter, and not without the reporting address. Both of those are the mistakes. They fail in opposite directions.

Publishing p=none with no rua address. The record exists, a checklist gets ticked and it does precisely nothing for you. The daily aggregate reports are the entire operational value of DMARC at this stage — they are how you find out that your invoicing tool, your helpdesk and an old newsletter account are all sending as your domain and none of them are aligned. Without the reports you are running blind and have confused publishing a record with having a posture.

Publishing p=reject on day one because reject sounds strongest. This instructs the world to bounce anything that fails, before you have any evidence about which of your own systems fail. The mail that stops arriving is your own — the receipt, the password reset, the invoice — and because you skipped the reporting address you have no way of telling which sender broke. This is the version of the mistake that takes a week to diagnose.

Get the record right in a few minutes with the DMARC record builder. It builds the exact TXT record, tells you where to publish it and flags the specific failures above — including the subdomain policy tag that leaves every subdomain unprotected while the record looks locked down. It runs in your browser and sends nothing anywhere.

Read the reports for a few weeks before you tighten anything. Tightening is a later decision made on evidence, not a setting you were supposed to have got right today.

The last decision, and the one that most often ruins a technically perfect setup. A new sending domain has no history, which means it has no credit to absorb a bad reaction. A complaint rate that an established sender would shrug off will define you.

Three things to settle before you press send. Everyone on the list gave you an address for this purpose — no scraped addresses, no imported contact list from someone's CRM, no addresses from a conference badge scanner. Addresses collected more than six months ago get treated as a separate, riskier group rather than mixed in. And anything you have never validated is stale enough that a chunk of it will hard-bounce, which is itself a reputation signal.

Then send small and send warm. The first campaign goes to a few hundred of your most recently active addresses, not the whole list. Watch what happens for a day. Then a larger slice, then the rest. This is not superstition — it is that a provider forming its first impression of your domain should be forming it on the mail your happiest recipients received. If you have thousands of addresses and no sending history, the warm-up mechanics apply to you even on shared infrastructure.

The dead list is the one to be honest about. Nine months of waitlist signups who have heard nothing since is not an audience, it is a group of strangers. Sending your loudest campaign to it first is the single most common way an early-stage domain gets itself into trouble.

Five lines. Run them the day before, not an hour before, so there is time for a DNS change to propagate.

The sending subdomain is the one you decided on and it is not your root domain. Your platform's domain screen says verified, not pending. Your signing is set to your own domain rather than the platform's default. The DMARC record resolves at _dmarc. plus your domain, at p=none, with a reporting address that reaches a mailbox somebody opens. Every recipient in this send gave you their address for this, and the send is your engaged slice rather than the whole list.

When one fails, the send moves. That is the entire policy. Agree on it before there is a launch date attached, because in the moment the argument is always that the deadline is fixed. The deadline being fixed has no effect on how Gmail scores your domain. A campaign delayed two days costs you two days; a first send that establishes a bad baseline costs you a quarter of worse delivery on every message, including the ones your product needs to work.

Open the DMARC builder, put in your domain, choose the monitoring stance and add a reporting address that lands in a mailbox you open. Publish the record it gives you at _dmarc.yourdomain.com. That is fifteen minutes and it is the only item on this list that starts working while you sleep — the reports begin arriving within a day or two and tell you, for the first time, everything sending mail as you.

While the record propagates, write two lines somewhere your team will find them: the sending subdomain you have chosen and the name of the person who holds DNS access. Those two lines resolve more future arguments than any amount of documentation about the records themselves.

Last, register the domain with Google Postmaster Tools, which is free, takes five minutes and is the only view you get of how Gmail actually sees you. The walkthrough covers what to look at once data starts appearing. You cannot fix what you cannot see. Until you do this the answer to "how is our deliverability" is a guess.