How I separated personal and marketing email on my domain

I recently wanted to make email on my portfolio feel a little more intentional. Instead of using a generic address everywhere, I wanted a personal address on my own domain and a separate identity for portfolio updates and marketing emails.

Then I realized I was already paying for iCloud+—and custom email domains were included.

That discovery sent me down a surprisingly interesting DNS rabbit hole. I ended up combining iCloud+ Custom Email Domain with Resend and separating the two by purpose:

mendisofficial.me
├── mendis@mendisofficial.me
│   └── personal email through iCloud Mail
│
└── updates.mendisofficial.me
    └── updates@updates.mendisofficial.me
        └── newsletters and promotional email through Resend

This post documents what I set up, what the DNS records actually do, why I moved bulk email onto a subdomain, and the practices I want to follow before sending a single campaign.

The goal

I had two different kinds of email:

personal conversations and important accounts
newsletter updates for people who subscribed through my portfolio

Those are different jobs, and using the same sending identity for both creates an unnecessary connection between them.

If a newsletter campaign generates bounces or spam complaints, mailbox providers can associate that behavior with its sending domain. I did not want a mistake in my marketing stream to affect the reputation of the domain I use for personal mail.

So the final split became:

Purpose	Address	Provider
Personal mail	`mendis@mendisofficial.me`	iCloud Mail
Newsletter and promotions	`updates@updates.mendisofficial.me`	Resend
Resend tracking	`links.updates.mendisofficial.me`	Resend

It is all still visibly part of my domain, but each system has a clearly defined boundary.

First: what DNS has to do with email

DNS is usually explained as the system that turns a domain name into a server IP address. That is true, but DNS also publishes rules about email.

When another mail server receives a message claiming to be from my domain, it can ask DNS questions such as:

Which servers receive mail for this domain?
Which services are authorized to send mail for it?
Is this message cryptographically signed?
What should happen if authentication fails?

Those answers come from a few record types.

MX: where incoming mail goes

MX stands for Mail Exchange. The MX records at the root of mendisofficial.me point incoming personal mail to iCloud Mail:

mx01.mail.icloud.com
mx02.mail.icloud.com

Resend also uses an MX record, but for a different purpose. Its record lives on send.updates.mendisofficial.me and handles the return path for bounces and complaints. Because the hostnames are different, it does not compete with the iCloud MX records at the root domain.

SPF: who is allowed to send

SPF is a TXT record that lists services authorized to send for a domain.

My root domain authorizes iCloud:

v=spf1 include:icloud.com ~all

The Resend return-path subdomain separately authorizes Amazon SES, which Resend uses underneath its delivery infrastructure:

send.updates.mendisofficial.me
v=spf1 include:amazonses.com ~all

This separation is important. A domain or hostname should not have multiple SPF records. If several services genuinely need to send from the same identity, their authorization usually belongs in one combined SPF policy. Using a dedicated subdomain avoided that problem here.

DKIM: proof that the message was signed

DKIM adds a cryptographic signature to outgoing email. The receiving server looks up the public key in DNS and checks whether the signature is valid.

iCloud and Resend each use their own DKIM selector:

sig1._domainkey.mendisofficial.me
resend._domainkey.updates.mendisofficial.me

The selectors are different, so both providers can publish their keys without overwriting one another.

DMARC: the policy tying everything together

DMARC checks whether the visible From domain aligns with authenticated SPF or DKIM. It also tells receiving servers what to do when those checks fail.

I started with a monitoring policy at the organizational domain:

_dmarc.mendisofficial.me
v=DMARC1; p=none;

p=none does not ask receivers to quarantine or reject failing messages yet. It is the cautious place to start while confirming that every legitimate sender passes authentication. After observing real delivery and adding aggregate reporting, I can gradually move toward quarantine and eventually reject.

Setting up personal mail with iCloud+

Because I already subscribed to iCloud+, I could add a domain I own from the iCloud Mail settings instead of paying for another mailbox provider.

The setup generated the records needed for:

Apple domain ownership verification
iCloud MX routing
iCloud SPF authorization
iCloud DKIM signing

After adding those records in Namecheap and completing verification, I could use an address such as mendis@mendisofficial.me from the same Mail apps I already use.

The important architectural decision was to keep these records at the root domain. mendisofficial.me remains my personal email identity.

Moving portfolio email to a Resend subdomain

I originally verified the root domain in Resend and sent from an address like:

updates@mendisofficial.me

It worked, but it mixed personal and marketing mail under the same visible sending domain. Resend recommends using a subdomain to isolate reputation by purpose, so I replaced that verified domain with:

updates.mendisofficial.me

Resend generated a new set of DNS records. Since Namecheap automatically appends the root domain to host fields, the relevant hosts were entered as:

