SPF, DKIM and DMARC explained: why your letters land in spam and how to fix it.

A letter from director@yourcompany.az can be written by anyone. Nothing in the basic email protocol stops a stranger from putting your address in the "From" line. That is why the large mail services — Gmail, Outlook, Yahoo and the corporate filters behind them — check every incoming letter against three records in the sender's DNS: SPF, DKIM and DMARC. A domain without them looks exactly like a domain someone is impersonating, and its mail goes to spam or is refused.

This guide explains what each record does in plain words, which ones you need, how to roll them out without losing legitimate mail, and how to check the result.

The short version

• SPF — a list of servers that are allowed to send mail for your domain.
• DKIM — a cryptographic signature on every letter, verified with a public key in your DNS.
• DMARC — your instruction to receivers: what to do when a letter fails SPF and DKIM, and where to send reports.

All three are TXT records in your domain's DNS. You publish them once; the receiving servers read them on every letter.

SPF: who may send in your name

SPF (Sender Policy Framework) is one TXT record on the root of your domain. It starts with v=spf1 and lists the senders you trust:

v=spf1 +a +mx +ip4:203.0.113.10 include:_spf.example.net ~all

How to read it:

• +a and +mx — the servers in your domain's A and MX records may send.
• ip4: — a specific IP address may send.
• include: — the senders listed in another domain's SPF may send (this is how a mail service or a newsletter tool is added).
• ~all at the end — everything else is suspicious (soft fail). -all means "refuse everything else".

Three rules that prevent most SPF problems:

1. One SPF record per domain. Two v=spf1 records make the check fail for every letter. If a second service needs to send as you, add its include: to the existing record.
2. At most 10 DNS lookups. Each include:, a and mx costs a lookup. Too many and the record breaks with a "permerror". Remove services you no longer use.
3. SPF checks the envelope, not the visible "From". That is why SPF alone is not enough — DMARC ties it to the address people see.

DKIM: a signature on every letter

DKIM (DomainKeys Identified Mail) signs each outgoing letter with a private key that stays on the mail server. The matching public key is published in your DNS under a selector:

selector._domainkey.yourcompany.az   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBg..."

The receiving server reads the selector from the letter's signature, fetches the public key from DNS and checks that the letter was not changed on the way and was signed by a server that holds your private key.

What matters in practice:

• You never create the key yourself. The mail service generates it and gives you the exact record to publish. Copy it as it is — the value is long and a single missing character breaks it.
• Each sending service has its own DKIM. Your mailboxes, your newsletter tool and your CRM each sign with their own key under their own selector. They do not conflict.
• A forwarded letter keeps its DKIM signature as long as nobody changes it, which is why DKIM is the check that survives forwarding when SPF does not.

DMARC: your policy and your reports

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.yourdomain:

_dmarc.yourcompany.az   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.az"

It does two jobs:

• Alignment. A letter passes DMARC only if SPF or DKIM passes for the same domain that people see in the From line. This is what finally stops someone from sending as director@yourcompany.az from their own server.
• Policy and reports. p= tells receivers what to do with letters that fail: none (deliver, just report), quarantine (put in spam) or reject (refuse). rua= is the address where receivers send daily summary reports.

Rolling out DMARC without losing mail

Most companies send mail from more places than they remember: the website's contact form, an accounting program, a newsletter tool, an old CRM. Turning on a strict policy on day one can silently block those letters. Go in stages:

1. p=none for about two weeks. Collect the reports and see which servers send mail in your name.
2. Add the legitimate senders you found to SPF (or set up their DKIM).
3. p=quarantine for another two weeks — failing letters go to spam, so mistakes are visible but recoverable.
4. p=reject when the reports are clean.

Which records does your domain need?

Large mail services have tightened their rules for senders in recent years: letters from domains without SPF, DKIM and DMARC are increasingly filtered or refused, especially when a company sends in volume. Publishing all three is no longer optional for business mail.

Setting it up with Rivervo

Business email

You don't need to compose any of the values. Open Mail → your domain in the panel. The page lists the exact MX, SPF and DKIM records (required) and DMARC (recommended), each marked Found or Not found yet. Copy them to wherever your domain's DNS lives:

• domain on Rivervo nameservers with a Rivervo website → Websites → your site → DNS zone;
• domain registered at Rivervo with other DNS → Domains → your domain → DNS records;
• elsewhere → at your registrar or DNS host (on Cloudflare: DNS only).

Then click I've added the records — check. The panel re-checks every 5 minutes on its own. Step-by-step setup of the mailboxes is in our business email guide.

Mail on the website hosting

For mailboxes that come with a hosting plan: Websites → your site → Mailboxes → Delivery shows the mail records of each domain — SPF, DKIM and MX — and marks what needs fixing. When the domain is on Rivervo nameservers, Fix sets the missing records up for you. DMARC you add yourself in the DNS zone as a TXT record named _dmarc.

More detail, including verification commands, is in the help article SPF, DKIM, DMARC.

How to check the result

• From a terminal:

dig +short TXT yourcompany.az | grep spf
dig +short TXT _dmarc.yourcompany.az

• With a test letter. Send a letter to a mail-testing service that gives you a temporary address and a report. It shows whether SPF, DKIM and DMARC passed and why not if they failed.
• In the received letter itself. In Gmail, open a letter you sent → Show original: the header shows SPF: PASS, DKIM: PASS and DMARC: PASS.

Common errors and what they mean

"SPF permerror". Two SPF records, or more than 10 lookups. Merge into one record and remove services you no longer use.

"DKIM fail" or "body hash did not verify". The public key in DNS does not match the key the server signs with — usually a value pasted with a missing piece, or an old key left after changing providers. Copy the record again from the panel.

"DMARC fail" although SPF passes. SPF passed for a different domain than the one in the From line (typical for a newsletter tool sending on its own domain). Set up that tool's DKIM for your domain.

"Letters still go to spam." Authentication is necessary but not sufficient. The content of the letter, how many recipients open it and the sending pattern also matter. Bulk mailings belong in a dedicated sending service, not in personal mailboxes.

Common questions

Can I have SPF, DKIM and DMARC if my domain is registered elsewhere? Yes. The records live in the DNS of the domain, wherever it is managed. The registrar does not matter.

Do I need DMARC if I only receive mail? Yes. Without DMARC anyone can send letters in your name, and your customers' filters have no instruction to stop them.

Will p=reject block my own letters? Only letters that fail both SPF and DKIM for your domain. That is why you start with p=none and read the reports first.

How long do changes take? Usually minutes on fast DNS, up to a few hours when old values are cached. See why DNS takes time.

Do I need to repeat this when I add a mailbox? No. The records are per domain, not per mailbox. You set them once for each domain.