Email Domain & DNS Setup

Before you can send production email on WRNexus, your sending domain has to be verified and authenticated. That means proving you own the domain and publishing a handful of DNS records so that Gmail, Outlook, Yahoo, and every other inbox provider can confirm the mail really came from you and wasn’t forged.

This guide is written for a non-technical reader. Work through it top to bottom and you’ll finish with a verified domain and passing SPF, DKIM, and DMARC — everything you need to land in the inbox instead of the spam folder. Each step explains, in plain language, what each record does, where to add it, and how to confirm it’s working.

Why this matters. Inbox providers reject or junk unauthenticated mail automatically. Getting these records exactly right — once — is the single biggest factor in your deliverability. A single typo, a duplicated record, or a stale DKIM key is the difference between landing in the inbox and being silently dropped. We call out every one of those traps below.

What you’ll do, at a glance

1. Gather your prerequisites — own a domain, get into your DNS control panel, pick a sending subdomain, and nominate an abuse contact.
2. Verify your domain — add one TXT record so WRNexus knows you control it.
3. Publish SPF — authorise WRNexus to send on your behalf.
4. Publish DKIM — cryptographically sign your mail so it can’t be forged.
5. Publish DMARC — tell inboxes what to do with mail that fails the checks.
6. (If asked) Add MX / return-path — so bounces and replies land somewhere.
7. Verify everything passes — confirm with WRNexus and public DNS tools.
8. Start sending — connect the verified domain and go live.

Every record below is shown to you, pre-filled with the exact values, on the Senders & domains page of the WRNexus Email app. This guide explains what each one means so you can add them with confidence.

---

1. Prerequisites checklist — before you onboard

Sort these out before you add the domain in WRNexus. Having them ready makes the rest of the process a 15-minute job instead of a multi-day back-and-forth.

#	You need	Why	Tips
1	A domain you own	You can only authenticate a domain you control — e.g. yourcompany.com.	Free webmail addresses (@gmail.com, @outlook.com) cannot be used as a sending domain; you don’t control their DNS.
2	Access to your DNS control panel	Every record below is added at your DNS host (your registrar or a DNS provider like Cloudflare).	This is wherever your domain’s nameservers point. If a third party manages your DNS, loop them in now — see the per-registrar tips.
3	A chosen sending subdomain	We recommend sending from a subdomain like mail.yourcompany.com or send.yourcompany.com, not the bare root domain.	A subdomain isolates your marketing/transactional reputation from your day-to-day corporate email, so one bad campaign can’t hurt your staff inboxes. Decide the name now and use it consistently.
4	A deliverability / abuse contact	DMARC reports and complaint feedback are emailed to an address you nominate.	Use a monitored mailbox such as dmarc@yourcompany.com or abuse@yourcompany.com. It must actually receive mail — don’t point it at a black hole.
5	Admin access to the WRNexus Email app	You’ll add the domain and read back the exact DNS values to publish.	Open the Email app → Senders & domains.

Root domain vs subdomain — pick one and commit. Throughout this guide, wherever you see mail.yourcompany.com, substitute the sending subdomain you chose in row 3. If you decide to send from the root domain instead, use yourcompany.com everywhere. Mixing the two is a common cause of “verified but mail still fails” confusion.

Before moving on, confirm:

• You can log in to the control panel where this domain’s DNS records live.
• You’ve decided your sending subdomain (e.g. mail.yourcompany.com).
• Your chosen DMARC/abuse mailbox exists and receives mail.
• You can open Senders & domains in the WRNexus Email app.

---

2. Understand the records you’re about to add (60-second primer)

Five record types do five different jobs. You don’t need to memorise the syntax — WRNexus generates it for you — but knowing what each one is for makes the steps make sense:

Record	In one sentence	Record type
Domain verification	Proves to WRNexus that you control the domain.	TXT
SPF	Lists which servers are allowed to send mail for your domain.	TXT
DKIM	Adds a tamper-proof cryptographic signature to every message.	TXT (or CNAME)
DMARC	Tells inboxes what to do when SPF/DKIM fail, and where to send reports.	TXT
MX / return-path	Where bounce notifications and replies are delivered (only if required).	MX / CNAME

A piece of mail is trusted when its DKIM signature verifies and/or its SPF passes, and the sending domain aligns with the From: address — which is exactly what DMARC checks. Get SPF and DKIM right and DMARC follows.

---

3. Step 1 — Verify your domain (TXT record)

Verification proves you own the domain before WRNexus will send a single message on its behalf.

