Skip to content
Back to blog

E-mail Your Business Owns: SPF, DKIM and DMARC Without the Black Box

Published on April 14, 2026 · principale.dev

Why E-mail Feels Impossible to Move

Most companies do not stay with an e-mail provider because they love it. They stay because moving feels dangerous.

There are two locks. The first is data: years of mailboxes, shared addresses, aliases, contacts, calendars, invoices, contracts, and one old message that suddenly matters. A mailbox is an archive as much as an inbox. IMAP is the standard protocol for accessing and moving mailbox data between servers; its current specification is RFC 9051. Export still takes planning because mailboxes are large, labels do not always map cleanly, and people keep working during the move.

The second lock is reputation. A domain that has sent ordinary business mail for years has history. A new server, a wrong DNS record, or a rushed cutover can make legitimate invoices look suspicious. Mail migrations feel less like changing software and more like moving the front door while clients still knock.

Receiving servers ask three questions about every message. Is this server allowed to send for the domain? Was the message changed on the way? What should happen if the answers are bad?

SPF: Who Is Allowed to Send

SPF answers the first question. The domain owner publishes a DNS record listing which mail servers may send mail for that domain. When a receiving server gets a message, it checks the sending server against that published policy. RFC 7208 defines SPF as a way for domains to authorize hosts and for receivers to check that authorization.

Plain language: SPF is the guest list at the door. If your domain says only these servers may send mail, a random server elsewhere has a harder time pretending to be you.

SPF has limits. It checks the envelope sender used during delivery, not the address a person sees in the From header. Forwarding can break it. Without SPF, though, receivers have less evidence that your mail is legitimate.

DKIM: Was the Message Changed?

DKIM answers the second question. The sending server signs parts of the message with a private key. The public key lives in DNS. A receiving server uses that public key to verify that the signed parts still match. RFC 6376 describes DKIM as domain-level cryptographic signing for e-mail.

Plain language: DKIM is a tamper-evident seal. It does not make the message secret, and it does not prove the sender is honest. It proves that the domain named in the signature took responsibility for that message, and that the signed parts were not altered after signing.

That matters for invoices, password resets, order confirmations, and day-to-day client mail. If your provider controls the signing and the keys, authentication becomes another thing you must trust but cannot easily inspect.

DMARC: What Happens When Checks Fail

DMARC ties SPF and DKIM to the visible From domain and tells receivers what the domain owner wants done when checks fail. A DMARC policy can ask receivers to do nothing, quarantine suspicious mail, or reject it. DMARC was first specified in RFC 7489 as policy plus reporting built on SPF and DKIM alignment. That document is now obsolete, split across three Standards Track successors: RFC 9989 for the policy itself, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. Check the current specifications before changing a production policy.

Plain language: DMARC is the company rulebook. It says: if a message claims to be from our domain, but the authentication does not line up, treat it this way and report what you saw.

The reporting part turns authentication from folklore into evidence. You can see who sends for your domain, what passes, what fails, and when it is safe to make the policy stricter.

A DMARC Rollout You Can Follow

RFC 9989 (Section 5.1) describes the deployment path domain owners are expected to follow. It is a sequence, not a single record you publish once:

  1. Publish SPF and DKIM first, and confirm both produce a passing result for your legitimate mail streams.
  2. Set up a mailbox for aggregate reports, then publish a DMARC record with p=none and an rua tag pointing at it. RFC 9989 calls this “Monitoring Mode”: receivers change nothing about how they handle your mail, but they start sending you daily reports of what they saw.
  3. Collect and read the reports. The RFC’s own reasoning: starting at p=none “takes advantage of DMARC’s aggregate reporting function, with the Domain Owner using the reports to audit its own mail streams’ authentication configurations” — so you catch a forgotten sending service before you start blocking mail.
  4. Fix whatever the reports show, such as a third-party mailer sending on your behalf without valid SPF or DKIM alignment.
  5. Move to enforcement (p=quarantine or p=reject) only once you’re confident every legitimate stream authenticates. The RFC is candid that this can take a while: “it may take many months of consuming DMARC aggregate reports before a Domain Owner reaches the point where it is sure that it is properly authenticating all of its mail.”

A monitoring-mode record, taken directly from the worked example in RFC 9989 Appendix B.2.1:

_dmarc  IN TXT ( "v=DMARC1; p=none; "
                 "rua=mailto:dmarc-feedback@example.com" )

Two syntax notes worth knowing before you edit a production record: tags are separated by ;, and unknown tags or trailing syntax errors are ignored rather than rejected, so a typo in one tag will not necessarily invalidate the whole record — but it also will not do what you intended.

If you’ve read older guidance about a pct tag for ramping enforcement up gradually (a percentage of mail subjected to the stricter policy), that tag existed in the original RFC 7489 and was removed in RFC 9989. It covers some of what pct did through a t (test) tag: with t=y, receivers are asked to apply a policy one level below what you published — a reject record is treated as quarantine, a quarantine record as none — while you watch reports before committing fully.

SPF: ~all vs -all, and the 10-Term Limit

The last mechanism in an SPF record is usually all, and its qualifier decides what happens to mail from servers not on the list. Per RFC 7208:

  • ~all (softfail): “a weak statement… that the host is probably not authorized” (Section 2.6.5). Receivers “SHOULD NOT reject the message based solely on this result” (Section 8.5) — softfail is a signal for closer scrutiny, not a block.
  • -all (fail): “an explicit statement that the client is not authorized to use the domain” (Section 2.6.4). A receiver that rejects on fail is told to use SMTP code 550 (Section 8.4).

A conservative path is to start with ~all while you confirm every legitimate sender is listed, then move to -all once you’re sure — the same none-then-enforce logic as the DMARC rollout above.

SPF also caps how much DNS work a check may trigger, and it does so by counting terms rather than queries: an evaluation may use at most 10 of the DNS-querying terms, which are the include, a, mx, ptr and exists mechanisms and the redirect modifier. Past that the check fails with a permerror (Section 4.6.4). A single term can still cause more than one query, so the real query count can exceed ten. An SPF record built from several include: statements (common when you use more than one outbound mail service) can hit this limit without anyone noticing until mail starts failing.

What Owning the Server Changes

Owning business e-mail means the domain, mailbox data, DNS policy, and backups stay under your control.

A Mailcow server on infrastructure you control keeps mailboxes where you decide. Your domain remains yours, and your archive stays portable over standard mail protocols. The settings stay visible instead of hiding behind a provider’s “deliverability” switch. Mailcow generates the DKIM key, and SPF, DKIM and DMARC are DNS records your company publishes with its domain provider. Mailcow tells you what they should contain; you or your DNS operator make the actual changes, or, for a connected Cloudflare zone, the panel publishes them after your approval. If a hosting provider stops fitting, the server and the data can move.

E-mail does need care. DNS records must be correct, keys rotated when needed, backups checked, and sender reputation watched. That recurring work is yours: you trigger the updates and check the records yourself.

Your business e-mail should be boring: clients can reach you, invoices arrive, old messages can be found, and no vendor owns the only usable archive.

principale.dev installs open-source tools like these on a server you own. Every install is free. See how it works.