How SPF, DKIM and DMARC work together
Each record answers a different question, and receivers ask them in order.
- SPF (RFC 7208): may this server send mail for the domain in the envelope? You publish one TXT record on the domain listing the servers and services that send for it.
- DKIM (RFC 6376): which domain takes responsibility for this message, and did it arrive unchanged? The sending service signs the message; receivers check the signature against a public key in your DNS.
- DMARC (RFC 7489): did either check pass for the domain people see in the From address, and if not, what should happen? You publish a TXT record at
_dmarc.
Mailbox providers now ask for them directly. Google asks every sender for SPF or DKIM, and senders of more than 5,000 messages a day to Gmail accounts for SPF, DKIM and DMARC. Yahoo asks bulk senders for all three. The full list is in Gmail and Yahoo sender requirements.
SPF DKIM DMARC alignment, in plain words
SPF checks the envelope domain. DKIM checks the signing domain in d=. Neither looks at the From header people see. DMARC closes that gap: it passes only when SPF or DKIM passes and the authenticated domain lines up with the From domain.
In relaxed mode, the default for both adkim and aspf, mail.acme.com aligns with acme.com because they share an organizational domain. In strict mode, only an exact match counts.
d=mail.acme.com
d=mail.acme.com
The order to set them up
- List everything that sends as your domain. Your app, your marketing platform, your helpdesk, billing and HR tools.
- Publish one SPF record that covers them, and stay under 10 DNS-querying terms.
- Turn on DKIM for each sender. For tinyRelay that's one CNAME per sending domain.
- Publish DMARC with p=noneand a
ruaaddress, then read the aggregate reports. - Tighten the policy to
quarantine, thenreject, once every legitimate sender passes.
Setting up a sending domain with tinyRelay
Our team adds your sending domains during onboarding. You add one CNAME so your mail is DKIM-signed:
| Host | Type | Value |
|---|---|---|
tec1._domainkey.yourdomain.com | TypeCNAME | Valuetec1.dkim.tinyemail.com |
Then check it. PUT /domain/dns/check validates DKIM and SPF for a domain and returns a status for each, plus the records it expects to find.
curl -X PUT https://api.tinyemail.com/v1/relay/domain/dns/check \ -H "X-RELAY-ACCESS-TOKEN: $TINYRELAY_KEY" \ -H "Content-Type: application/json" \ -d '{ "domain": "acme.com" }' # 200 (shape from the docs) { "dkim": { "status": "Invalid", "dns": [{ "type": "CNAME", "name": "tec1._domainkey.", "value": "tec1.dkim.tinyemail.com" }] }, "spf": { "status": "Valid", "dns": [{ "type": "TXT", "name": "@", "value": "v=spf1 … include:_spf.tinyemail.com … -all" }] } }
Base URL from current site samples; confirm in the docs. Response shortened.
DMARC is yours to publish on your domain. To see all three records at once, run your domain through the free SPF, DKIM and DMARC checker.
What happens when authentication fails
A receiving server that refuses mail on authentication grounds shows up in tinyRelay as a BOUNCED event with bounce category 55, SPF/DKIM/DMARC: refused on authentication policy. The event's bounceDescription carries the receiving server's own words, which usually name the failing check. See the email bounce codes reference and how events reach you through signed webhooks.
Sources
- RFC 7208, Sender Policy Framework (SPF): datatracker.ietf.org/doc/html/rfc7208
- RFC 6376, DomainKeys Identified Mail (DKIM) Signatures: datatracker.ietf.org/doc/html/rfc6376
- RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC): datatracker.ietf.org/doc/html/rfc7489
- Google, Email sender guidelines: support.google.com/a/answer/81126
- Yahoo Sender Hub, Sender Best Practices: senders.yahooinc.com/best-practices
- tinyRelay docs, Validate DKIM and SPF for a domain: docs.tinyrelay.com/docs/tiny-relay/validate-dns