Reference

Email authentication

What SPF, DKIM and DMARC do—and what they do not prove.

Email authentication helps receivers check whether a message is authorized to use a domain. It does not prove that the person writing it is honest, that a link is safe or that an invoice is legitimate.

The three checks

CheckPurpose
SPFChecks whether the sending server is authorized for the envelope sender domain.
DKIMVerifies a cryptographic signature using a published domain key.
DMARCChecks alignment with the visible From domain and publishes a failure policy.

MailMoose’s setup checklist supplies the relevant DNS records for its configured providers. Preserve existing policies and other mail services when updating them.

Reading results

Messages can show authentication results when the receiving provider supplies them. A passing result is useful evidence about domain authentication, not proof of a trusted person. Missing results are not a pass.

Failures deserve attention, especially for payments or credential requests. Forwarding can legitimately break SPF; verify unexpected requests through a separate trusted channel.

DMARC policy

A suggested p=none policy monitors rather than requests rejection. p=quarantine requests suspicious treatment for failures; p=reject requests rejection. Receivers apply their own handling.

Do not replace an existing policy blindly or tighten it before legitimate senders are aligned. DMARC reporting also requires a reporting address/configuration; p=none alone does not send you reports.

See DNS records explained.

Last updated 2026-10-20