Skip to main content
If you’re anything like me until a few weeks ago, you’ve heard of SPF, DKIM, and DMARC. You know they’re “email things.” You know that without them, your emails end up in spam. And that’s about where your knowledge stops. Most guides online take the helpful approach of “here’s how to set up SPF” without ever explaining why it exists. Congratulations, you’ve copy-pasted a DNS record. Do you understand what it does? Of course not. But it works, so who cares? Well, I finally cared enough to figure it out. And since you’re hosting applications and sending emails from them, you probably should too.

​
The fundamental problem with email

Here’s the thing about email that makes all of this necessary: it’s asynchronous and decentralized. When you visit a website, you initiate the connection. You type the domain, TLS kicks in, certificates get verified, and you know you’re talking to who you think you’re talking to. The whole authentication flow is baked into the protocol. Email doesn’t work that way. With email, some random server connects to your server and says “hey, I have a message for you from bank.com.” And your server has to decide whether to believe it or not. Without any verification, anyone could claim to be sending email from your bank, your employer, or that Nigerian prince who’s been trying to reach you. This is the problem SPF, DKIM, and DMARC try to solve.

​
SPF: “Is this server even allowed to talk?”

SPF (Sender Policy Framework) answers a straightforward question: is the server sending this email actually authorized to send email for this domain? It’s a DNS TXT record that says “these IP addresses and these servers are allowed to send email on behalf of my domain.” When an email arrives claiming to be from example.com, the receiving server checks the SPF record for example.com and verifies that the sending server is on the list. Think of it as a bouncer with a guest list. No list, no entry.

​
DKIM: “Has this email been tampered with?”

DKIM (DomainKeys Identified Mail) solves a different problem. Even if an email comes from an authorized server, how do you know the content hasn’t been modified in transit? DKIM adds a cryptographic signature to each email. You publish the public key in a DNS record, and every email gets signed with the private key. The receiving server can then verify that the email content is exactly what the sender intended. It’s like a wax seal on a letter. If the seal is broken, you know someone’s been messing with it.

​
DMARC: “What should I do when things fail?”

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties the other two together with a policy layer. It tells receiving servers what to do when an email fails SPF or DKIM checks. Your options are:
  • none: Do nothing (useful for testing)
  • quarantine: Put suspicious emails in spam
  • reject: Drop them entirely
You can enable reports alongside any of these policies. The reporting feature is genuinely useful. When other mail servers receive emails claiming to be from your domain, they check SPF and DKIM. If those checks fail, they send you a report. This means you get notified when someone is trying to spoof your domain, or when you’ve misconfigured something and your legitimate emails are failing authentication. Without DMARC reports, you’d have no idea that someone’s been sending phishing emails pretending to be you. With them, you can see exactly which IPs are sending mail on your behalf (legitimately or not) and whether your authentication is working as intended.

​
The practical bit: multiple email providers

Here’s where this gets relevant for actual application development. Most applications need to send different types of email. You have transactional emails (password resets, order confirmations) and marketing emails (newsletters, promotions). These typically come from different providers because transactional email services don’t want you sending bulk marketing through them. So you end up with at least two email providers, both needing to send from your domain. Your SPF and DKIM records need to authorize both. But here’s the pro tip: use different domains for different email types. Why? Reputation isolation. If your marketing provider does something weird (or gets used by spammers on the same IP range), it can tank your sender reputation. If that reputation is shared with your transactional emails, suddenly your password reset emails aren’t getting delivered. Your users can’t log in. Support tickets pile up. Your weekend is ruined. Keep transactional.example.com separate from marketing.example.com. If one reputation takes a hit, the other survives.

​
DKIM on Upsun

If you’re hosting on Upsun and want DKIM for emails sent from your application, the process is straightforward. Open a support ticket requesting DKIM activation for your domain, and support will provide you with the DNS records you need to add (a CNAME and TXT record). Once your DNS is configured, validation checks run every 15 minutes. After validation completes, Upsun automatically signs your outgoing emails with DKIM through SendGrid’s infrastructure. You don’t manage the keys yourself; it’s handled for you. See the Upsun email documentation for the full setup process.

​
Wrapping up

That’s it. Three DNS records:
  • SPF: Which servers can send email for your domain
  • DKIM: Cryptographic proof that emails haven’t been tampered with
  • DMARC: What to do when the first two fail
All three exist because email is fundamentally a “stranger walks up to you” protocol, and we need ways to verify they are who they claim to be. Unlike HTTPS, where you initiate the connection, email authentication is a series of workarounds for the fact that someone else is connecting to you. Now you actually know what those acronyms mean. You’re welcome.
Last modified on April 14, 2026