Here’s a bug that catches almost everyone the first time they set up email on their own domain. It’s worth walking through, because the obvious fix is aimed at completely the wrong record.
The setup
Picture this. You’ve set up email for your domain. Receiving works perfectly. Then you add an outgoing relay, a service that sends your mail for you, because your server can’t send directly. (Oracle, I’m looking at you. Long story.)
Everything seems fine. Then someone mentions your email went to their spam folder. Then someone else. A few messages don’t arrive at all.
The obvious suspect
Email problem? Check the email record. The one everyone has heard of is the MX (Mail Exchanger) record, so that’s where most people go first.
You check it. It points to your server. It’s correct. You check it again, because surely. Still correct. You start to wonder if the internet is broken.
The internet isn’t broken. You’re looking at the wrong half of the system.
Receiving and sending are different jobs
This is the whole trick, so here it is plainly.
- MX is about receiving. It tells the world: “if you’re sending mail to this domain, deliver it here.” It has nothing at all to do with mail you send.
- SPF (Sender Policy Framework) is about sending. It’s a list that says: “these are the servers allowed to send mail on behalf of this domain.”
When your email arrives at Gmail, Gmail doesn’t check your MX record. It checks your SPF record and asks: “is the server handing me this email on the list?”
Your email now comes from the relay. If the relay isn’t on your SPF list, Gmail sees a stranger sending mail in your name. That looks exactly like spam, so that’s where it goes.
The twist
So you add the relay to SPF. Easy. Except many people do it by creating a second SPF record next to the old one.
That makes it worse. The rules say a domain can only have one SPF record. With two, receiving servers don’t pick the better one. They give up and treat SPF as broken entirely. You’ve gone from “one sender missing” to “no valid list at all.”
The fix is one record with everything in it:
v=spf1 include:your-relay.example ~allOne line, every sender you use, and a rule at the end saying what to do with everyone else.
The seal as well as the list
SPF has a sibling worth setting up at the same time: DKIM (DomainKeys Identified Mail). SPF says who’s allowed to send. DKIM puts a digital seal on each email so the receiver can check it wasn’t tampered with and really came from your domain.
Then DMARC (Domain-based Message Authentication, Reporting and Conformance) ties them together and tells receivers what to do when checks fail. Start it on p=none, which reports problems without acting on them, and tighten it once everything passes.
How to check yours
Send an email to a Gmail address, open it, and choose “Show original.” Gmail tells you whether SPF, DKIM and DMARC each passed or failed. Or send one to mail-tester.com, which scores the whole setup and tells you what’s wrong in plain language.
The lesson
When something breaks, the first thing to ask isn’t “which setting is wrong?” It’s “which part of the system is actually doing this job?” MX was never going to fix a sending problem, however many times you check it.
That’s true well beyond email. Half of debugging is finding out you were staring at the wrong component.