Corporate Email on Your Own Domain: MX, SPF, DKIM and DMARC Made Simple

An address like info@your-company.ge inspires more trust in a customer than an address from a free mail service. At the same time, it is under your control: when an employee leaves, the address stays with the company. In this article we explain in simple terms what email on your own domain means and what the four abbreviations are for: MX, SPF, DKIM and DMARC.

What corporate email is

You have a domain, for example your-company.ge. The mailboxes on this domain are handled by a service, most often Microsoft 365 (Exchange Online) or Google Workspace (Gmail). The domain and the mail service are two separate things. They are connected to each other by DNS records, that is, domain settings. You can think of DNS as the internet's address book: it says where your domain's mail should go and who is allowed to send email in your name.

An important detail: these records are changed where your domain's DNS is managed, that is, at the domain registrar or at a DNS service provider. Microsoft's documentation states directly that Microsoft 365 has no portal or PowerShell command for managing SPF records. Such a record is created at the registrar or the DNS hosting provider.

MX: where an incoming email should go

When someone sends you an email, the sender's system checks your domain's MX records and learns from them where to deliver the message. According to the Google Workspace help page, its MX value is smtp.google.com. If you used Google Workspace before 2023, your domain may have other values that start with "aspmx". In Microsoft 365, the MX value is individual for each domain. You get it from the admin center, and it looks like this: something.mail.protection.outlook.com.

Practical rules for MX:

• After adding the new record, delete the old MX records. According to Google's instructions, leaving old or incorrect records in place may cause mail to work incorrectly.
• Microsoft's documentation recommends a single MX record that points to one mail system. Several records may cause delivery problems.
• The change does not take effect immediately. Microsoft writes that a DNS change usually becomes active in about 15 minutes, but sometimes takes longer. Google warns that it can take up to 72 hours for a new MX record to be recognized.

SPF: who is allowed to send in your name

SPF is a TXT-type record that lists the servers and services that are allowed to send mail in the name of your domain. The receiving system uses it to check whether an email was sent in your name from an unfamiliar source. The main rule: there must be only one SPF record on a domain. If, besides Microsoft or Google, another service also sends emails from your domain, for example a newsletter platform or a CRM, all sources must be combined in one record. Microsoft also advises that in complex organizations, where it is hard to identify all sources, you should quickly start DKIM and DMARC in monitoring mode.

DKIM: the digital signature of an email

DKIM adds a digital signature to an email sent in your name, and the recipient verifies this signature with a key published in DNS. Microsoft's documentation recommends setting up DKIM on every custom domain and subdomain from which mail is sent. The exact records you need to add in DNS are shown in the admin panel of your mail service. DKIM alone is not enough to protect your domain from spoofing. It needs to work together with SPF and DMARC.

DMARC: what happens to an email that fails the checks

DMARC links SPF and DKIM to the address that the recipient sees in the "From" field. It states how the receiving system should act if an email fails the checks: do nothing and only send you a report, mark the email as suspicious, or reject it. According to Microsoft's documentation, for your own domains the DMARC record is also created in DNS, not in the Microsoft 365 portal. A DMARC record automatically covers subdomains too, if they do not have their own DMARC record. However, each subdomain still needs SPF and DKIM for DMARC.

The right order

According to Microsoft's official instructions, you set up SPF first, then DKIM, and DMARC last. You start DMARC in "do nothing" mode, that is, for observation only. In the reports you will see which sources send mail in your domain's name and who passes the checks. It is worth moving to strict mode only when you are sure that all legitimate senders are configured correctly. Otherwise, real emails may be lost.

A short checklist before launch

• Find out where your domain's DNS is managed and who has access to it.
• Save a copy of the existing DNS records, especially the MX and TXT records.
• List all services that send emails from your domain: accounting, online store, website forms, agencies.
• A domain verification TXT record does not change the direction of mail. The direction of emails changes only when you change the MX record. So plan the MX change for a time when everyone is ready.
• After the change, test in both directions: send an email to an external address and receive one from outside.
• After enabling DKIM, check whether the emails you send pass the SPF and DKIM checks. Then publish DMARC in monitoring mode.

Common mistakes

• Creating two SPF records, one for Microsoft and another for a different service. The correct way is one combined record.
• Leaving the old MX record in place, so that mail partly reaches the old system.
• Enabling DMARC in strict mode before checking the other two records.
• Forgetting subdomains: each subdomain from which mail is sent needs its own SPF and DKIM.

Setting up corporate email is not difficult, but it requires attention to detail. If you would prefer a Georgian IT team to do it, Appy.ge can help you. Appy is an official Microsoft CSP partner and also sets up Google Workspace.

Sources:
• Set up MX records for Google Workspace - Google Workspace Admin Help — https://support.google.com/a/answer/6150791?hl=en
• External Domain Name System records for Microsoft 365 - Microsoft Learn — https://learn.microsoft.com/en-us/microsoft-365/enterprise/external-domain-name-system-records?view=o365-worldwide
• Set up SPF to identify valid email sources for your Microsoft 365 domain - Microsoft Learn — https://learn.microsoft.com/sr-Latn-RS/defender-office-365/email-authentication-spf-configure
• How to use DKIM for email in your custom domain - Microsoft Learn — https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure
• Set up DMARC to validate email in Microsoft 365 - Microsoft Learn — https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure