What professional email is (and why it’s worth it)
A professional email is an address that uses your company’s domain after the “@”, such as sales@yourcompany.com. The domain is the same name your website uses, registered to your company (in Brazil, for example, .com.br domains are registered through Registro.br).
Beyond a more serious image, there are practical benefits: accounts belong to the company rather than to an employee, you can create addresses for each department, and domain authentication makes it harder for scammers to send messages impersonating your brand.
Credibility
Customers and suppliers trust messages sent from a company’s own domain more.
Control
When someone leaves the company, the account and its history stay with the company.
Deliverability
With properly configured DNS, your messages are more likely to reach the inbox.
Choosing an email service
The first step is deciding where your mailboxes will live. Broadly speaking, there are three options:
| Criterion | Productivity suites | Hosting email | Specialized providers |
|---|---|---|---|
| Examples | Google Workspace, Microsoft 365 | Email included in cPanel, Plesk and similar plans | Zoho Mail, Proton, dedicated email providers |
| Cost | Per user/month | Usually included | Varies; usually mid-range |
| Storage and features | Extensive, with calendar, drive and meetings | Limited by the plan | Good, focused on email |
| Spam filtering and security | Very robust | Depends on the server | Generally robust |
| Risk of blocking caused by others | Low | Higher on shared servers | Low |
| Best for | Teams that collaborate heavily | A few accounts and light use | Reliable email without a full suite |
General assessment. Features, limits and prices change often; check each service’s current terms.
Your website and email don’t need to be in the same place
It’s common to host the website on one server and email on another service. The domain’s DNS decides where each one goes. Keeping them separate prevents a website problem from taking down your email, and vice versa.
Before you start: what you’ll need
- A registered domain in the company’s name, not a former vendor’s or employee’s.
- Access to the DNS panel, which may be at your registrar (such as Registro.br), your hosting provider or a service like Cloudflare. To find out where it is, check which DNS servers (nameservers) the domain uses.
- A list of the addresses to be created and who will use each one.
- An inventory of what already exists: if the company already has email elsewhere, you’ll need to plan the migration of old messages.
nslookup -type=NS yourcompany.com # Sample output: # yourcompany.com nameserver = a.sec.dns.br → DNS at Registro.br # yourcompany.com nameserver = ana.ns.cloudflare.com → DNS at Cloudflare
All the changes in this guide must be made in the panel indicated by those nameservers. Changing records anywhere else will have no effect.
Creating accounts and organizing addresses
After you sign up for the service, it will ask you to add and verify your domain. Verification proves you own it and is usually done with a temporary TXT (or CNAME) record in DNS containing a code provided by the service.
Once the domain is verified, create the accounts. Some best practices:
Personal accounts
A single pattern, such as firstname.lastname@ or firstname@, makes things easier for customers and your own team.
Aliases and groups
Addresses like contact@ and billing@ can be aliases or groups that deliver to several people, with no extra account cost.
Passwords and 2FA
Require strong passwords and enable two-step verification. A hacked email account is a gateway to scams.
Technical addresses
Set aside accounts like postmaster@ and a mailbox for DMARC reports. They’ll come in handy later.
Understanding email DNS
DNS works like the internet’s phone book: it translates names into addresses and stores information about the domain. For email, it answers two questions: where to deliver incoming messages and how to tell whether an outgoing message is legitimate.
The post office address
The MX record tells other servers where the “post office” that receives your domain’s mail is located.
Sender, stamp and house rules
SPF is the list of who may send mail on your behalf, DKIM is the seal proving the letter wasn’t tampered with, and DMARC says what to do with suspicious letters.
Two terms come up all the time: TTL is how long, in seconds, other servers cache the information before checking again; propagation is the time it takes for everyone to see the change. That’s why a change can take anywhere from minutes to a few hours to take effect everywhere.
Configuring MX, SPF, DKIM and DMARC
The values below are for illustration only
Each service provides its own servers, priorities and keys, usually on a screen called “DNS settings”, “DNS records” or “Domain authentication”. Field names also vary between panels: “Name”, “Host” or “Entry” generally mean the same thing. Always use your provider’s values.
1. MX: where emails are received
The MX record points to the server that receives the domain’s messages. The priority sets the order: the lowest number is tried first, and the others act as backups.
# Type Name Priority Value TTL
MX @ 10 mx1.example-provider.com 3600
MX @ 20 mx2.example-provider.com 3600
- @ stands for the domain itself. Some panels ask you to leave the field blank or type the full domain.
- Remove old MX records from any previous provider. Mixing records sends some emails to one place and some to another.
- The MX value must be a hostname, never an IP address.
2. SPF: who can send on behalf of the domain
SPF is a TXT record listing the servers authorized to send email using your domain. If your website, a system or an email marketing tool also sends messages, they all need to be in the same record.
# Type Name Value TXT @ "v=spf1 include:_spf.example-provider.com ~all" # With the email provider + a marketing tool: TXT @ "v=spf1 include:_spf.example-provider.com include:spf.example-marketing.com ~all"
- include: authorizes a service’s servers. ip4: authorizes a specific IP.
- ~all (softfail) flags anyone not on the list as suspicious; -all (fail) recommends rejection. Start with ~all and tighten it once you’re sure nothing legitimate was left out.
- A domain can have only one SPF record. Two v=spf1 records invalidate both.
- SPF allows a maximum of 10 DNS lookups. Too many include entries can exceed that limit.
3. DKIM: your messages’ digital signature
DKIM adds a cryptographic signature to every email you send. The receiving server uses a public key published in your DNS to confirm the message really came from your domain and wasn’t altered along the way.
Typically, you generate the key in your email service’s panel, copy the record into DNS, and then go back to the panel to enable signing. That last step is often forgotten.
# TXT format, with the public key: TXT selector1._domainkey "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." # CNAME format, pointing to a key hosted by the provider: CNAME selector1._domainkey selector1.dkim.example-provider.com
The selector (selector1 in the example) is a name that identifies the key. It lets you have multiple keys at once, one for each service that sends email, without conflicts.
4. DMARC: the policy for messages that fail
DMARC ties SPF and DKIM together and tells receiving servers what to do when a message fails verification. It also lets you receive reports on who is sending email with your domain, including fraud attempts.
# Phase 1 — monitor only (2 to 4 weeks) TXT _dmarc "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com" # Phase 2 — send failing messages to spam TXT _dmarc "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourcompany.com" # Phase 3 — reject failing messages TXT _dmarc "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com"
- p= is the policy: none (observe only), quarantine (send to spam) or reject (refuse).
- rua= is the address that receives daily reports in XML format. DMARC analysis tools turn these files into readable charts.
- To pass DMARC, the sender’s domain must be aligned with the domain validated by SPF or DKIM.
No longer optional
Major providers such as Gmail, Yahoo and Outlook now require SPF, DKIM and DMARC from higher-volume senders. Even for small businesses, missing these records greatly increases the chance of landing in spam.
Record summary
| Record | Type | Name | Purpose |
|---|---|---|---|
| MX | MX | @ | Points to the server that receives email |
| SPF | TXT | @ | Lists who can send for the domain |
| DKIM | TXT or CNAME | selector._domainkey | Publishes the key that validates the signature |
| DMARC | TXT | _dmarc | Defines the policy and reporting |
| Verification | TXT or CNAME | Specified by the provider | Proves you own the domain |
Quick SPF and DMARC generator
Fill in the fields to build a starting point. Check the include values in your provider’s documentation before publishing.
Accessing email on desktop and mobile
Besides webmail, you can use apps like Outlook, Gmail, Apple Mail or Thunderbird. Many services offer their own app or automatic setup; otherwise, manual setup relies on these protocols:
- IMAP: keeps messages on the server and syncs them across all devices. It’s the recommended option today.
- POP3: downloads messages to a single device. You may lose emails if that device fails.
- SMTP: the sending protocol, always with authentication (username and password).
# Incoming IMAP imap.example-provider.com port 993 SSL/TLS POP3 pop.example-provider.com port 995 SSL/TLS # Outgoing SMTP smtp.example-provider.com port 465 SSL/TLS port 587 STARTTLS Username: full address (e.g., maria@yourcompany.com)
If the account uses two-step verification, some older apps require an app password, generated in the service’s panel, instead of your regular password.
How to test that everything works
1. Check the records in DNS
nslookup -type=MX yourcompany.com nslookup -type=TXT yourcompany.com # SPF nslookup -type=TXT selector1._domainkey.yourcompany.com # DKIM nslookup -type=TXT _dmarc.yourcompany.com # DMARC # On Linux/macOS, dig gives more direct answers: dig MX yourcompany.com +short
2. Send and receive test messages
Send an email from an external account (a personal Gmail or Outlook) to the new address and reply to it. Then, in Gmail, open the received message, click “Show original” and check the authentication results:
Authentication-Results: mx.google.com; dkim=pass header.d=yourcompany.com spf=pass smtp.mailfrom=maria@yourcompany.com dmarc=pass (p=NONE) header.from=yourcompany.com # Warning signs: spf=softfail → sending server not in SPF dkim=none → DKIM signing not enabled dmarc=fail → neither SPF nor DKIM aligned
3. Use diagnostic tools
Online DNS checkers and email scoring services (such as spam testers and MX analyzers) reveal missing records, duplicate SPF, DKIM issues and whether your domain or IP appears on blocklists. It’s worth retesting after every change.
Common problems and how to fix them
📭 Emails stop arriving after switching providers
Almost always, an old MX record is still published, or the change was made in a DNS panel that isn’t the active one. Check the nameservers, remove the previous MX records and wait for the TTL to expire.
🗑️ Sent messages land in spam
SPF is missing, DKIM wasn’t enabled, or DMARC fails due to lack of alignment. Content matters too: too many links, image-only emails and sensationalist subject lines hurt your reputation.
🧾 Website form doesn’t send, or goes to spam
Many websites send through the server’s built-in mail function, which isn’t in SPF and doesn’t sign with DKIM. The fix is to configure the site to send via your provider’s authenticated SMTP or a transactional email service included in SPF.
⚔️ Two SPF records
When a new tool is added, someone creates a second v=spf1 record. Both become invalid. Merge everything into a single record.
☁️ Email records “proxied” on Cloudflare
MX and TXT records don’t go through the proxy, but subdomains used for email (such as mail.) stop working when the orange cloud is on. These records should be set to “DNS only”.
✂️ Truncated DKIM key or misplaced quotes
Long keys sometimes get cut off when pasted. Some panels require splitting the value into chunks of up to 255 characters; others do it automatically. Compare the published value with the one your provider gave you.
🔁 Forwarded emails fail SPF
When an email is automatically forwarded, the intermediate server isn’t in the original sender’s SPF. That’s why DKIM matters so much: the signature survives forwarding and keeps DMARC passing.
Setting up is one step; maintaining is another
Once everything works, the job isn’t over. New tools that send email must be added to SPF, the DMARC policy should evolve from none to reject, reports need to be reviewed, and accounts of departing employees must be deactivated.
For companies without a dedicated technical team, working with a specialized partner usually pays off. WD Seven, for example, helps you choose the right email service for your company’s size, configures DNS with full authentication, migrates old messages without disrupting communication, and connects your website forms to authenticated sending.
Are your emails landing in spam?
With Cloud & DevOps and Maintenance & Support, WD Seven reviews your DNS and fixes your domain authentication.
Frequently asked questions
Yes. Virtually every service lets you access your account through apps like Gmail, Outlook and Apple Mail, either via IMAP and SMTP or through the provider’s own app.
After you change the DNS records, propagation usually takes anywhere from a few minutes to a few hours, and in rare cases up to 48 hours, depending on the configured TTL. Lowering the TTL a few days before a migration speeds up the switch.
Not if the migration is planned. Most services offer IMAP import tools. Ideally, migrate your messages before changing the MX records and run a final sync right afterward.
Technically, email works without them, but in practice they are essential. Without these records, your messages are far more likely to land in spam or be rejected, and your domain is more vulnerable to spoofing.
No, as long as you only change the email records (MX and the SPF, DKIM and DMARC TXT records). Your website relies on A, AAAA or CNAME records, which shouldn’t be touched in this process. Still, write down or export your current records before you start.
Conclusion and checklist
Setting up professional email isn’t complicated, but it requires doing things in order: choose the service, verify the domain, create the accounts, publish the DNS records and test. MX ensures you receive mail; SPF, DKIM and DMARC ensure your messages are recognized as legitimate.
Choose your email service
Consider number of users, storage, security and budget.
Find the active DNS panel
Check the nameservers and save a copy of the current records.
Verify the domain and create accounts
Define the address pattern, aliases, strong passwords and 2FA.
Migrate old messages, if any
Import via IMAP before changing the MX.
Configure MX
Use your provider’s values and remove old records.
Publish a single SPF record
Include every service that sends for the domain, starting with ~all.
Publish and enable DKIM
Add the record and turn on signing in the service’s panel.
Create DMARC in monitoring mode
Start with p=none and move to quarantine and reject after reviewing reports.
Test sending, receiving and headers
Confirm spf=pass, dkim=pass and dmarc=pass.
Update your website forms
Make the site send via authenticated SMTP.
MX
Makes sure emails arrive.
SPF + DKIM
Prove you are who you say you are.
DMARC
Protects your brand from fraud.
Management
Keeps everything running over time.
