Getting Your Email Delivered: SPF, DKIM, DMARC, and a Safe Cutover

Getting Postfix and Dovecot running, as covered in the previous post, gets you a server that can send and receive mail. It tells you nothing about whether that mail actually reaches an inbox instead of getting quietly filtered into spam. That's a completely separate problem, and understanding it properly is what separates a mail server that technically works from one that's actually usable.

This post explains the three DNS records that control deliverability, why each one exists, and a safe way to switch a live domain over to a new mail server without losing any real mail along the way.

Three records, three different jobs

It helps to understand what problem each of these is actually solving, rather than treating them as magic incantations to copy into DNS.

SPF (Sender Policy Framework) answers one specific question a receiving server asks: "is this IP address allowed to send mail claiming to be from this domain?" It's a DNS TXT record listing authorized senders. A basic one looks like this:

v=spf1 ip4:YOUR_SERVER_IP ~all

The ~all at the end means "soft-fail anything not explicitly listed" — treat it as suspicious rather than reject it outright. That's the sensible default while you're building confidence in your setup; you can tighten it later.

DKIM, which we set up in the previous post, proves a message wasn't altered in transit and really was signed using a key associated with your domain. The public half of that key lives in DNS at default._domainkey.yourdomain.com.

DMARC ties SPF and DKIM together and tells receiving servers what to do when a message fails either check:

v=DMARC1; p=none

p=none means "don't take any drastic action yet, just note failures" — the right policy to start with. Once you're confident every legitimate way you send mail (including any third-party tools sending on your behalf) is properly authenticated, you can tighten this to quarantine or eventually reject.

Testing before you touch anything live

mail-tester.com is the fastest way to check all of this at once. It gives you a temporary email address; you send a test message to it from your new server, and it reports back on SPF, DKIM, DMARC, spam-filter heuristics, and reverse DNS — with a score out of 10 and specific, actionable advice for anything short of perfect. A correctly configured setup, following the steps in this series, should reasonably get you close to a perfect score.

Test this before your new server is handling any real mail. It costs nothing and takes a few minutes, and it turns "I think this is configured correctly" into an actual, verified answer.

The safe way to cut over a live domain

If you already have real mail flowing through an existing provider, this is the part that actually matters most — and it's the part most guides skip entirely. Switching your MX record carelessly can drop real incoming mail mid-transition without any obvious warning sign.

Here's an approach that avoids that risk, by making every step independently reversible until the very last one:

1. Build the entire new stack first, with your existing provider still handling all live mail, completely untouched. Nothing about this step is visible to anyone sending you mail.
2. Add your new server's IP to your SPF record alongside your existing provider, not instead of it — for example, v=spf1 include:_spf.oldprovider.com ip4:YOUR_NEW_IP ~all. This is purely additive; it doesn't change anything about how mail currently flows.
3. Send a real test message through the new server to a mail-tester.com address and confirm a strong score before going any further.
4. Only once that's proven, switch your MX record from your old provider to your new mail server. This is the actual moment incoming mail starts routing to the new system — and by the time you reach it, you already know the destination works correctly.
5. Once you've confirmed the new server is handling mail correctly, remove your old provider from SPF, and update any application settings (like an outbound-email configuration in a web app) to send through the new server instead.

The key idea is ordering: you never make an irreversible change until you've already verified, independently, that what you're switching to actually works. That's the entire difference between a cutover nobody notices and a scramble to figure out where a customer's email went.

Where this leaves you

At this point you have a mail server you installed yourself, configured to sign and authenticate its own mail correctly, verified against a real deliverability test, and a safe process for pointing a live domain at it whenever you're ready. That's the whole system — not magic, just three well-understood pieces of software and a handful of DNS records, each doing exactly one clearly-defined job.