Email authentication

Email authentication uses three checks: SPF identifies authorized sending servers, DKIM signs messages so tampering can be detected, and DMARC tells receiving systems how to handle mail that fails.¹ The most common setup failure is putting the records in the wrong order.² Enable SPF and/or DKIM before DMARC. Enabling DMARC first will probably create delivery issues.^{3, 4} Build one layer, check that it works, then use the result to decide what needs fixing.

Know what you are setting up

Before changing DNS, know what each layer does. That gives you a direct way to diagnose a failed message.

SPF lists the mail servers allowed to send for your domain, and receiving systems compare the sending server's IP with that list.⁵

DKIM adds a cryptographic signature to outgoing messages. Receiving systems verify it against a public key published in DNS, which lets them detect changes made in transit.⁶

DMARC defines the policy receiving systems should follow when SPF or DKIM fails. It also reports who is sending mail as your domain.⁷

Build the records in order

1

Sending domain and sources

2

Publish SPF

3

Publish DKIM

4

Add DMARC

1. Sending domain and sources
2. Publish SPF
3. Publish DKIM
4. Add DMARC

Start with the sending identity. List the systems that send mail, publish the records they need, and add the receiver policy after the earlier checks are available.

Choose the sending domain and sources

List every system that sends mail using the domain, including normal business mail and outbound systems that send on its behalf. This keeps the SPF and DKIM setup aligned with the traffic you intend to send.

For cold email, send from a subdomain instead of the apex domain.⁸ Keep a list of the systems allowed to send as that domain, along with an owner and a documented sending path.

Publish SPF

Publish an SPF TXT record at the root of the domain. It identifies the authorized sending servers.⁹ Add it through the DNS provider that controls the domain. Providers often use different procedures for SPF and DKIM records, so follow the registrar's instructions or contact its support team when the publishing screen or record format is unclear.¹⁰

After publishing, confirm that the listed sources match the systems you intend to use. If a legitimate sender is missing, fix the sending inventory before adding the next layer.

Publish DKIM

Enable DKIM for each sending system that will sign mail. Publish its public key in a selector-based TXT hostname so receiving systems can find and verify the signature.¹¹

Confirm that the selector record exists for every intended signer and matches the domain and sending system you documented.

Add DMARC

Add DMARC only after the earlier authentication checks are available. Set it up with a DMARC DNS TXT record¹² at the _dmarc hostname.¹³

Choose what receiving systems should do when a message fails the required authentication checks. The options are reject, quarantine, or deliver the message.¹⁴ Receiving servers consult the DMARC record when mail from the domain fails SPF or DKIM, then apply the published action.¹⁵

Check that the setup holds

Validation has two parts: confirm that the records are published where receiving systems expect them, then see what happens to mail from each intended source.

Check the SPF record at the domain root, the DKIM record at the selector hostname, and the DMARC record at the _dmarc hostname. This gives you a first check before you investigate a message or report.

Send a test message from each documented sending path. Review the authentication information for a missing source, an unexpected sender, or a failed check. If a result is unclear, trace it back to the sending system and the record that should authorize or sign it.

Use DMARC reports to find possible authentication issues and malicious activity involving messages sent from the domain.¹⁶ Treat each report as both a source inventory and a failure notice. Reconcile legitimate sources with your SPF or DKIM setup, and investigate unfamiliar ones before changing the policy.

DMARC combines the checks. It requires alignment with SPF or DKIM, applies the published policy when both fail, and reports the result to the domain owner.¹⁷ A passing check in isolation does not settle the result for the whole message. Follow the report back to the source and correct the record or sending configuration that explains the failure.

What not to do

Avoid these mistakes:

• Do not enable DMARC before SPF and/or DKIM. Messages sent from the domain will probably have delivery issues when those checks are missing.⁴
• Do not stop at DKIM. DKIM alone cannot prevent spoofing of the domain, so SPF and DMARC still need to be configured.¹⁸
• Do not publish an isolated record and call the domain covered. SPF, DKIM, and DMARC need to work together for effective email authentication.¹⁹
• Do not guess the DNS provider's record procedure. Check its instructions or contact its support team when adding SPF or DKIM.¹⁰