Platform Emails Going to Spam? SPF, DKIM and DMARC Explained

A member makes a deposit, and the confirmation email goes to spam. They do not blame Gmail — they blame you, and they open a support ticket with an edge in it. Email deliverability is one of the least glamorous and most trust-critical parts of running a platform. The good news: it mostly comes down to three DNS records and a handful of habits.

The three records that decide where your mail lands

SPF: who may send for your domain

An SPF record is a line in your DNS listing the servers allowed to send email for your domain. Without it, anyone on earth can send mail claiming to be you, and receiving filters treat your genuine messages with suspicion as a result. With it, your platform server and your business mailbox are on the guest list; spammers are not.

The detail that catches people out: every sender has to be on that list. If your platform sends from the server but your support mailbox sends through a separate mail provider, both belong in the record. Miss one, and that stream of perfectly genuine mail starts failing checks — usually discovered by a member, in a ticket, after a payout notice never arrived.

DKIM: a signature on every message

DKIM attaches a cryptographic signature to each outgoing email. The receiver checks it against a key in your DNS and knows two things: the mail really came from your domain, and nobody altered it on the way. Unsigned mail from a financial platform is exactly what modern filters are trained to distrust.

The signature only counts if the key in your DNS actually matches the private key your server signs with. Publish a key the server does not hold — after a migration, say, or a panel reinstall — and your mail leaves unsigned while every settings page still insists DKIM is on. It is the quietest failure in this whole article, and the testing section below is how you catch it.

DMARC: the policy that ties them together

DMARC tells receivers what to do with mail that fails SPF or DKIM — monitor it, quarantine it, or reject it. Even starting with a monitoring policy improves how filters score your domain, and the reports it generates show you who else is sending (or pretending to send) as you.

DMARC also adds the check the other two lack: the domain your member actually sees in the From line must line up with the domains SPF and DKIM authenticated. That alignment rule is what stops a lookalike sending setup from passing on a technicality. In practice, roll it out in stages — monitor first while you read the reports, then quarantine, then reject once you are sure no legitimate sender has been left out.

Setting all three up properly is a one-time job; it is also one of the services in our services hub, because doing it half-right is worse than it looks — a broken DKIM key quietly poisons a domain for weeks. Our Business Email Setup service covers exactly this ground: SPF and DKIM configured on a mailbox on your own domain at the $20 Basic tier, and the full set — SPF, DKIM and DMARC, up to five mailboxes — at $50, with the mail tested to confirm it lands in the inbox.

Read your DMARC reports, at least at first

The reports DMARC generates are the most underused diagnostic in platform email. The big mailbox providers send aggregate summaries of the mail they received claiming to be from your domain: which servers sent it, how much of it passed authentication, and how much did not. In the first weeks after setup, those reports are how you find the sender you forgot — an old contact form, a second mailbox provider, a test install on a subdomain — before a stricter policy starts rejecting its mail. Later, they are an early-warning system: a source you do not recognise, sending as you and failing, is spoofing you can act on while it is still small.

Habits that help (and hurt)

• Send from your own domain. Platform mail should come from addresses on your domain, on proper business email — never from a free mailbox.
• Warm up a new domain. A brand-new domain sending hundreds of messages on day one matches the spammer profile almost exactly. Ramp volume over the first weeks.
• Keep content clean. Shouting subject lines, shortened URLs and image-only emails are classic spam signals.
• Process your bounces. Repeatedly mailing dead addresses damages sender reputation for every other member too.
• Separate the streams. Transactional mail (deposits, resets) is sacred. Marketing blasts from the same domain put it at risk; use a subdomain if you must send them.
• Retest after every change. A hosting move, a new mailbox provider or a DNS tidy-up can silently break one of the three records. The records point at senders; change a sender and the record has to change with it.

Test it the way a member experiences it

Create test accounts at the major mailbox providers and trigger every email your platform sends: signup, deposit confirmation, payout notice, password reset. Check where each lands and view the authentication results in the message headers — you want to see SPF pass, DKIM pass, DMARC pass. Fifteen minutes of this finds problems your members would otherwise find for you, in public, at the worst time. It belongs on the same pre-launch checklist as the items in our GoldCoders launch checklist.

Look at the headers, not just the folder. Mail can reach the inbox on a good day with a broken signature underneath, because reputation carried it — and reputation is a cushion, not a fix. The header lines are the evidence: they say plainly which checks ran and which passed, for that exact message, from that exact stream.

Why this matters beyond the inbox

Deliverability is quietly a security feature too: SPF, DKIM and DMARC are what stop strangers from sending convincing fake “payout problem” emails in your name. If you have not already, read our platform hardening checklist — your domain’s email setup is part of your platform’s defences.

From our own desk

Our own domain passes SPF, DKIM and DMARC — we verified them header by header when we set up this store’s mail, because our order confirmations and support replies travel through the same pipe our customers rely on. When a single one of those records was wrong during setup, our own test mail landed in spam within the hour. That is how fast this shows up. If you would rather not live in DNS records, this is the whole job of our business email setup — SPF, DKIM and DMARC configured and tested with real messages.

The bottom line

Publish correct SPF, DKIM and DMARC records, send from your own domain on real business email, warm up gradually, and test every message type like a member. Your confirmations will land in the inbox — and members will stop wondering where they went.