Email on your own domain gives you an address that can remain consistent while the underlying mailbox service changes. Making that work requires several separate decisions: where incoming mail goes, which systems may send, how outgoing messages are authenticated, and how receiving systems should treat failures. DNS publishes the information those systems use.
MX, SPF, DKIM, and DMARC often appear together in a provider’s setup checklist, but they serve different purposes. Understanding those purposes helps you change the right record and test the right outcome. Start with the custom domain email overview if you are still deciding who will host the mailbox and who will manage your domain.
Find the account that controls authoritative DNS
Your domain registrar, DNS operator, website host, and email provider may be different companies. Before editing records, establish which service currently hosts the authoritative DNS zone. A DNS screen in an unused hosting account can accept changes without affecting the records the internet actually receives.
Confirm that you can access the right account and recover it if needed. Save a copy of the existing zone or relevant records, including their names, types, values, priorities, and time to live. Record the purpose of unfamiliar entries before changing them; the zone may also support your website and other services.
Cloudflare’s official email record setup guide emphasizes that the exact DNS values depend on the email provider. Treat your provider’s account-specific instructions as the source for those values. The explanations below describe their roles and do not supply a configuration to paste into a live domain.
Give each record one clear job
| Record or mechanism | Question it helps answer | Common placement |
|---|---|---|
| MX | Which mail servers accept incoming messages for this domain? | MX records at the receiving domain name. |
| SPF | Is this sending server authorized for the envelope sender’s domain? | A TXT record at the domain being checked. |
| DKIM | Does a signature verify using the signing domain’s published key? | A selector under _domainkey, with provider-specific publication details. |
| DMARC | Does authenticated sending align with the visible From domain, and what policy applies? | A TXT record under _dmarc. |
Receiving and sending are separate paths. An MX record can direct incoming mail correctly while outgoing authentication is incomplete. Likewise, a domain can authenticate an automated sender without using that sender as its mailbox host. Keep these relationships separate in your notes.
Set MX for the receiving service you intend to use
MX records name the servers that should receive mail for a domain. Their preference numbers guide which server is tried first; a lower number indicates a more preferred destination. Use the full set and priorities specified by the mailbox provider, rather than inventing extra destinations as a precaution.
Create the required users, shared addresses, and aliases at the destination before changing incoming routing. A server receiving mail for your domain still needs to know what to do with each address. Test an ordinary user address, an important alias, and any shared address after the change.
Avoid leaving an old provider listed as an improvised backup unless you have deliberately configured and tested that arrangement. Otherwise, mail can reach a system that no longer has the right users or handling rules. Document the previous MX values so you can investigate or reverse a routing change if the migration plan requires it.
Build SPF from an inventory of legitimate senders
SPF allows a domain to publish authorization for servers using that domain in the SMTP envelope sender identity. That identity is involved in handling delivery failures and can differ from the From address displayed to a reader. An SPF pass therefore does not, by itself, establish that the visible From domain is authenticated.
List each system that sends on your behalf: the staff mailbox service, customer platform, appointment tool, and any other active sender. Ask each provider which envelope domain it uses and what configuration it requires. Some arrangements use a provider-managed envelope domain; others require changes to a domain or subdomain you control.
Publish a single applicable SPF policy at each domain being configured. Adding a second independent SPF record is not a way to combine providers. Merge authorized mechanisms deliberately according to their instructions. SPF evaluation limits DNS-querying terms, so a long chain of included services needs review rather than unlimited additions.
Remove obsolete authorization when a sender is retired and no longer needs it. Keep a note connecting each entry to an active service and an owner. That record makes later maintenance much easier than trying to identify unfamiliar provider names during a delivery incident.
Publish DKIM, then confirm signing is active
DKIM adds a cryptographic signature covering selected message content and headers. The receiving system uses the signature’s domain and selector to locate the public key and verify it. The private signing key stays with the sending system; it should never be pasted into public DNS.
Your provider may ask you to publish a TXT record containing a public key or CNAME records that delegate the lookup to provider-managed records. Follow the specified names and types exactly. Check whether your DNS editor automatically appends the domain so you do not accidentally publish a duplicated name.
Publishing the lookup record and enabling signing can be separate steps. Send a new test message after completing the provider’s process and inspect the recipient’s authentication results. A DNS record existing in a dashboard does not prove that outgoing messages carry a valid signature.
DKIM verifies a signature; it does not encrypt the message for the recipient. It also does not guarantee that the content is safe or that the sender’s account has not been misused. Keep its purpose specific when explaining the setup to colleagues.
Use DMARC to connect authentication to the visible sender
DMARC evaluates the domain in the visible From address against authenticated identifiers. A message can pass DMARC when SPF passes with an aligned envelope domain, or DKIM passes with an aligned signing domain. Both mechanisms do not have to pass for DMARC to pass, although configuring both correctly can support a more robust sending arrangement.
Alignment has relaxed and strict modes. Relaxed alignment can accept the appropriate organizational domain relationship; strict alignment requires an exact domain match. This is why an SPF or DKIM pass for an unrelated service domain does not automatically produce a DMARC pass for your own visible address.
DMARC also lets a domain publish a requested handling policy and request reports. A monitoring policy does not ask receivers to quarantine or reject messages because they fail DMARC. A sensible rollout begins by understanding legitimate sending, examining available reports, and correcting failures before requesting stronger handling.
Receiving systems apply their own policies, and reports are not a complete delivery ledger. Forwarding, mailing lists, and other message transformations can complicate authentication. Investigate those paths using real examples rather than tightening policy solely because a simple direct test succeeded.
Test the complete arrangement before calling it finished
Send a fresh message from every legitimate sending system to separate recipient accounts. Include staff mail and automated tools. Inspect the authentication results at the recipient, recording the visible From domain, SPF identity, DKIM signing domain, and DMARC outcome. Retain a few harmless test messages as evidence of the configuration.
Also send messages into your domain and reply from the destination mailboxes. Check aliases and shared addresses independently. DNS caches may continue serving previous answers until their cached lifetime expires, so record when changes were made and compare authoritative answers with what a resolver currently returns.
For a planned move, review TTL settings in advance. Lowering a record’s TTL immediately before changing its value does not erase older answers already cached with the previous lifetime. Allow for that existing cache behavior in the transition plan, and keep the previous mailbox arrangement available for the agreed observation period.
Authentication is one part of delivery. Recipient filtering, sender reputation, message content, and addressing problems can still affect the result. Keep failure messages and investigate the specific cause. The business email operating plan helps assign ownership when several people or external services share responsibility.
Keep the configuration understandable
Document the purpose and owner of every mail-related record, alongside the provider instructions used to create it. Review that record when adding a service, changing mailbox hosts, rotating signing keys, or retiring a domain. Custom domain email stays manageable when routing, authorization, signatures, and policy each have a clear role and a verified result.