What you’ll add. In the Email app, open Senders & domains, click Add domain, and enter your sending domain (e.g. mail.yourcompany.com). WRNexus shows you a verification TXT record that looks like this:

Type	Host / Name	Value
TXT	mail.yourcompany.com (or @ for the root)	wrnexus-verification=ab12cd34ef56...

Where to add it. In your DNS control panel, create a new TXT record with that exact host and value. (See the per-registrar tips for where the “add record” button lives in your panel.)

How to confirm it. Back in Senders & domains, click Verify. WRNexus re-reads your DNS and flips the domain to Verified once it finds the token. You can also check it yourself from a terminal:

dig +short TXT mail.yourcompany.com
# look for: "wrnexus-verification=ab12cd34ef56..."

It can take a few minutes. DNS changes aren’t instant. If Verify fails on the first try, wait 5–15 minutes and try again before assuming something is wrong. See propagation timelines.

---

4. Step 2 — SPF (who is allowed to send for you)

What SPF is. SPF — Sender Policy Framework — is a public list of the mail servers permitted to send email using your domain. When an inbox receives a message claiming to be from your domain, it checks this list. If the sending server isn’t on it, the message looks forged.

The record to add. WRNexus shows you the exact value on the Senders & domains page. It looks like this:

Type	Host / Name	Value
TXT	mail.yourcompany.com (or @ for the root)	v=spf1 include:_spf.wrnexus.com ~all

• v=spf1 — marks this as an SPF record.
• include:_spf.wrnexus.com — authorises WRNexus’s sending infrastructure. This is the part that lets us send for you. Use the exact include value shown in your dashboard — don’t copy one from another provider’s guide.
• ~all — “softfail”: anything not listed is suspicious but not hard-rejected. This is the safe starting point. You can tighten it to -all (hard fail) once you’re confident every legitimate sender is listed.

The single most common SPF mistake: more than one SPF record. A domain may have exactly one SPF (v=spf1 …) TXT record. If you already send mail through another service (Google Workspace, Microsoft 365, a CRM, etc.), you must merge WRNexus into your existing SPF record — not add a second one. Merge by dropping our include: into the record you already have:

Before:  v=spf1 include:_spf.google.com ~all
After:   v=spf1 include:_spf.google.com include:_spf.wrnexus.com ~all

Watch the “too many DNS lookups” limit. SPF allows a maximum of 10 DNS lookups when it’s evaluated. Each include: (and each a: / mx:) counts toward that ceiling, and big providers’ includes can nest several more inside them. Go over 10 and your SPF returns PermError and fails for everyone — even mail that should pass. If you’re near the limit, remove includes for services you no longer use, or use SPF “flattening”. You can count your lookups with any SPF record checker.

How to confirm it.

dig +short TXT mail.yourcompany.com
# exactly one line should start with: "v=spf1 ... include:_spf.wrnexus.com ... ~all"

---

5. Step 3 — DKIM (cryptographically sign your mail)

What DKIM is. DKIM — DomainKeys Identified Mail — attaches a digital signature to every message you send. WRNexus signs with a private key that only we hold; you publish the matching public key in DNS. Inbox providers use the public key to confirm the message genuinely came from you and wasn’t altered in transit. DKIM is the strongest of the three signals.

Retrieve your key from WRNexus. On the Senders & domains page, your domain’s DKIM record is generated for you under the selector wrnexus. You’ll see one of two forms — add exactly the one shown:

• TXT form (most common):

  Type	Host / Name	Value
  TXT	wrnexus._domainkey.mail.yourcompany.com	v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…QIDAQAB

• CNAME form (if your dashboard offers it): point the selector host at a WRNexus-hosted key so the key can be rotated for you without you editing DNS again:

  Type	Host / Name	Value
  CNAME	wrnexus._domainkey.mail.yourcompany.com	wrnexus._domainkey.dkim.wrnexus.com

The selector is wrnexus. That’s why the host name starts with wrnexus._domainkey. — don’t rename it. The host is the selector plus ._domainkey. plus your sending domain.

Paste the whole value, with no edits. The DKIM public key is long. Many DNS panels (and the dig tool) display a long TXT value split into several quoted chunks of up to 255 characters each — for example "v=DKIM1; k=rsa; p=MIIB…" "…QIDAQAB". That split is normal and is not corruption; DNS reassembles the pieces automatically. Just paste the value WRNexus gives you verbatim:

• Do not add spaces or line breaks inside the p= key.
• Do not wrap it in extra quotes (your panel adds those).
• Do not truncate it — every character matters.

How to confirm it. Click Verify on the domain, or check directly:

