SPF, DKIM & DMARC Explained: A Practical Business Email Guide

Why these three records matter

SPF, DKIM and DMARC are separate controls, but they work best as a system. SPF tells a receiving server which infrastructure is allowed to send for a domain. DKIM adds a cryptographic signature so the receiver can verify that a message was signed by an authorized domain and was not altered in transit. DMARC connects those signals to the address people actually see in the From field and adds a policy for handling failures.

A domain can have a valid SPF record and still have deliverability problems if the visible From domain does not align with the authenticated sender. The same is true for DKIM: a signature can validate successfully while using a different organizational domain. DMARC is the layer that asks whether at least one authenticated mechanism also aligns with the visible sender.

SPF: authorize the right sending systems

An SPF record is published as a TXT record on the sending domain. It should include every platform that sends mail using that domain in the envelope sender or Return-Path. Typical examples include Microsoft 365, Google Workspace, a transactional email provider, a CRM, or a web server.

Avoid creating multiple SPF TXT records for the same hostname. SPF expects one policy. If you use several senders, they normally need to be combined into a single record. Also watch the SPF DNS-lookup limit: too many include mechanisms can cause a permanent error even when the record looks syntactically valid.

DKIM: prove the message was signed

DKIM uses a selector, such as selector1 or default, to locate a public key in DNS. The sending platform holds the private key and signs outgoing messages. The receiver retrieves the public key and validates the signature.

A common DKIM problem is publishing the record but forgetting to enable signing in the sending platform. Another is rotating a key without updating DNS. During troubleshooting, check both the message header for a DKIM-Signature field and the selector record in DNS.

DMARC: alignment, policy and reporting

DMARC is published at _dmarc.yourdomain.com. A monitoring policy such as p=none lets you collect data while you identify legitimate sending sources. Quarantine and reject policies tell receivers to treat unauthenticated, non-aligned mail more aggressively.

Move toward enforcement gradually. Before changing to quarantine or reject, confirm that newsletters, website forms, support tools, invoices and other legitimate systems are aligned. This reduces the risk of blocking your own mail while still improving anti-spoofing protection.

A safe implementation order

Start by inventorying every service that sends mail for your domain. Fix SPF so the authorized infrastructure is represented. Enable DKIM on every platform that supports it. Add DMARC in monitoring mode and review failures. Once legitimate senders are aligned, increase the policy gradually.

After changes, send real messages to multiple mailbox providers and inspect authentication results. DNS configuration is important, but deliverability also depends on reputation, content, complaint rates and recipient engagement.