SPF, DKIM, DMARC and MX Explained

Four DNS record families carry much of a custom email domain’s operational policy. MX directs incoming mail. SPF authorizes sending infrastructure. DKIM attaches a verifiable domain signature to messages. DMARC checks whether SPF or DKIM aligns with the domain visible to the recipient and publishes an enforcement policy.

They work together, yet each solves a separate problem. A domain administrator should understand those boundaries before connecting a provider or migrating mail.

Thelemail’s private custom-domain email service generates and checks the required records. This guide explains what the records mean so you can review the resulting configuration with confidence.

MX selects the inbound mail servers

An MX record says which host accepts email for a domain. Each record has a preference value and a target hostname. Lower preference numbers are tried first. Multiple records at the same preference can distribute attempts among equivalent servers, while higher-numbered records commonly provide alternate delivery paths.

The target is a hostname that resolves to an address. Enter the values exactly as the mail provider supplies them. DNS dashboards handle the zone name and final dot differently, so treat the published result as the final authority.

MX affects incoming routing. It says nothing about which systems may send as the domain. That authorization comes from SPF and DKIM, with DMARC evaluating identity alignment.

During a provider migration, prepare the new service before replacing MX. Create every mailbox, alias and shared address first. The staged MX cutover guide covers TTL planning, overlap monitoring and rollback.

SPF authorizes the envelope sender

Sender Policy Framework, or SPF, publishes a TXT policy that identifies systems allowed to send using a domain in the SMTP envelope. Receiving servers compare the connecting IP with the mechanisms in that policy.

The envelope identity is often called the return path or MAIL FROM address. It receives bounces and can differ from the From address visible in a mail client. A raw SPF pass may therefore use a domain unrelated to the visible sender.

An SPF policy can authorize direct IP ranges and provider-maintained policies. Common mechanisms include ip4, ip6, a, mx and include. The final qualifier covers unmatched sources. Your provider should supply its required policy elements.

Keep one SPF policy per domain

A domain should publish one SPF record beginning with v=spf1. Several separate SPF records create a permanent evaluation error. When a website platform, billing system and mailbox provider all send mail for the domain, combine their authorized mechanisms into one policy.

SPF evaluation allows at most ten DNS-querying mechanisms and modifiers. Nested include policies count toward that limit. Exceeding it produces a permanent error. Remove retired senders and consider dedicated subdomains for different mail purposes.

Forwarding can affect SPF because the forwarding server connects from a new IP while preserving an earlier envelope domain. Sender Rewriting Scheme can provide a new authorized envelope identity. DKIM can survive forwarding when signed content stays intact.

DKIM signs the message with a domain key

DomainKeys Identified Mail, or DKIM, gives a sending system a private signing key. Its DKIM-Signature header contains the signing domain, selector, signed headers and a body hash. The receiver gets the public key from DNS and verifies the signature.

The DNS name combines the selector with _domainkey and the signing domain. A provider supplies the public key record or a CNAME pointing to it. Several selectors can coexist for key rotation and multiple sending services.

A successful DKIM verification shows that the signed content survived transit and a private-key holder created the signature. DMARC then checks alignment between the signing domain and visible From domain.

Mailing lists, gateways and security products can modify signed content and break a DKIM signature. Inspect the Authentication-Results header and message path before changing the DNS key.

Rotate selectors deliberately

For a safe DKIM rotation, publish the new key, sign with the new selector, verify results and retain the former public key through the transition window. Restrict private keys to authorized sending systems.

DMARC connects authentication to the visible From domain

Domain-based Message Authentication, Reporting and Conformance, or DMARC, is published at _dmarc beneath the domain. It evaluates the domain in the visible From header against SPF and DKIM results.

DMARC passes when at least one of these paths succeeds:

• SPF passes and its authenticated envelope domain aligns with the visible From domain.
• DKIM passes and its signing domain aligns with the visible From domain.

