How to send a newsletter from your own domain

Why does sending from your own domain matter?

Two reasons: trust and ownership. A newsletter from news@yourbusiness.co.nz is recognisably yours in the inbox. One from a platform’s shared domain is recognisably somebody else’s software, and readers treat it accordingly.

The second reason matters more over time. Deliverability is reputation-based: mailbox providers decide where your mail lands partly on the history of the domain it came from. On a shared sending domain that history is pooled, so another customer’s bad list can affect whether your mail reaches the inbox. On your own domain, the reputation you build is yours, and so is the damage if you are careless with it.

There is a third reason that only becomes visible when you leave. A list built on someone else’s domain has been training mailbox providers to trust that domain, not yours. Move platforms and you start from zero. Build on your own domain and the reputation comes with you.

What are DKIM, SPF and DMARC?

They are three DNS records that together let a receiving mail server answer one question: is this message really from the domain it claims to be from?

SPF is a list of who is allowed to send email on behalf of your domain. It is a TXT record naming the sending services you use. If mail arrives from somewhere not on the list, that is a signal.

DKIM is a cryptographic signature. Your sending service signs each message with a private key, and publishes the matching public key in your DNS, so a receiver can verify that the message was signed by someone holding your key and has not been altered in transit.

DMARC ties the two together and tells receivers what to do when a message fails both: do nothing (p=none, monitor only), quarantine it to spam, or reject it outright. It also asks receivers to send you reports, which is how you find out that something is sending as you.

The word that trips people up is alignment. It is not enough for SPF or DKIM to pass; the domain that passed has to match the domain in the From line the reader sees. A message signed by a platform’s own domain passes DKIM but fails DMARC alignment for yours. That is why a platform that sends "on your behalf" from its own domain cannot give you the benefit of your own reputation, and why the records below are set up on your domain, not theirs.

How do you set them up?

Your sending platform generates the records; you add them wherever your DNS is hosted, which for most New Zealand businesses is the registrar or the web host. Brieva shows you exactly what to add and then checks for you.

DKIM is usually three CNAME records. The custom MAIL FROM subdomain needs an MX record and its own SPF TXT record. If you already send email from the domain, for example through Microsoft 365 or Google Workspace, you must add the new sender to your existing SPF record rather than creating a second one: a domain with two SPF records is treated as having none.

That last mistake is common and it is silent. Everything looks fine until deliverability quietly degrades. If you already have an SPF record, edit it; never add another.

Once the records are live, verification typically completes within an hour, though DNS changes can take longer to propagate depending on your TTL.

A worked example: the records for one domain

Suppose the business is Harbour Plumbing, the website is harbourplumbing.co.nz, and the newsletter will send from news@harbourplumbing.co.nz. The business already uses Microsoft 365 for ordinary email. Here is what ends up in DNS.

DKIM: three CNAME records with names like abc123._domainkey.harbourplumbing.co.nz, each pointing at a matching name on the sending platform. The platform generates the three random names; you copy them exactly. These are what let receivers verify the signature on every newsletter.

A MAIL FROM subdomain: an MX record on mail.harbourplumbing.co.nz pointing at the platform’s bounce handler, and a TXT record on the same subdomain reading v=spf1 include:amazonses.com ~all. This is where bounces are returned to, and having it on a subdomain keeps newsletter bounces separate from the business’s ordinary email.

SPF on the main domain: the business already has v=spf1 include:spf.protection.outlook.com -all for Microsoft 365. Because the newsletter uses its own MAIL FROM subdomain, the main-domain SPF record does not need to change. If the platform had asked you to send from the bare domain, you would edit that one record to add a second include, and you would not add a second record.

DMARC: a TXT record on _dmarc.harbourplumbing.co.nz, starting at v=DMARC1; p=none; rua=mailto:dmarc@harbourplumbing.co.nz. That is the monitoring stage. Nothing changes about how mail is delivered yet; you just start receiving reports.

Total: five or six records, all copy-and-paste, added in the registrar’s DNS panel. Twenty minutes, most of it finding the login.

Should DMARC be set to reject?

Not on day one. Start at p=none, which monitors without changing how anything is delivered, and read the reports for a few weeks. You will almost certainly discover a legitimate sender you had forgotten: an invoicing system, a booking tool, a CRM.

Once every legitimate sender passes, move to p=quarantine, and later to p=reject if you want the strongest protection against someone spoofing your domain. Going straight to reject with an incomplete SPF record is how businesses accidentally stop their own invoices from being delivered.