dig +short TXT wrnexus._domainkey.mail.yourcompany.com
# should return your v=DKIM1; ... p=... key

Then send yourself a test message and view the headers — Gmail’s Show original should report DKIM: ‘PASS’ with d=mail.yourcompany.com and s=wrnexus.

⚠️ The #1 DKIM failure: a stale key after re-adding the domain

This is the single most common reason a WRNexus domain shows DKIM: FAIL even though the email is delivered, and it has bitten us before. The cause is simple:

1. You add the domain → WRNexus generates key A → you publish A in DNS.
2. Later you re-add, re-confirm, or re-run setup on the same domain → if the key is re-minted, WRNexus now signs with a new key B, but your DNS still serves the old key A → the signature no longer matches → DKIM: FAIL.

How to avoid it: publish the DKIM value once, and treat it as stable. Don’t keep an old copy from a previous setup attempt — always copy the value currently shown on Senders & domains at the moment you publish.

How to fix it if you already see dkim=fail: go back to Senders & domains, copy the DKIM record exactly as it appears right now (this is WRNexus’s current signing key), and replace the old value at wrnexus._domainkey.mail.yourcompany.com. Re-verify and send a fresh test — it should report dkim=pass. The published key and the signing key simply have to match; re-publishing the current value re-aligns them.

The CNAME form (above) sidesteps this entirely, because the key lives on WRNexus’s side and you never have to re-copy it — prefer it if your dashboard offers it.

---

6. Step 4 — DMARC (the policy that ties it together)

What DMARC is. DMARC — Domain-based Message Authentication, Reporting & Conformance — does two things: it tells inbox providers what to do with mail that fails SPF and DKIM, and it asks them to email you reports about who is sending as your domain. It’s how you find spoofers and confirm your own mail is authenticating before you turn the policy up.

Start safe with p=none. A DMARC record is a TXT record at the special host _dmarc.<your-domain>. Begin in monitor-only mode so you collect reports without risking any legitimate mail being blocked:

Type	Host / Name	Value
TXT	_dmarc.mail.yourcompany.com	v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; fo=1; adkim=r; aspf=r

• p=none — “just monitor”: don’t change how failing mail is handled, only report it. Always start here.
• rua=mailto:dmarc@yourcompany.com — where the daily aggregate reports go (your abuse contact from step 1).
• adkim=r / aspf=r — “relaxed” alignment, the right default for most senders.

Progress to enforcement — safely, in stages. Leave p=none running for 1–2 weeks and read the reports. Once they show your real mail passing SPF and/or DKIM, tighten the policy in steps. Don’t jump straight to reject:

1. p=none — monitor. Confirm your legitimate mail authenticates.
2. p=quarantine; pct=25 — send a quarter of failing mail to spam. Watch for a week; raise pct toward 100 as you gain confidence.
3. p=quarantine (full) — all failing mail to spam.
4. p=reject — outright reject forged mail. The end goal, only after weeks of clean reports.

Don’t skip the staircase. Jumping to p=reject before your own mail reliably passes will cause inbox providers to reject your legitimate email. Move up one rung at a time and let the reports guide you.

How to confirm it.

dig +short TXT _dmarc.mail.yourcompany.com
# should return your v=DMARC1; p=none; ... record

---

7. Step 5 — MX and return-path / bounce (only if WRNexus asks)

Most senders do not need an MX record to send — MX records are for receiving mail. Add the records in this section only if the Senders & domains page explicitly shows them for your domain.

Return-path / bounce CNAME. When a message can’t be delivered, the receiving server sends a bounce back to the envelope address (the “return-path”). For those bounces to be processed — and for the return-path to align with your domain so it strengthens DMARC — WRNexus may ask you to add a CNAME that points a bounce subdomain at our infrastructure:

Type	Host / Name	Value
CNAME	bounce.mail.yourcompany.com	bounce.wrnexus.com

This lets bounce notifications flow back to WRNexus so failing addresses are automatically suppressed — which keeps your reputation clean.

MX record (only if shown). If your plan delivers replies or bounces to a mailbox on your sending domain, WRNexus will show an MX record to add:

Type	Host / Name	Priority	Value
MX	mail.yourcompany.com	10	mx.wrnexus.com

If the page doesn’t show MX or a bounce CNAME, you don’t need them. A pure outbound sending domain works with just verification + SPF + DKIM + DMARC. Only add what your dashboard lists for your specific setup.

---

8. Per-registrar quick tips — where records live

The records are identical everywhere; only the buttons differ. Here’s where to add a DNS record in the most common control panels.

