Set Up Professional Business Email With Your Domain

Why a Professional Business Email Matters

When a potential customer receives a message from contact@yourbusiness.co.uk rather than yourbusiness2024@gmail.com, they immediately perceive your company as more established. Research consistently shows consumers are more likely to open and respond to emails sent from branded domains.

A custom domain email gives you full control over mailboxes, aliases, and routing. If you ever switch hosting or email platforms, your address remains the same because you own the domain. Brand consistency across your website, business cards, invoices, and email signatures builds trust at every touchpoint.

Choosing Your Email Platform

Google Workspace starts at around five pounds per user per month, including Gmail with your custom domain, Google Drive, Docs, and Meet. Microsoft 365 offers Outlook with your domain, OneDrive, and the full Office suite, ideal for businesses needing advanced calendar sharing and desktop app integration.

cPanel email hosting is included with all BearHost packages at no additional cost. It supports IMAP and POP3, provides webmail through Roundcube, and gives you full control over mailboxes, forwarders, and autoresponders. If you simply need reliable email without per-user fees, cPanel email delivers everything you need.

DNS Records: MX, SPF, DKIM, and DMARC

MX records tell other mail servers where to deliver email for your domain. SPF specifies which servers are authorised to send on your behalf, preventing spammers from forging your domain. DKIM adds a digital signature to every outgoing email proving it has not been tampered with in transit.

DMARC ties SPF and DKIM together by telling receiving servers what to do when authentication fails. Misconfigured or missing records are the most common reason legitimate emails land in spam. BearHost automatically configures MX and SPF records for cPanel accounts and provides guides for DKIM and DMARC setup.

Step-by-Step Setup and Device Configuration

For cPanel email on BearHost, log in to your dashboard, navigate to Email Accounts, enter your desired address, set a strong password, and click Create — Knowledge Base Email How To Create Professional Email Account has the click-through. For Google Workspace or Microsoft 365, sign up, verify domain ownership via a DNS TXT record, then update your MX records to point to their mail servers. Always enable two-factor authentication immediately.

For desktop clients like Outlook or Thunderbird, use IMAP port 993 with SSL for incoming mail and SMTP port 465 with SSL for outgoing. BearHost cPanel includes an auto-configuration tool for popular clients. On mobile, iOS and Android built-in mail apps support manual IMAP configuration, while Google Workspace and Microsoft 365 offer dedicated apps with automatic setup.

Best Practices and BearHost Email Features

Create strategic addresses like info@, support@, and sales@ for different enquiry types. Use aliases and forwarders to route multiple addresses to a single inbox. Set up professional email signatures with your name, title, phone number, and website, keeping them clean to avoid triggering spam filters.

BearHost includes email hosting with every plan featuring unlimited accounts, generous storage, SSL/TLS encryption, and SpamAssassin spam filtering. For businesses using Google Workspace or Microsoft 365, our DNS management tools make it easy to configure all required records while keeping your website hosted with BearHost.

SPF Syntax Deep-Dive: The 10-Lookup Limit and Flattening

SPF records look deceptively simple but contain one rule that trips up almost everyone: RFC 7208 section 4.6.4 caps the total number of DNS lookups at 10 per evaluation. Each `include:`, `a:`, `mx:`, `exists:`, `redirect`, and `ptr` mechanism counts toward that limit, and every nested include recursively counts too.

A typical record like `v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org include:_spf.mcsv.net ~all` already consumes around 8 lookups because each included record contains its own `include:` entries. One more marketing tool and the record becomes "permerror" in DMARC reports, silently breaking delivery.

The fix is SPF flattening. Services like dmarcian, EasyDMARC, and Valimail resolve all your nested lookups into a single record of static IP ranges, which you then publish as one TXT record. Because sending-service IPs change, these services keep the flattened record updated automatically via a CNAME delegation. Alternatively, consolidate: if you only use Google Workspace, the record `v=spf1 include:_spf.google.com ~all` with a single lookup is all you need. Use `~all` (softfail) during rollout and move to `-all` (hardfail) once you have verified every legitimate sender is included.

DKIM Key Rotation and 2048-Bit Standards

DKIM signs every outbound message with a private key, and the receiving server verifies it against a public key published as a TXT record at `selector._domainkey.yourdomain.com`. The M3AAWG best practice is to use 2048-bit RSA keys and rotate them at least every 12 months, and more frequently (every 6 months) for high-volume senders or after any suspected compromise.

The practical rotation pattern is to publish a second selector (for example `s2024._domainkey`) alongside the existing one, reconfigure your mail server to sign with the new key, then wait at least 48 hours before removing the old DNS record so in-flight messages still verify. Google Workspace, Microsoft 365, and Postfix with OpenDKIM all support two concurrent selectors without downtime.

1024-bit keys are still widely deployed but no longer recommended. Gmail, Yahoo, and Microsoft have all flagged 1024-bit as "weak" in recent sender guidance, and some operators outright reject 512-bit signatures. If your current TXT record has `k=rsa; p=` followed by a shorter Base64 payload (roughly 216 characters), you are on 1024-bit and should regenerate.

DMARC Policy Progression: none, quarantine, reject

