deploy notes
Websites

SPF, DKIM and DMARC explained for a website owner

Understand which domain SPF checks, what DKIM signs and how DMARC connects authentication to the From address readers see.

Beginner guide6 min read
In this guide

SPF checks whether a sending server is authorized for a domain used during mail delivery. DKIM checks a signature attached by a sending service. DMARC checks whether a passing result belongs to the domain in the From address your reader sees, and publishes a policy for failures.

For a website owner, the useful first step is to list every service sending mail for your domain: the business mailbox, newsletter platform and any website notification service. They may need different settings even when their messages all appear to come from the same domain.

This explanation will help you understand those settings and identify which provider instructions you need. It does not supply DNS values to paste into your domain.

Start with the three identities in a message

The visible From address might be hello@studio.example. Behind that message is an envelope sender, an address used during delivery and for handling bounces. A sending service may use a different domain for it. A DKIM signature can name a third domain: the signing domain.

Those differences are normal. The question is whether the authenticated identity connects correctly to the visible From domain.

Mechanism What it checks What it does not establish by itself
SPF The sending server’s IP address against the envelope-sender domain’s published authorization. That the visible From domain is authorized.
DKIM A cryptographic signature, identifying a signing domain and covering selected message content. That the signing domain matches the visible From domain.
DMARC A passing SPF or DKIM result aligned with the visible From domain. That the message is wanted or will reach the inbox.

SPF: which servers may use the envelope-sender domain

Sender Policy Framework lets a domain publish authorized senders in DNS, the system that holds a domain’s records. For ordinary messages, the receiver checks the envelope-sender domain, also called the SMTP MAIL FROM domain. It does not simply look up the address displayed in your email app. SPF also has rules for the server’s HELO identity, including messages with an empty envelope sender.

Your provider tells you which SPF setting it needs and at which domain. If multiple services share one envelope-sender domain, their authorization must be represented in that domain’s single SPF record. Adding a second SPF record at the same name is not a way to combine providers. RFC 7208 defines the checked identities and record rules.

Forwarding can affect SPF because the server delivering the forwarded message may not be one of the original domain’s authorized senders. That is one reason a domain owner should not treat SPF alone as proof that every mail path is ready.

DKIM: a signature from a sending domain

DomainKeys Identified Mail adds a digital signature to a message. The sender keeps the private signing key; the receiver uses a public key published through DNS to check it. The signature’s d= value identifies the signing domain. Its selector helps the receiver find the right public key.

A valid signature confirms that the signed content verifies under that key. It does not encrypt the email or certify that its claims are true. The sender must actually sign outgoing messages; a DNS key sitting unused does not do that. RFC 6376 explains DKIM’s scope.

Different sending services can use different selectors on the same domain. Use each service’s current instructions for its key or DNS pointer, rather than copying a key from another account or guide.

DMARC: connect the result to the visible From domain

Domain-based Message Authentication, Reporting, and Conformance adds alignment: a relationship between the authenticated domain and the visible From domain. A message passes DMARC when SPF passes and aligns, or when a valid DKIM signature aligns. Both do not have to pass for that individual DMARC result.

With strict alignment, the domains match exactly. Relaxed alignment allows domains within the same organizational domain. For example, mail.studio.example and studio.example can align in relaxed mode. Google’s DMARC reference explains the two modes.

Consider these invented examples, all with visible From hello@studio.example and an applicable DMARC policy record:

Authentication result DMARC result Why
SPF passes for sender.example; no valid DKIM signature. Fail The passing domain does not align with studio.example.
SPF passes for sender.example; DKIM passes with d=studio.example. Pass The DKIM result aligns exactly.
SPF fails; DKIM passes with d=studio.example. Pass One passing, aligned mechanism is sufficient.

These examples illustrate the alignment rule in the DMARC standard, RFC 9989. They are not delivery results from a configured domain.

A policy is not an inbox guarantee

A DMARC policy can express no special handling preference (p=none), ask for suspicious treatment (p=quarantine), or ask for rejection (p=reject) when authentication does not align. Receivers apply their own handling decisions. Aggregate reports, when requested and supplied, help reveal which sources use your domain and how authentication is behaving.

Start by accounting for legitimate senders before considering stricter enforcement. A forgotten booking system or website form can be affected alongside forged mail. Google’s DMARC guidance recommends beginning with monitoring and reviewing results before enforcement.

Authentication is only one part of delivery. Recipient-provider rules also address message formatting, complaints and sending practices. Gmail’s sender guidelines illustrate why a DMARC pass is not a promise of inbox placement, and why configuring both SPF and DKIM still matters even though DMARC can pass through either.

Make a sender list before touching DNS

For each service, record the visible From domain, its envelope-sender domain if documented, its DKIM signing domain, and the official authentication guide. Include normal mailbox replies, newsletters and automatic website messages. If you cannot identify a sender’s domains, ask its provider before changing an existing record.

You have reached this guide’s result when you can explain which identity each check uses and point to instructions for every sender on your list. Configuring and verifying those senders is the next task; no new email product is needed merely to understand the three mechanisms.

← Back to website guides