Guides
SPF, DKIM and DMARC explained
Three DNS records decide whether the world trusts email from your domain. Here is what each one does, what it looks like, and how to set them up correctly.
Email was designed without any built-in way to prove who sent a message. Anyone can type any address into the From line. SPF, DKIM and DMARC are the three standards that close that gap — and today they are the difference between mail that reaches the inbox and mail that is junked or refused.
All three are published as DNS TXT records on your domain. Your email host provides the values; you (or your host, if it manages your DNS) publish them.
SPF — who is allowed to send
Sender Policy Framework (SPF) is a list of the servers allowed to send mail for your domain. A receiving server looks up the SPF record of the domain in the message's envelope sender and checks whether the connecting server's IP address is on the list.
A typical record looks like v=spf1 a mx ip4:203.0.113.10 -all. The ending matters: -all means "reject anything not listed", ~all means "treat it as suspicious". A domain must have only one SPF record, and it may trigger at most ten DNS lookups — so when you add services such as a newsletter tool, merge them into the same record.
DKIM — a signature on every message
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing message. The mail server signs with a private key; the matching public key is published in DNS at selector._domainkey.yourdomain.com. The receiver fetches the key, checks the signature and learns two things: the message really came from a server authorised by your domain, and nobody changed it on the way.
The selector is just a label that lets one domain have several keys. In BigMail.az it is always dkim, so your record is at dkim._domainkey.yourdomain.com and the console shows its value even before you publish it.
DMARC — the policy that ties it together
Domain-based Message Authentication, Reporting and Conformance (DMARC) checks that SPF or DKIM passes for the same domain the reader sees in the From address — this is called alignment — and tells receivers what to do when it does not.
The record lives at _dmarc.yourdomain.com, for example v=DMARC1; p=none; rua=mailto:[email protected]. The p tag is the policy: none (monitor only), quarantine (send to spam) or reject (refuse). The rua address receives daily aggregate reports showing who sends mail using your domain.
How to roll them out safely
1. Publish SPF and DKIM first, using the values from your email host, and confirm they verify.
2. Publish DMARC with p=none and a reporting address. Read the reports for a few weeks to find any service sending on your behalf that is not yet authenticated — invoicing tools, website forms, newsletter platforms.
3. Fix those senders, then move to p=quarantine and finally p=reject. At that point anyone forging your domain is stopped at the receiving server.
Why it matters more every year
Since 2024 the largest mailbox providers require bulk senders to authenticate with SPF and DKIM and to publish a DMARC record, and they increasingly filter unauthenticated mail from everyone else. Authentication will not make poor content land in the inbox, but its absence will send good mail to spam.
It also protects your customers: with DMARC at reject, a fraudster cannot send a fake invoice "from" your domain.