A sensible timeline for a small business: p=none for the first month, p=quarantine with pct=100 once a month of reports shows only your own senders, and p=reject after another month if nothing has broken. There is no prize for getting to reject quickly, and a real cost to getting there before Xero, your booking system and your accountant’s software have all been added.

How do you read a DMARC report?

Aggregate reports arrive daily as XML attachments from every mailbox provider that received your mail. Raw, they are unreadable. Paste one into any free DMARC report viewer and you get a table: for each sending IP, how many messages, whether SPF passed, whether DKIM passed, and whether each aligned with your domain.

What you are looking for is rows that fail. A failing row from an IP you recognise (your email provider, your invoicing tool) means that sender is not in your SPF record or is not signing with your DKIM key; fix the record. A failing row from an IP you do not recognise, sending a handful of messages, is usually someone forwarding your mail, which breaks SPF and is harmless. A failing row from an IP you do not recognise sending thousands of messages is someone spoofing your domain, and it is the reason you set DMARC up.

You do not need to read these every day. Once a fortnight for the first two months, then whenever you add a new system that sends email, is enough.

What actually damages sending reputation?

Bounces and complaints, in that order of frequency and reverse order of severity.

A bounce is mail to an address that does not exist. A high bounce rate tells a mailbox provider you are sending to a list you did not collect properly, because a list built from real sign-ups does not contain many dead addresses. AWS, whose infrastructure Brieva sends on, expects bounce rates below 5%, and will review an account above that.

A complaint is someone marking your message as spam. Complaints are far rarer and far more damaging: the threshold that matters is a fraction of a percent. AWS expects complaint rates below 0.1%.

Brieva enforces tighter limits than that, per newsletter. It warns at 3% bounce or 0.05% complaint, and automatically pauses sending at 5% bounce or 0.08% complaint, so one bad list cannot take down your domain’s reputation before anyone notices.

Engagement matters too, in a way that is harder to measure. Gmail in particular watches whether recipients open, reply to, and move your mail. A newsletter that is consistently opened by most of its list builds a reputation that survives the occasional bounce. One that is ignored by most of its list is quietly demoted to the promotions tab, then to spam, without a single complaint being filed. Keeping the list small and engaged is a deliverability strategy, not just a content one.

How do you keep the bounce rate low?

Never buy or rent a list. Every address on a purchased list is either dead, a spam trap, or belongs to someone who will complain. It is not a shortcut with a downside; it is the single fastest way to destroy a sending domain.

Use double opt-in so a mistyped address never enters the list in the first place. Suppress hard bounces permanently and immediately, rather than retrying them. Remove addresses that have not opened anything in a year: they are more likely to be abandoned accounts, and abandoned accounts sometimes become spam traps.

And send regularly. A list that hears from you every fortnight decays slowly. One that hears from you after eighteen months of silence will bounce and complain heavily, because nobody remembers subscribing.

Brieva does the mechanical parts of this automatically: every sign-up is double opt-in, a hard bounce removes the address on the spot, and a spam complaint unsubscribes the reader before the next issue. What it cannot do is stop you sending to a list you should not have; that part is on you.

What does a one-click unsubscribe require?

Gmail and Yahoo both require bulk senders to support one-click unsubscribe, which means two specific headers on every message: List-Unsubscribe with a URL, and List-Unsubscribe-Post signalling that a single POST is enough. The unsubscribe must take effect without asking the person to log in or confirm.

This is also the cheapest deliverability protection available. A reader who cannot find the unsubscribe link marks the message as spam instead, and a complaint costs you far more than a lost subscriber. Make it easy to leave.

Brieva sets both headers on every message and includes a visible unsubscribe link in the footer, and unsubscribes take effect immediately.

The same providers also expect a valid reverse DNS record on the sending IP, TLS on the connection, and a spam rate under 0.3% as measured by Gmail’s own tools. On a managed platform the first two are handled for you. The third is, again, about the list.

How do you warm up a new sending domain?

Gently. A domain with no sending history that suddenly emits ten thousand messages looks exactly like a compromised domain, and will be treated as one.

Start with your most engaged subscribers, the ones who asked for it most recently, and grow volume over a couple of weeks. If you are migrating an existing list, send to the people who have opened something recently first, and leave the long tail until the domain has a track record.

For a list under a thousand this is mostly academic: the volumes are too small to alarm anyone. For a list of ten thousand moving from another platform, split the first three issues by engagement (opened in the last 30 days, then 90, then everyone) and let each go out a few days apart. It costs nothing and it avoids the one scenario that can put a new domain on a blocklist in its first week.

