Why authentication decides deliverability
Receiving mail servers have to guess whether a message claiming to be from your domain really is. Without authentication records they are guessing from reputation alone, and the safe guess for an unknown sender is the spam folder.
SPF, DKIM and DMARC turn that guess into a check. They are DNS records rather than server configuration, and setting them up correctly is the single highest-impact thing you can do for deliverability.
SPF: which servers may send
An SPF record is a DNS TXT record listing the servers authorised to send mail for your domain. A receiving server compares the sending address against that list.
The common mistakes are having more than one SPF record on a domain, which invalidates both, and exceeding the ten DNS lookup limit by chaining too many include statements. Keep the record to a single line and as few includes as you can.
DKIM: proof the message was not altered
DKIM attaches a cryptographic signature to each outgoing message. The public key lives in DNS, so the receiver can verify that the message really came from your domain and was not modified in transit.
Your sending service generates the key pair and gives you a record to publish. The main thing to get right is publishing it under the exact selector the service expects.
DMARC: what to do when a check fails
DMARC ties the other two together. It tells receiving servers what to do with mail that fails SPF and DKIM, and it asks them to send you reports about what they saw.
- Publish a DMARC record in monitor mode first, which asks for reports without affecting delivery.
- Read the reports for a few weeks and identify every legitimate source sending as your domain.
- Fix anything legitimate that is failing.
- Move the policy to quarantine, then to reject once you are confident.
Going straight to a reject policy before reading reports is how organisations discover they have been silently blocking their own invoicing system.
Alignment is the part people miss
DMARC requires not just that SPF or DKIM passes, but that the domain it passed for matches the domain in the visible From address. A message can pass SPF for the sending service’s own domain and still fail DMARC because that domain is not yours.
This is why sending services ask you to verify a domain and publish records under it, rather than just letting you send.
Beyond the records
- Send from a subdomain dedicated to the type of mail, so transactional reputation is separate from marketing reputation.
- Warm up a new sending address gradually rather than starting at full volume.
- Process bounces and remove addresses that hard bounce.
- Make unsubscribing easy, because complaints damage reputation faster than almost anything else.
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- Taking Full Ownership of a Cloud Account After Handover
- What Cloud Credits Actually Are, and How They Behave
- Amazon SES vs Kamatera: Which Cloud Account Should You Buy?
- VPS or Managed Platform: Which One Your Project Needs
Frequently asked questions
No. A domain must have exactly one SPF record. Two records cause both to fail, so multiple senders have to be combined into a single record.
SPF and DKIM together, then DMARC in monitor mode once both are passing.
They are necessary but not sufficient. Authentication lets receivers identify you reliably; reputation is then built by sending mail people want.