A note on host names. Some panels want the full host (wrnexus._domainkey.mail.yourcompany.com); others want only the part before your domain (wrnexus._domainkey.mail) and append the domain for you. If a panel auto-appends your domain and you paste the full host, you’ll end up with a doubled name like …mail.yourcompany.com.yourcompany.com. When in doubt, enter the short form and check the preview the panel shows you.

Registrar / DNS host	Where DNS records live	Quirks to watch
GoDaddy	My Products → Domain → DNS → Manage DNS → Add	Use @ for the root domain. Enter host names without your domain (GoDaddy appends it). TTL “1 Hour” is fine.
Cloudflare	Your domain → DNS → Records → Add record	For TXT/CNAME, set the proxy status to DNS only (grey cloud) — orange-cloud proxying does not apply to these records. Cloudflare accepts the full host name.
Namecheap	Domain List → Manage → Advanced DNS → Add New Record	Use @ for the root. In the Host field enter only the subdomain part (e.g. wrnexus._domainkey.mail); Namecheap appends the domain.
AWS Route 53	Hosted zones → your zone → Create record	Enter the full record name. For TXT values, wrap the string in double quotes. Choose Simple routing.

Different DNS host than registrar? If your domain’s nameservers point to a third party (e.g. you bought the domain at GoDaddy but use Cloudflare for DNS), add the records at the DNS host the nameservers point to, not at the registrar. Check your nameservers with dig +short NS yourcompany.com.

---

9. How to verify everything passes

Once all the records are published, confirm them two ways.

1. In WRNexus. On Senders & domains, click Verify. The domain moves to Verified / Authenticated once SPF and DKIM both resolve correctly. This is the gate — your domain becomes sendable only when these pass.

2. With public tools. Cross-check against the wider internet using any of:

• MXToolbox — run SPF Record Lookup, DKIM Lookup (selector wrnexus), and DMARC Lookup for your domain. Each returns a green pass/fail and, for SPF, your DNS lookup count.

• A test message. Send an email to a Gmail account, open it, choose Show original, and confirm all three lines read PASS:

  SPF:   PASS  with domain mail.yourcompany.com
  DKIM:  PASS  with domain mail.yourcompany.com (selector wrnexus)
  DMARC: PASS

• Command line. The dig commands shown in each step above let you read back exactly what’s published.

Common mistakes & rejection causes. If verification won’t pass, it’s almost always one of these:

Symptom	Likely cause	Fix
DKIM: FAIL but mail is delivered	Published key no longer matches WRNexus’s current signing key (stale key after a re-add).	Re-copy the DKIM value currently shown on Senders & domains and replace the old one. See §5.
SPF PermError / “too many lookups”	More than 10 DNS lookups across your include:s.	Remove unused includes or flatten SPF. See §4.
Two SPF records	A second v=spf1 TXT was added instead of merging.	Keep one SPF record; merge all include:s into it.
DKIM/SPF value altered	Spaces, line breaks, or extra quotes were inserted when pasting.	Re-paste the value verbatim; let the panel add its own quotes.
Host name doubled	Full host pasted into a panel that auto-appends the domain.	Use the short host form (e.g. wrnexus._domainkey.mail).
Record added at the wrong place	Published at the registrar while DNS is hosted elsewhere.	Add records at the host your nameservers point to.
Verified, then broke	DKIM key was regenerated after publishing.	Republish the current key; don’t re-mint once it’s live.
DMARC blocking your own mail	Jumped to p=reject before mail was passing.	Drop back to p=none, fix SPF/DKIM, then climb the staircase.

---

10. Propagation timelines — what to expect

DNS changes are not instant. They spread across the internet on a schedule set by each record’s TTL (time-to-live):

• Typical: new records are visible within 5–30 minutes.
• Worst case: up to 24–48 hours for full global propagation, especially if your old TTL was set high.
• WRNexus “Verify” reads live DNS each time you click it — so if it fails, wait a little and retry rather than re-editing a record that’s already correct.

Don’t thrash the records. Editing and re-saving a DNS record resets its propagation clock and can briefly make a correct record look broken. Publish once, wait, then verify.

---

11. You’re verified — now start sending

Once Senders & domains shows your domain Verified / Authenticated and your test message reports SPF, DKIM, and DMARC all PASS, you’re ready to send production email.

Next steps

• Getting started — create your WRNexus account and workspace if you haven’t already.
• Configuration overview — onboarding for every channel.
• Email API — send transactional and campaign email over HTTP from your verified domain.
• Email SDK — official JavaScript, Python, Go, Java, and Rust clients.
• Email Webhooks — receive delivery, bounce, open, and complaint events in real time.