Relaxed alignment permits organizationally related subdomains, while strict alignment requires an exact domain match. Relaxed alignment is the default. The policy also describes requested failure handling.

The primary policy modes are:

• p=none requests monitoring while reports are collected.
• p=quarantine asks receivers to treat failing mail as suspicious.
• p=reject asks receivers to reject failing mail.

Receivers retain final control over local handling, so the policy is a published request. Aggregate reports sent to rua destinations summarize results by source and expose alignment problems before stronger enforcement.

Move from monitoring to enforcement after every legitimate sender is accounted for. A forgotten invoicing tool or website form can lose deliverability under a strict policy even when mailbox-provider mail is configured correctly.

Authentication and encryption protect different things

SPF, DKIM and DMARC help receiving systems evaluate domain identity and spoofing, while MX routes incoming mail. Content encryption requires controls elsewhere in the message path.

TLS protects SMTP traffic between supporting servers. End-to-end encryption protects readable content across the full path when both sides use compatible keys. Storage encryption protects mailbox data held by the service.

Thelemail provides zero-access encryption for stored mailbox content and end-to-end encryption between Thelemail accounts. For outside mail, the web client uses WKD/OpenPGP when a compatible recipient key is available, and Thelemail publishes user keys through WKD for compatible encrypted inbound mail. Other external delivery uses standard SMTP with TLS where supported. External subject headers and envelope metadata stay visible for routing. The security and threat model describes those guarantees precisely.

Use a staged setup order

A new custom-domain configuration is easiest to review in this sequence:

1. Verify domain ownership with the provider’s TXT record.
2. Publish DKIM for the new sending service.
3. Build one SPF policy covering every legitimate sender.
4. Publish DMARC with reporting and an appropriate initial policy.
5. Create every mailbox, alias and shared address.
6. Test outbound authentication from each sending service.
7. Change MX after all inbound recipients are ready.
8. Review reports and move DMARC enforcement according to evidence.

This is the order used by Thelemail’s domain setup walkthrough. The current plans and capacities determine mailbox, storage and domain limits. Paid plans include unlimited aliases, subject to a workspace anti-abuse guardrail; aliases are not included in the Free plan.

An individual can use an @thelemail.com address without administering DNS. A household or founder-run team gains the portability of custom-domain addresses when one technical administrator owns this setup process.

Diagnose failures from the message header

Start with the receiving system’s Authentication-Results header. It usually records SPF, DKIM and DMARC outcomes along with the domains evaluated.

SPF passes while DMARC fails

Compare the authenticated envelope domain with the visible From domain. Configure an aligned return path or use an aligned DKIM signature.

DKIM reports a missing key

Query the selector and signing domain from the DKIM-Signature header. Check copied host fields, expired provider setup and early key removal.

DKIM verification fails with a published key

Confirm the current DNS key and check whether a forwarding service, mailing list or gateway changed signed content. Test a direct path to isolate modification.

SPF returns a permanent error

Check for multiple SPF records, syntax problems, recursive includes and more than ten DNS-querying terms. Retire unused services or separate mail streams.

Some senders still reach the former host

Query authoritative DNS and inspect the MX TTL. Keep both providers available through the planned overlap and reconcile old-host messages.

Maintain the records after launch

Email DNS needs periodic review. Remove authorization for retired platforms, rotate DKIM selectors, read DMARC aggregate reports and verify MX after DNS-provider changes. Add every new sending service to the inventory before it sends production mail.

Use provider dashboards as one signal and independent DNS queries as another. Test messages to external systems reveal the authentication results receivers actually see. Keep the domain registrar, DNS provider and mail host recovery paths documented outside the mailbox they protect.

For family domains, the family email setup guide turns these records into a complete household plan. Homelab administrators can use the self-hosting evaluation to assess the network, reputation and operational work behind the DNS.

When the four record families are understood separately, troubleshooting becomes much more direct: MX answers where incoming mail goes, SPF answers which infrastructure may send, DKIM proves a domain signature, and DMARC checks alignment with the identity a recipient sees.