What if you move email providers later?

Your ordinary business email and your newsletter are independent as long as they are set up as described above. Moving the business from Google Workspace to Microsoft 365, or the other way, means replacing the include in the main-domain SPF record and the provider’s DKIM records. The newsletter’s DKIM and MAIL FROM records are untouched.

The one thing to check after any provider move is the DMARC reports for the following week. If the new provider is signing correctly you will see it pass; if you forgot a record you will see it fail, and because you are at p=none or p=quarantine rather than reject, the cost of the mistake is a few days in spam folders rather than lost mail.

Which address should the newsletter come from?

A real one, on your domain, that a person reads. news@, hello@ and the owner’s first name all work; noreply@ does not. Readers reply to newsletters, and those replies are the best feedback and sometimes the best leads the newsletter produces. A no-reply address throws them away and tells the reader you are not interested.

Use a subdomain only if you have a reason. Some larger senders put newsletters on news.example.co.nz so that a deliverability problem with the newsletter cannot affect ordinary business email. For a small business with a clean list, the bare domain is simpler and the reputation benefit accrues to the domain customers already know. If you do use a subdomain, it needs its own DKIM, MAIL FROM and DMARC records; DMARC on the parent domain applies to subdomains by default, but the others do not.

Whatever you choose, keep it stable. Mailbox providers build reputation per sending address as well as per domain, and readers build recognition. Changing the from address every few months resets both.

Why does the free tier send from brieva.news?

Because a new business trying the product should not have to touch DNS to find out whether it is useful. On the free tier every issue goes from issues@brieva.news with your newsletter’s name as the display name, and replies go to the address you set. The reputation of that sending domain is protected by the same bounce and complaint limits described above, applied per newsletter, so one customer’s bad list cannot degrade it for everyone.

The trade-off is the one described at the top of this guide: the reputation you build on brieva.news is not portable, and the from line says brieva.news in the small print. That is fine for a trial and a small list. When the list is one you intend to keep, move to your own domain, which every paid plan includes. Your DNS records are set up once; if you later drop back to the free tier, Brieva falls back to brieva.news automatically and resumes your domain when you upgrade again, with no DNS changes.

Troubleshooting: the six things that usually go wrong

Verification never completes. Almost always a typo in a CNAME, or the record was added to the wrong zone (the www subdomain instead of the root, or a parked duplicate of the domain at another registrar). Check each record with a public DNS lookup tool rather than trusting the control panel.

Mail lands in spam at Gmail but not Outlook, or the other way round. Usually a DMARC alignment problem: SPF or DKIM passes but on a different domain from the From line. The DMARC report will show which. Fix the record; do not "warm up" your way past it.

Everything passes but the first issue still goes to spam for some readers. Normal for a brand-new sending domain with no history. It clears with a few issues that people open. Ask your first subscribers to reply to the first issue; replies are the strongest positive signal a mailbox provider sees.

Bounce rate jumps on one issue. Look at the addresses. A cluster from one company domain usually means that company changed email providers or its staff moved on; suppress them. A scatter of random-looking addresses means someone tested your sign-up form with fake entries, which double opt-in should have stopped; check the form is actually the Brieva one and not a copy without confirmation.

Your own ordinary email starts bouncing after you change SPF. You added a second SPF record instead of editing the existing one, or you set DMARC to reject before adding your email provider to SPF. Revert, then fix.

A reader says they unsubscribed and still got the next issue. Check when: an unsubscribe after the send started will not stop that issue. If it was before, look at whether they are on the list twice under different addresses; the second address is still subscribed and they do not remember it.

A checklist

Before the first issue from your own domain: DKIM records added and verified. MAIL FROM subdomain MX and SPF added and verified. Main-domain SPF record checked: exactly one record, and it includes every service that sends as you. DMARC record at p=none with a reporting address you will actually read. Sign-up form live with double opt-in. Unsubscribe link visible in the footer and one-click headers present (Brieva does this; check any other tool you use).

After the first month: read the DMARC reports. Add any legitimate sender that is failing. Move to p=quarantine. Look at bounce and complaint rates per issue; anything above 1% bounce on a double opt-in list means something is wrong with the form or someone is testing it with fake addresses.

After three months: consider p=reject. Remove subscribers who have not opened anything since they joined. Keep the send day and time you have; readers have built a habit around it by now.