Type	Namecheap host	Purpose
TXT	`resend._domainkey.updates`	Resend DKIM public key
MX	`send.updates`	Bounce and complaint return path
TXT	`send.updates`	SPF authorization for Resend
CNAME	`links.updates`	Branded open and click tracking

The complete names published in DNS are therefore:

resend._domainkey.updates.mendisofficial.me
send.updates.mendisofficial.me
links.updates.mendisofficial.me

After both of Namecheap's authoritative nameservers returned the new records, Resend marked the domain as verified. I then removed the obsolete root-domain Resend SPF, MX, and DKIM records while leaving every iCloud record untouched.

The application sender can now be:

Chathusha Mendis <updates@updates.mendisofficial.me>

That repetition looks slightly unusual at first, but it is valid: the mailbox name is updates, and the verified sending domain is updates.mendisofficial.me.

How the portfolio subscription flow works

My portfolio uses a small Next.js API route and the Resend SDK. When someone submits the newsletter form, the browser sends the address to /api/newsletter, and the server adds it to a Resend Audience:

const { error } = await resend.contacts.create({
  email,
  audienceId: process.env.RESEND_AUDIENCE_ID,
})

The API key and Audience ID stay in server-side environment variables. They are never exposed to the browser.

There is also an unsubscribe route. It marks the matching contact as unsubscribed instead of deleting the history:

await resend.contacts.create({
  email,
  audienceId,
  unsubscribed: true,
})

DNS authentication proves that I am authorized to send. It does not give me permission to email people. Consent and unsubscribe handling are separate—and equally important—parts of the system.

Email-sending practices I am following

Correct DNS is only the foundation. A sender can pass every authentication check and still build a poor reputation by sending unwanted or low-quality mail.

Send only to people who asked for it

Every newsletter recipient should have deliberately subscribed. I do not plan to buy lists, scrape addresses, or silently add people who contacted me for another reason.

For a larger audience, I would also consider double opt-in. It confirms ownership of the address and prevents accidental or malicious sign-ups.

Make unsubscribing easy

An unsubscribe link should be obvious, functional, and honored immediately. Trying to hide it only encourages people to use the spam button, which is much worse for sender reputation.

Handle bounces and complaints

Hard-bouncing addresses should stop receiving mail. Spam complaints should also result in suppression. Repeatedly sending to invalid or unwilling recipients is one of the fastest ways to damage deliverability.

Warm up volume gradually

A new sending subdomain has little history. I would rather start with a small, engaged list and grow consistently than send a sudden large campaign from a new identity.

Keep content and identity consistent

The display name, sending address, subject, and content should make it obvious who sent the email and why the recipient is receiving it. The new address does this well:

Chathusha Mendis <updates@updates.mendisofficial.me>

For replies, I can use a monitored personal or contact address rather than a no-reply inbox.

Test authentication—not just delivery

Seeing a message in the inbox is encouraging, but I also inspect the received headers and confirm:

SPF=PASS
DKIM=PASS
DMARC=PASS

I test with more than one mailbox provider because Gmail, Outlook, iCloud Mail, and others can make different filtering decisions.

Protect the API key

The Resend API key belongs only on the server. It should be scoped as narrowly as possible, stored in environment secrets, rotated if exposed, and never committed to Git or included in client-side JavaScript.

A migration detail that surprised me

Tracking domains deserve their own migration plan.

My old Resend domain used links.mendisofficial.me. The new sending domain uses links.updates.mendisofficial.me. Removing a Resend domain can deactivate the provider-managed proxy behind its old tracking hostname, so links in previously sent campaigns may stop resolving even if an old CNAME remains in DNS.

That is a useful lesson: DNS records and the service behind them are two different things. A CNAME can still point somewhere while the destination no longer knows how to serve that hostname.

For future migrations, I would inventory previously sent tracked links before removing the old provider configuration.

The final architecture

The result is simple and intentional:

mendisofficial.me
├── website
│   └── hosted separately from email
├── iCloud Mail
│   ├── MX at the root domain
│   ├── iCloud SPF
│   └── Apple DKIM
├── Resend
│   └── updates.mendisofficial.me
│       ├── Resend SPF
│       ├── Resend DKIM
│       └── updates@updates.mendisofficial.me
└── DMARC
    └── monitoring policy covering the domain and its subdomains

I get a personal address from a service I was already paying for, a dedicated marketing identity for my portfolio, and a cleaner boundary between two very different kinds of email.

The biggest lesson was not simply how to add DNS records. It was learning to treat email identity, authentication, consent, and reputation as parts of the same system. Once those responsibilities are separated clearly, the DNS becomes much easier to reason about—and much safer to change.