How to Set Up SPF, DKIM and DMARC for a Custom Domain

Email authentication can look like a collection of unrelated DNS records. In practice, each record answers a different question:

• SPF: Which servers may send mail for this domain?
• DKIM: Was this message signed by an authorized sender, and did it change in transit?
• DMARC: Does the visible From domain align with SPF or DKIM, and what should receivers do when authentication fails?

This guide shows a safe, provider-neutral setup sequence for a custom domain.

The DNS values below are examples. Always copy the actual hostnames, selectors, and targets supplied by your email provider.

Before changing DNS

Confirm three things first:

1. You control the domain's authoritative DNS zone.
2. You know every service that currently sends mail for the domain.
3. You have saved a copy of the existing MX and TXT records.

Do not delete website A, AAAA, or CNAME records while configuring email. Email DNS and website DNS normally coexist.

You can inspect the records currently visible on the public internet with the Free Domain Mail DNS Checker.

Step 1: Configure MX for incoming mail

MX records tell other mail systems where to deliver messages addressed to your domain.

A simplified example looks like this:

Type: MX
Name: @
Priority: 10
Value: inbound.mail-provider.example

The @ symbol usually means the root domain, but DNS dashboards differ. Some expect a blank name, while others expect the complete domain.

Important rules:

• Use the exact MX destination supplied by the receiving provider.
• Lower priority numbers are tried first.
• Remove an old MX record only when you intentionally stop using the old receiver.
• Do not point MX to an ordinary website IP address.
• If you use Cloudflare, mail hostnames generally need to remain DNS only.

MX controls receiving. It does not authorize outgoing mail.

Step 2: Publish one SPF policy

SPF is stored as a TXT record. It lists the infrastructure allowed to send using a particular envelope domain.

Example:

Type: TXT
Name: @
Value: v=spf1 include:spf.mail-provider.example -all

The most common SPF mistake is publishing two records such as:

v=spf1 include:service-a.example -all
v=spf1 include:service-b.example -all

That does not create two valid policies. It normally produces an SPF permanent error. Combine legitimate senders into a single record instead:

v=spf1 include:service-a.example include:service-b.example -all

Also remember:

• SPF has a DNS-lookup limit.
• An include authorizes another provider's policy; it is not a redirect.
• ~all is a soft-fail qualifier and -all is a hard-fail qualifier.
• Changing to -all before identifying every sender may break legitimate mail.
• SPF alone may not satisfy DMARC when the authenticated envelope domain does not align with the visible From domain.

Step 3: Enable DKIM signing

DKIM adds a cryptographic signature to outgoing messages. The sending service holds the private key, while DNS publishes the public key or a CNAME pointing to it.

A provider may give you records like:

Type: CNAME
Name: selector1._domainkey
Value: selector1.dkim.mail-provider.example

Some services provide one selector; others provide several. Publish every record shown in the provider dashboard.

Common DKIM problems include:

• Entering the whole hostname when the DNS dashboard automatically appends the domain.
• Checking default._domainkey when the provider uses another selector.
• Creating a TXT record when the provider requested a CNAME.
• Copying a target with missing characters.
• Assuming that a published key means the sender has started signing.

After DNS verification, send a real test message and inspect its headers. Look for dkim=pass and verify that the signing domain aligns with the From domain.

For a more detailed walkthrough, see this DKIM setup guide.

Step 4: Start DMARC in monitoring mode

DMARC is a TXT record at _dmarc.yourdomain.com.

A sensible starting policy is:

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:[e-mail]

With p=none, receivers can send aggregate reports without being asked to quarantine or reject failures. This gives you time to find forgotten senders and alignment problems.

A safe rollout is usually:

1. Begin with p=none.
2. Review reports and fix legitimate failures.
3. Move a small percentage to p=quarantine.
4. Increase enforcement gradually.
5. Use p=reject only when authorized mail is consistently aligned.

The reporting address must be able to receive and process DMARC aggregate reports. These are XML files and can arrive in significant volume.

Step 5: Verify alignment, not only individual passes

A message can show spf=pass and still fail DMARC if SPF authenticated a different organizational domain. Likewise, DKIM must pass with an aligned signing domain.

DMARC passes when at least one aligned mechanism passes:

• SPF passes and the authenticated SPF domain aligns with the From domain, or
• DKIM passes and the DKIM signing domain aligns with the From domain.

This distinction matters with ticketing systems, newsletters, transactional platforms, and forwarding services.

Useful DNS checks

Replace the example domain and selector:

dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CNAME selector1._domainkey.example.com

If results differ between tools, query the authoritative nameserver directly. That helps distinguish a bad record from a resolver cache that has not refreshed yet.

DNS changes can appear quickly or take longer depending on TTL values and resolver caches. Repeatedly saving the same record does not make propagation faster.

Final validation checklist

Before declaring the configuration complete:

• [ ] The intended MX destinations are publicly visible.
• [ ] There is exactly one SPF record at each sending hostname.
• [ ] Every legitimate sender is included in the SPF design.
• [ ] All provider-issued DKIM selectors resolve.
• [ ] Test messages show DKIM signatures.
• [ ] DMARC exists at _dmarc, not at the root.
• [ ] SPF or DKIM passes with DMARC alignment.
• [ ] Bounce and complaint handling is active.
• [ ] DMARC reports are being reviewed.
• [ ] No API keys, SMTP passwords, or private keys were published.

A practical order of operations

For a new domain, I prefer this order:

1. Verify ownership with the email provider.
2. Publish DKIM.
3. Configure SPF for known senders.
4. Point MX to the receiving service.
5. Add DMARC with p=none.
6. Send and receive test messages.
7. Review headers and reports.
8. Tighten the DMARC policy gradually.

This order reduces the chance of enforcing a policy before authentication is actually working.

If you want a concise version you can keep beside your DNS dashboard, the public email DNS checklist on GitHub contains provider-neutral examples and an Amazon SES-specific companion guide.

What DNS provider or email service are you configuring? Share the record types—not credentials—in the comments, and I can help identify the usual pitfalls.