+994 70 270 58 00WhatsApp ↗

Corporate email on your own domain: MX, SPF, DKIM and DMARC

Which DNS records email on your own domain needs, in what order to configure them, and how to reach a strict DMARC policy without losing mail.

Email on your own domain looks more credible than an address on a free service, but that is not where the differences end. For messages to arrive, the domain needs four settings: MX, SPF, DKIM and DMARC. Here is what each one does and the order in which to add them.

MX: where incoming mail is delivered

The MX record names the mail servers that accept messages for your domain. Each record has a priority: the lower the number, the higher the preference. Several records with different priorities exist for redundancy, not for load balancing.

The main rule: MX records must match the service you actually use. A common situation is that mail moved to an external provider long ago while the old hosting records stayed in the zone, and part of the mail goes nowhere.

SPF, DKIM and DMARC: who may write in your name

SPF is a text record listing the servers allowed to send mail for the domain. A check permits no more than ten DNS lookups, so long include chains from several services stop working - the record has to stay compact.

DKIM adds a cryptographic signature to the message, with the public key published in DNS under a selector. It confirms the message was not altered in transit.

DMARC ties both checks to the domain in the From field and tells the receiving side what to do with mail that fails, as well as where to send reports.

The order of setup

  • List every service that sends mail for the domain: staff mailboxes, site notifications, CRM, campaign tools, accounting
  • Configure MX for the service that receives incoming mail
  • Add the domain to each sending service and enable DKIM signing there
  • Assemble one SPF record covering all those services and check the DNS lookup count
  • Add DMARC with a none policy and a reporting address
  • After two or three weeks review the reports and confirm every legitimate source passes
  • Move the policy to quarantine, then to reject

Why reject cannot be switched on straight away

A strict policy looks like the right decision, but enabled immediately it rejects mail from services you have forgotten about. The effect is not obvious at once: first notifications from the accounting system stop arriving, then it turns out a campaign reached nobody.

So for the first weeks DMARC runs in observation mode: mail is delivered as usual while reports show which servers actually send mail for your domain. Those reports often reveal forgotten services configured years ago.

Frequently asked questions

Can email stay on the website hosting?

Technically yes, and for a small company it works. The downsides appear with growth: shared hosting has no mail reputation, sending volumes are limited, and when the site moves, email risks moving with it. Keeping the site and the mail on separate platforms is usually more reliable.

Is DKIM needed when SPF is already configured?

Yes. SPF checks the sending server but breaks on forwarding: when a recipient auto-forwards a message, the sending server address changes. A DKIM signature survives forwarding, so together the two checks give a noticeably more stable result.

Where do DMARC reports arrive and what should be done with them?

They arrive as XML at the address in the record, and reading them by hand is impractical. Dedicated services turn the reports into a readable table of sources. During setup it is enough to confirm that every familiar service passes and that no unknown senders appear.

Let us set up mail for your domain

Send the domain and list the services that send mail on its behalf. We will check the current records and prepare a plan.

Discuss your project ↗

What would you like to make?

A short description and a way to reach you are enough to start.

info@siteman.az ↗+994 70 270 58 00
WhatsApp
AzIkSiteman AI assistant