Email Deliverability: DKIM, SPF, and DMARC Explained

Getting your email delivered is harder than sending it. A message that passes through Postfix without errors can still end up in spam — or silently dropped — because inbox providers grade every incoming message on its authentication record. This post explains the three standards that determine that grade.

Why authentication matters

Email was designed in an era with no identity layer. Any server can send a message claiming to be from ceo@yourbank.com. DKIM, SPF, and DMARC are retrofitted solutions that let a legitimate sender prove their domain is theirs.

SPF: who is allowed to send

An SPF record is a TXT record at your domain root that lists the IP addresses and services permitted to send mail from it:

v=spf1 include:_spf.rovela.dev ~all

The ~all softfail means "other senders are suspicious"; -all means "reject anything else." When you add your domain in Rovela, we publish the correct include: entry for you.

Limitation: SPF only checks the envelope-from (the SMTP MAIL FROM), not the From: header the reader sees. That is why SPF alone is not enough.

DKIM: a cryptographic signature

DKIM attaches a signature to every message using a private key held by your sending service. The public key lives in DNS:

rovela._domainkey.acme.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN..."

Receiving servers fetch that record and verify the signature. If it matches, the message provably came from someone who controls your domain. A tampered message fails verification.

Rovela generates a 2048-bit RSA key pair per domain. The private key never leaves our infrastructure; the public key is the DNS record we ask you to add.

DMARC: the policy that ties them together

DMARC tells receivers what to do with messages that fail SPF and DKIM, and where to send reports:

_dmarc.acme.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@acme.com"

The p= value progresses from none (observe and report) to quarantine (spam folder) to reject (refuse delivery). Start with none, read the aggregate reports for a few weeks, then tighten.

Why p=reject matters: when your domain publishes p=reject and a phishing email fails DKIM and SPF, Gmail and Outlook will reject it outright rather than delivering it to your customers.

The practical order

1. Add your domain in Rovela — we generate the three DNS records.
2. Publish all three at your DNS provider.
3. Verify in the dashboard. Rovela tests each record and shows the live result.
4. Set your DMARC policy to none and add a rua report address.
5. After two weeks of clean reports, move to quarantine, then reject.

Common mistakes

Mistake	Effect
Multiple SPF records for the same domain	Receivers take the last one and ignore the rest; legitimate mail fails
DKIM key shorter than 2048 bits	Some providers consider it weak and downgrade the score
Skipping DMARC entirely	SPF and DKIM have no policy to back them up; spoofing still works
Going straight to p=reject	Misconfigured forwarding chains fail and drop legitimate mail

Rovela handles key generation and rotation automatically. The DNS records are the part that only you can control.