Sender authentication (SPF, DKIM, DMARC): definition and practice

Definition

Sender authentication combines mechanisms with different jobs. SPF lets a receiver check whether sending infrastructure is authorised for the domain being evaluated. DKIM provides a cryptographic signature associated with a signing domain. DMARC evaluates alignment with the visible From domain and supplies a domain policy and reporting framework. These checks concern domain identity and handling rather than business suitability.

Authentication does not establish consent, recipient interest, message accuracy, or permission to conduct an outreach campaign. It also does not guarantee inbox delivery. A correctly signed message can still be unwanted, filtered, or sent to an inappropriate recipient. Keep technical authentication, communication eligibility, and campaign approval as distinct controls rather than treating successful DNS configuration as completion of the outreach process.

In origination work

Before approved outreach, assess authentication on the actual sending path and inspect receiver results where available. A configuration record alone does not show that every sending service is using it correctly. Monitor delivery outcomes separately from authentication results and preserve suppression instructions across imports. Docket's outreach is optional and requires client approval of messaging and each target; authentication supports the technical sending setup but does not replace those approvals or the applicable communication review for the intended channel and recipient.

What each protocol does

SPF, the Sender Policy Framework, lets a domain publish in DNS the servers permitted to send mail for it; a receiving server checks the connecting server against that list. DKIM, DomainKeys Identified Mail, adds a cryptographic signature to each message, which a receiver verifies using a public key published in DNS. DMARC builds on both: it tells receivers what to do when a message fails alignment between the visible From domain and the SPF or DKIM domain, and it requests reports. Each is defined in a public IETF document.

They solve different problems. SPF validates the path, DKIM validates message integrity and signing domain, and DMARC ties these to the domain the reader sees and sets policy. A message can pass SPF and still fail DMARC if the domains do not align, which is a common configuration error when sending through third-party platforms.

Why mailbox providers require it

Large mailbox providers publish requirements for bulk senders. Google's sender guidelines require authentication, a low rate of spam complaints, and easy unsubscription for senders of large volumes, and Yahoo and Microsoft have published comparable expectations. Specifics change, so check the current text of each provider's guidance rather than relying on summaries. The direction has been consistent: stricter authentication and clearer sender accountability.

Industry bodies publish best practices as well. The Messaging, Malware and Mobile Anti-Abuse Working Group collects documents on authentication, abuse handling and sender practices. These are voluntary, but they reflect what receiving networks tend to expect.

Setting it up and checking it

Use a dedicated sending domain or subdomain for outreach, so reputation damage does not spill over to the main domain. Publish SPF listing only the services actually used, enable DKIM signing for each, and publish DMARC starting with monitoring and moving to enforcement once reports show legitimate mail is aligned. Check records with a DNS lookup and send test messages to see the authentication results in the headers.

Monitor continuously. DMARC aggregate reports show who is sending as your domain, which can uncover forgotten services or abuse. Authentication is necessary and not sufficient: it proves identity, not that the message is welcome. Reputation, complaint rates and content determine whether authenticated mail reaches the inbox.

Inbox placement — Whether a delivered email appears in the recipient's inbox rather than another folder or filtering destination.
Suppression list — A maintained set of records that prevents contact for specified recipients, companies, or communication scopes.
Origination — The work of identifying, researching, and developing potential acquisition opportunities against a mandate.

Sources and further reading

RFC 7208 — Sender Policy Framework (SPF), IETF. Which hosts may send for a domain, published in DNS.
RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures, IETF. Cryptographic signing of a message by the sending domain.
RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC), IETF. Alignment, policy and the aggregate reports that tell you who is sending as you.
Email sender guidelines, Google Workspace Admin Help. The receiving side's published requirements, including authentication and the spam-rate threshold for bulk senders.
Outlook.com sender requirements and troubleshooting, Microsoft. The equivalent rules for the other half of corporate inboxes.
Sender best practices, Yahoo Sender Hub. A second large provider's authentication and complaint-rate expectations.
Published documents and best common practices, M3AAWG. Industry best practice on sending reputation, list hygiene and abuse handling, written by the operators.

To apply these distinctions to your own acquisition criteria, discuss your research brief or inspect the demo platform.