Three IETF standards decide whether a founder's email arrives

The workload

A one-person SaaS sending transactional email — receipts, password resets, notifications — needs its messages to reach an inbox rather than a spam folder. Getting there means publishing DNS records and configuring a sending service to sign outgoing mail, work usually done once per domain and revisited when a mail provider changes. Three Internet Engineering Task Force standards define the mechanisms, verified from their own texts: RFC 7208 for the Sender Policy Framework (SPF), RFC 6376 for DomainKeys Identified Mail (DKIM), and RFC 7489 for Domain-based Message Authentication, Reporting and Conformance (DMARC). None requires a paid product; the workload is DNS-record configuration, not procurement.

What the documents show

RFC 7208's abstract states, verified, that SPF lets an administrative domain 'explicitly authorize the hosts that are allowed to use their domain names,' so a receiving server can check the sender against a published list. RFC 6376's abstract states, verified, that DKIM 'permits a person, role, or organization that owns the signing domain to claim some responsibility for a message' by attaching a signature a receiver verifies against a public key in DNS. RFC 7489 defines DMARC, verified, as 'a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting,' but is explicit that DMARC does not authenticate mail alone: a message satisfies it only when SPF or DKIM produces a result aligned with the visible From address. DMARC layers on the other two standards' results; it does not replace either.

The operating cost

None of the three RFCs sets a fee; publishing a DNS TXT record and a DKIM key costs nothing beyond the time to add them. The recurring cost is maintenance: adding SPF entries whenever a new sending service is adopted (SPF's own 10-lookup limit, stated in RFC 7208, is a common reason misconfigured records silently fail once several services are named) and rotating DKIM keys periodically, a practice mail platforms recommend but that sits outside what these documents require.

The stop condition

None of the three RFCs states when a sender is done. This is an editorial stop condition: a domain has reasonable coverage once SPF names every sending service, DKIM signs mail from each, and a DMARC record exists at least in monitoring mode so failures become visible before rejection — after which the remaining work is reading DMARC's own aggregate reports, not re-reading the standards.

• Does the SPF record name every current sending service, including ones added after the record was first written?
• Is DKIM signing enabled on the same services SPF authorizes?
• Is a DMARC policy actually published, and are its reports being read by anyone?

The three standards are free to implement and narrow in scope: each checks one specific thing, and DMARC's own text says it depends on the other two's results rather than replacing them.