DMARC publishes a policy telling receiving servers what to do with mail that fails SPF and DKIM alignment. The three policies are `p=none` (monitor only), `p=quarantine` (send to junk), and `p=reject` (bin entirely). Gmail and Yahoo now require at least `p=none` for any domain sending more than 5,000 messages per day to their users, per their February 2024 sender requirements.

A realistic deployment timeline is six to eight weeks: weeks 1 to 2 at `p=none` with both `rua=mailto:dmarc@yourdomain.com` (aggregate reports) and optionally `ruf=mailto:forensic@yourdomain.com` (per-message failure reports) to see what is actually sending; weeks 3 to 4 at `p=quarantine; pct=25` to route a quarter of failures to junk; weeks 5 to 6 at `p=quarantine; pct=100`; then finally `p=reject` once aggregate reports show zero legitimate failures.

Aggregate (rua) reports arrive as XML daily from every major mailbox provider. Tools like Postmark's free DMARC monitoring, dmarcian, or URIports parse these into readable dashboards. Forensic (ruf) reports are rarer because most providers do not send them for privacy reasons, so rua reports are where you will do the actual diagnostic work.

BIMI: Putting Your Logo in the Inbox

Brand Indicators for Message Identification (BIMI) is the newest piece of the authentication puzzle. It displays your company logo next to authenticated emails in supported inboxes, which is a measurable trust signal and also a strong incentive to get DMARC to enforcement. Gmail, Yahoo Mail, Apple Mail (iOS 16+), and Fastmail all render BIMI logos today; Outlook.com has an ongoing pilot.

The catch is that Gmail and Apple Mail both require a Verified Mark Certificate (VMC) from DigiCert or Entrust, which in turn requires a registered trademark of the exact logo at a recognised trademark office such as the UK IPO, USPTO, or EUIPO. VMCs cost around $1,500 per year at the time of writing. Without a VMC the logo will display on Yahoo and Fastmail but not Gmail.

To publish BIMI, convert your logo to a specific SVG Tiny 1.2 Portable/Secure profile (square, minimum 96x96, solid background), host it over HTTPS, then publish a TXT record at `default._bimi.yourdomain.com` containing `v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem`. BIMI only renders on domains with DMARC at `p=quarantine` or `p=reject`, so treat it as the reward for completing the DMARC journey described above.

If you set up email alongside a website on BearHost Shared Hosting , our cPanel Hosting Features tooling has a DNS editor that supports all the record types above, and our Blogs How To Secure Wordpress Website post covers the related question of sending transactional mail from WordPress without tripping your own DMARC policy.

Deliverability: Warm-Up, Reputation, and the Google/Yahoo 2024 Rules

In February 2024, Gmail and Yahoo jointly introduced new sender requirements that now apply to any domain sending more than 5,000 messages per day to their combined userbase. Authentication with SPF, DKIM, and DMARC alignment is mandatory; the one-click list-unsubscribe header (RFC 8058) must be present on commercial mail; and the user-reported spam rate must stay under 0.3 percent, with 0.1 percent as the target. Crossing 0.3 percent triggers silent folder routing for your entire domain.

New sending IPs need warm-up. Sending 50,000 messages on day one from a brand-new IP is the fastest way to land in spam permanently, because receivers have no reputation history for that IP. Start at a few hundred messages per day to your most engaged recipients, then roughly double every 2 to 3 days, watching Postmaster Tools at postmaster.google.com for reputation signals. Full ramp-up to 100,000+ per day takes 4 to 6 weeks.

Google's Postmaster Tools is the single most useful dashboard for diagnosing deliverability. It shows your domain and IP reputation as a four-tier rating (High, Medium, Low, Bad), spam rate by day, encryption rate, and DMARC pass rate. Microsoft SNDS (Smart Network Data Services) provides equivalent data for Outlook.com and Hotmail. Check both weekly during growth and immediately after any infrastructure change.

MTA-STS, TLS-RPT, and Transport Security

SPF, DKIM, and DMARC protect message authenticity but say nothing about whether the message travelled over an encrypted connection. MTA-STS (RFC 8461) is the fix. You publish a policy at `_mta-sts.yourdomain.com` and serve a policy file at `https://mta-sts.yourdomain.com/.well-known/mta-sts.txt` listing your MX hosts and an `enforce` mode. Sending MTAs that support MTA-STS then refuse to deliver if they cannot establish valid TLS to your server.

A working policy file is four lines: `version: STSv1`, `mode: enforce`, `mx: mail.yourdomain.com`, `max_age: 604800`. Combined with a DNS TXT record `v=STSv1; id=20260101T000000`, this prevents the downgrade attacks that were demonstrated against SMTP in the 2014 STARTTLS stripping research. Google Workspace and Microsoft 365 both publish MTA-STS policies and honour policies from other senders.

TLS-RPT (RFC 8460) is the companion. Publish a TXT record `_smtp._tls.yourdomain.com` with `v=TLSRPTv1; rua=mailto:tls-rpt@yourdomain.com` and receiving servers email you a daily JSON report of any TLS failures when delivering to your domain. This is how you spot a misconfigured MX before it turns into silent delivery loss. Combined with DANE (DNSSEC + TLSA records), these three give you a complete transport-layer assurance stack.