Put your first website and email online

Five connected jobs, not one product

The domain is the public name. DNS is the routing directory. Hosting stores or runs the website. The website is the content or application people use. Email is a separate service that may share the domain while using different DNS records.

One company may supply several layers, but they remain separate responsibilities. Moving a website does not automatically move email; changing nameservers can move control of the entire DNS zone.

• Domain registrar
• DNS manager
• Website host
• Email provider
• Technical owner and renewal owner

Draw the route before touching settings

For the website, trace visitor → domain → DNS → host → website. For email, trace sender → domain DNS → mail provider → mailbox. Mark every unknown instead of guessing from the logo shown in one control panel.

Record the current nameservers and important records before a change. This simple baseline is the recovery map if the website or email later stops working.

Find the authoritative control point

The active nameservers determine where the DNS zone is managed. A domain purchased at one registrar may use DNS somewhere else, so editing the wrong dashboard produces no public change.

Connecting by nameservers transfers control of the DNS zone. Connecting with selected A, AAAA or CNAME records changes only named destinations. Follow the exact destination supplied by the hosting platform and preserve unrelated mail, verification and service records.

• Current nameservers
• Existing DNS export or screenshot
• Required destination
• Records that must remain
• Rollback owner

Expect propagation; verify instead of repeatedly editing

DNS changes can take time to appear across resolvers. Repeated changes during propagation make diagnosis harder. Record the time, old value, new value and expected result, then check authoritative and public responses.

Do not delete an old record merely because a new tutorial shows a different example. First identify whether it supports the website, email, certificate, verification or another live service.

Website routing records

An A record points a name to an IPv4 address; AAAA is the IPv6 equivalent. A CNAME makes one hostname an alias of another hostname. The root domain and the www hostname may use different record patterns depending on the platform.

Conflicting root or www records can send visitors to different destinations. Wildcards also affect undefined subdomains, so they should be reviewed before adding a named application or verification record.

• Root record
• www record
• IPv4 and IPv6 destinations
• Wildcard records
• TTL and intended change window

Email, verification and security records

MX records select mail receivers. TXT records are commonly used for SPF, DMARC and ownership verification; DKIM may appear through TXT or CNAME depending on the provider. CAA can restrict which certificate authorities may issue for the domain.

Copy values from the current service's official setup screen. A generic value from a blog or old account can look valid while authenticating the wrong service.

Receiving and authentication are different checks

MX records tell other mail systems where to deliver messages. SPF describes authorised senders, DKIM provides a cryptographic signature and DMARC states how receivers should handle authentication failures and where reports may be sent.

Creating an inbox in a control panel is not enough when the domain still points mail elsewhere. Use the provider's current Connect Domain values and change them only in the authoritative DNS zone.

• Mailbox exists
• MX accepted
• SPF present without conflicting duplicates
• DKIM verified
• DMARC policy understood

Test like a recipient

Send from the new mailbox to an unrelated provider and reply back. Check inbox and spam placement, From name, reply address and authentication results. A successful send to another mailbox at the same provider does not prove public delivery.

Record the account recovery owner and renewal boundary. Mailbox passwords, app passwords and reset links must never appear in a public tutorial screenshot.

Choose the operating responsibility you can support

A managed website builder or shared hosting plan handles more platform work; a VPS gives broader control while making the owner responsible for operating-system updates, services, firewall, backups and incident response. Select the smallest platform that meets the website's actual requirements.

Before publishing, record the site source, data store, public domain, deployment owner and rollback method. Do not edit an unstable application directly on the production server when a versioned deployment is available.

• Website source
• Hosting destination
• Database and uploads
• Deployment owner
• Backup and rollback

HTTPS is a testable outcome

After DNS reaches the correct host, confirm the certificate covers the intended domain and subdomains. Verify HTTP redirects to the chosen HTTPS address and that the page does not load scripts, images or styles through insecure URLs.

Test the homepage, one internal page, a form and a missing page on phone and desktop. A green lock does not prove the application, email or data path works; it proves only the browser connection for that hostname.

A VPS is a server, not a faster website button

Use a VPS when the application needs operating-system control, custom services, containers, background workers or resources that managed hosting cannot provide. The owner must maintain updates, firewall rules, service health, logs, storage and access.

Begin with a non-root application account where practical, SSH keys, a narrow public-port plan and documented emergency access. Never remove the only known working access path until the replacement has been tested.

• Named administrator
• SSH key access
• Public ports
• Update routine
• Monitoring and incident owner

Backups need a restoration boundary

Know what a provider snapshot or backup contains, how long it is retained and what restoration overwrites. Preserve application data separately when the recovery-point requirement is tighter than the server snapshot schedule.

Before a risky deployment, identify the exact revision, migration state, health check and rollback trigger. A backup label is not proof of recoverability until the restoration scope and a safe test are understood.