> ## Documentation Index > Fetch the complete documentation index at: https://notifizz.com/llms.txt > Use this file to discover all available pages before exploring further. # Sending Domain — Prove the Mail Is Yours > Authenticate the domain your emails leave from: the DNS records to publish, what Notifizz verifies for you, what breaks while it is not done, and what happens if the records later disappear. # Sending domain Every email Notifizz sends on your behalf carries **your** domain in the `From` address. Mailbox providers will not take that claim on trust: they check that the domain's owner authorised the sender. Publishing a handful of DNS records is how you give that authorisation — and it is the single setup step that most decides whether your mail reaches an inbox. **Mostly a Dev / IT task, with a Marketing consequence.** Someone with access to your DNS zone publishes three records, once. Until that is done, no real email leaves for your recipients — which is why it belongs on the launch checklist, not in a backlog. ## TL;DR * Add your domain in **Settings → Email → Domains**. Notifizz generates the records; you publish them at your DNS provider. * **Two records decide verification**: a DKIM `TXT` (signs your mail) and a return-path `CNAME` (routes bounces and aligns the envelope sender). An SPF `TXT` is offered as **recommended**, not required. * **Verification is automatic.** Notifizz re-checks continuously and flips the domain to *Verified* on its own; the screen also refreshes while you watch it. * **A `From` address can only exist on a verified domain.** No verified domain and no default sender means no real send — the attempt is recorded as a failure, not silently dropped. * **Verification is not permanent.** A domain whose records are later changed or removed regresses to *Error*, and that regression is raised on the Reputation page. * Once verified, your domain is also **scanned against the major anti-spam blocklists** several times a day. ## Choose the domain Use a **dedicated subdomain** — `mail.example.com`, `send.example.com`, `notifications.example.com`. The dashboard recommends exactly this, for one reason: reputation is built per sending domain. A subdomain isolates your notification traffic from the domain your team uses for ordinary correspondence, so a bad campaign week never becomes a problem for your sales mail. Sending from your root domain works too. It is simply a bigger blast radius for the same mistake. Pick the domain before your first campaign, not after. Reputation is earned by a domain over time, and moving to a different sending domain later starts that clock from zero — including the [gentle pacing regime](/docs/concepts/broadcasts#pacing) applied to domains verified less than fourteen days ago. ## Add it and publish the records **Settings → Email → Domains → Add a sending domain**. Enter the hostname (`mail.example.com`). Notifizz registers it and immediately shows the records to publish, grouped by purpose. Three rows, each with a **Name**, a **Type** and a **Content** value, with a copy button on each. Publish them in the zone that hosts your domain. | Purpose | Type | Required? | What it does | | --------------- | ------- | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **DKIM** | `TXT` | Required | Publishes the public key your messages are signed with. This is the signature a receiver verifies to know the mail is really from you. | | **Return-Path** | `CNAME` | Required | Points the envelope sender at a host under your domain, so bounces and error reports come back through a path that belongs to you — and so SPF is evaluated against your domain rather than an unrelated one. | | **SPF** | `TXT` | Recommended | Lists the servers allowed to send for the host. Your mail already authenticates through DKIM and the return-path, which are the two providers actually check; SPF mainly makes your setup legible to auditing tools. | **One-click placement, when your provider supports it.** If your DNS provider implements the Domain Connect standard, the panel offers a *Connect DNS automatically* button that publishes the records for you in one authorised redirect. If the button is not there, publish them by hand — that is the normal path and it takes the same two minutes. Nothing else is required. The panel re-reads the state every ten seconds while it is open, and the platform re-checks every domain in the background on its own schedule. There is also a **Verify records** button if you would rather not wait for the next pass. DNS propagation is the only real delay — usually minutes, occasionally longer depending on your provider and the TTL you set. Once the domain reads **Verified**, add the senders you will send from — a local part (`hello`, `notifications`, `news`) and a display name. The address is composed server-side as `local@your-domain`, so a sender can never be attached to a domain you have not authenticated. The first sender you add becomes the **default** — the `From` campaigns use unless one is chosen explicitly on the email itself. You can promote any other sender to default later. ## The three statuses | Status | Meaning | What you do | | ------------ | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | **Pending** | The domain is registered, one or both required records are not visible in DNS yet. | Publish the records, or wait for propagation. | | **Verified** | DKIM and return-path both check out. Senders can be created; real mail can go out. | Nothing. | | **Error** | The domain **was** verified and no longer authenticates — records changed or removed. | Restore the records. Until then, treat your delivery as degraded. | The distinction between *Pending* and *Error* is deliberate. *Pending* is a setup that has not finished; *Error* is a setup that broke. Only the second one is an incident, and only the second one is raised on the Reputation page as an authentication drift. ## Why SPF behaves differently from the other two SPF is the one record Notifizz resolves against live DNS itself rather than trusting a status flag. That produces three cases the other records never show: * **Nothing published** — the row stays amber, and nothing is blocked. Your mail still authenticates through DKIM and the return-path. * **An SPF record already exists and does not cover us** — flagged as a conflict, with the value already published shown next to it. Only one `v=spf1` record is allowed per name, so the fix is to **merge** the two values into one, never to add a second line. * **Several SPF records already published** — flagged as invalid. SPF is already failing for everything that host sends, independently of Notifizz. Merge them into a single record. Notifizz never edits an existing SPF record for you, and never guesses at somebody else's SPF tree — a wrong merge would de-authorise a mail server you rely on. The suggested value is also trimmed of the `a` and `mx` mechanisms when the host has neither, so you are not asked to publish terms that authorise nothing. ## What is blocked while the domain is not verified Being explicit about this saves a launch day. * **You cannot create a `From` address.** Senders are refused on any domain that is not verified. * **Any campaign using the email channel carries an implementation task** — *Configure the email sending domain* — visible in its panel and executable from your IDE. It is satisfied when a default sender exists **and** its domain is verified. * **That task does not block the move to Review.** Review does not send real mail to your audience anyway: it reaches only your organisation's verified sandbox addresses. See [send scope](/docs/concepts/campaigns#send-scope). * **It does block anything real.** A live send with no usable sender is recorded against the message as a delivery failure (`no_sender_configured`), visible in [delivery history](/docs/operations/delivery-history-and-stats). Nothing is silently discarded — but nothing arrives either. * **Broadcasts launched without a verified domain on record are paced gently**, on the assumption that an unproven domain is a young one. ## After verification: it keeps being checked Verification is a state, not a certificate. Notifizz re-checks every domain that can still change — *pending* ones, which may verify, and *verified* ones, which may break. A previously verified domain that stops authenticating flips to **Error**, and that transition surfaces as *Authentication DNS records degraded* on **Settings → Email → Reputation**. This matters more than it sounds: nothing in DNS tells you when a record is removed, and the symptom otherwise arrives as a slow, unexplained slide in delivery. Verified domains are also **scanned against the major anti-spam URI blocklists** several times a day. A listing shows on the Reputation page with the list that carries it, so you learn about it in hours rather than through a week of quietly degrading delivery. See [deliverability](/docs/operations/deliverability) for what the platform does with those signals. ## Removing a domain Removing a sending domain removes the senders attached to it — they cannot exist without it. If the default sender was one of them, the oldest remaining sender is promoted to default automatically, so your organisation is never left with senders but no default. ## FAQ Notifizz does not generate one for you, and it is not part of what gets verified here. It is still worth publishing on your own: DMARC is what tells receivers how to treat mail that fails authentication in your name, and Gmail reports your DMARC pass rate on real traffic once your domain is linked to [Postmaster Tools](/docs/operations/gmail-postmaster). Start in monitoring mode. Three usual causes. **Propagation** — give it time proportional to the TTL you set. **Wrong record type** — DKIM is a `TXT` record and the return-path is a `CNAME`; some DNS interfaces silently coerce one into the other. **Zone mismatch** — the record must be published in the zone that actually serves the subdomain, which is not always the zone you edited. Query the exact name from an external resolver to see what the world sees. Yes, and it is the usual setup — but they are two different records and two different screens. This page authenticates the domain your mail *comes from*; a [custom tracking domain](/docs/operations/tracking-domain) changes the domain *inside* the email body. Neither improves the other. Yes. Add as many as you need; each has its own records, its own status and its own senders. Pacing for a broadcast looks at your **oldest** verified domain, so adding a fresh domain does not push an established account back into the cautious regime. Sends are still attempted, but they are no longer authenticated the way receivers expect, so a growing share will be filtered or rejected. Treat it as an outage: restore the records first, then check the per-provider bounce counts on the Reputation page to see how much of the last few days was affected. Not today. Notifizz sends through its own infrastructure so that authentication, feedback handling and reputation monitoring are one coherent system rather than your responsibility. ## See also Every lever that decides inbox placement, and what the platform watches on your behalf. Your own domain on the links, images and pixels inside the email. Authentication rates measured on real mail, straight from Google. Per-message outcomes, including the reason a send failed.