Skip to main content

​
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 applied to domains verified less than fourteen days ago.

​
Add it and publish the records

1

Add the domain

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.
2

Publish the records at your DNS provider

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.
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.
3

Let verification happen

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.
4

Add your From addresses

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

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.
  • 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. 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 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. 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. 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

Deliverability

Every lever that decides inbox placement, and what the platform watches on your behalf.

Tracking domain

Your own domain on the links, images and pixels inside the email.

What Gmail sees

Authentication rates measured on real mail, straight from Google.

Delivery history

Per-message outcomes, including the reason a send failed.