Zum Hauptinhalt springen
tsecurity.de LIVE
Echtzeit-Radar & Feeds
Alle RSS Feeds
👥 Community & Social
YouTube Security VideosAndroid Police: Samsung is smashing records! #shorts #tech #phones(21.09.2026 um 13:55 Uhr)
YouTube Security Videosheise & c't: Bundesnetzagentur wollte diesen Futterautomaten verbieten(21.09.2026 um 13:53 Uhr)
YouTube Security VideosNeil Patel: Your Google Traffic Isn't An Asset It's A Loan #shorts(21.09.2026 um 14:05 Uhr)
Windows Tipps & SecurityF-14 A Tomcat Top Gun endlich als Revell Klemmbausteinmodell erhältlich(21.09.2026 um 14:27 Uhr)
Sichere ProgrammierungShow the Hand-Back Sample Before Approving an Agent Score(21.09.2026 um 14:15 Uhr)
Sichere ProgrammierungHybrid retrieval in one Postgres query: RRF over tsvector + pgvector(21.09.2026 um 14:15 Uhr)
YouTube Security VideosAndroid Police: Samsung is smashing records! #shorts #tech #phones(21.09.2026 um 13:55 Uhr)
YouTube Security Videosheise & c't: Bundesnetzagentur wollte diesen Futterautomaten verbieten(21.09.2026 um 13:53 Uhr)
YouTube Security VideosNeil Patel: Your Google Traffic Isn't An Asset It's A Loan #shorts(21.09.2026 um 14:05 Uhr)
Windows Tipps & SecurityF-14 A Tomcat Top Gun endlich als Revell Klemmbausteinmodell erhältlich(21.09.2026 um 14:27 Uhr)
Sichere ProgrammierungShow the Hand-Back Sample Before Approving an Agent Score(21.09.2026 um 14:15 Uhr)
Sichere ProgrammierungHybrid retrieval in one Postgres query: RRF over tsvector + pgvector(21.09.2026 um 14:15 Uhr)
Intelligence View
⚡ tsecurity.de Intelligence

Self-hosting your email? SPF, DKIM and DMARC decide your inbox rate

I moved outbound email for a couple of side projects off a hosted ESP last year, mostly to stop paying per-seat for what is basically a solved problem. Postfix took an afternoon. Then I sent the first real batch and watched Gmail quietly…

0
↗ Quelle (dev.to)
Reagiere als Erste:r — dein Feedback zählt!

I moved outbound email for a couple of side projects off a hosted ESP last year, mostly to stop paying per-seat for what is basically a solved problem. Postfix took an afternoon. Then I sent the first real batch and watched Gmail quietly file most of it under spam and throttle the rest to a trickle. That's when it landed that "I configured SPF" and "Gmail trusts me" are two completely different sentences.



Deliverability is the part that quietly eats your week. Here's how I think about it now, plus the actual records that get most of your mail into the inbox instead of the spam folder.



Two things earn you a spot in the inbox, and providers weigh them separately. One is proving the mail is genuinely from you, which is pure crypto and DNS and takes about a weekend. The other is a track record of people wanting your mail, which is behavior, and that takes months. Fail the first and you never get to play for the second. Gmail bins you before anyone reads the subject line.






SPF, DKIM, and DMARC each do one job



People list these as one checklist item. They're not interchangeable.



SPF is a DNS record naming the IPs allowed to send for your domain. One catch trips almost everyone. It checks the envelope sender, the Return-Path / MAIL FROM your servers negotiate, not the From: address your recipient actually reads. So on its own it can't stop someone spoofing your domain in the visible From, and it breaks the moment your mail is forwarded and the relaying IP changes. Leave it off entirely, though, and some receivers won't bother evaluating the rest.




example.com.  IN TXT  "v=spf1 mx ip4:203.0.113.10 -all"






DKIM signs each message with a private key and publishes the matching public key in DNS at a selector. This is the strong one. It survives ordinary forwarding, which SPF can't, and it proves the signed headers and body weren't altered in transit. There's a caveat every mailing-list operator will remind you of. If a forwarder rewrites what it signed, like a list appending a footer or tagging [list-name] onto the subject line, the signature breaks too, and that gap is exactly what ARC was built to patch.




mail._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki...QAB"






DMARC ties the two together, and its real mechanism is alignment, not a plain pass or fail. It passes if SPF or DKIM passes and the passing domain lines up with the From: address the recipient sees. That's why "SPF passed but DMARC failed" is a real and maddening thing: your envelope domain checked out, it just didn't match the visible From. When nothing aligns, DMARC tells the receiver what to do, and if you ask for them, it emails you reports.




_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"






Start at p=none, but include the rua= address from day one. A bare p=none sends you nothing, and you'll assume it's broken. Watch the aggregate reports for a week or two, then tighten to quarantine and eventually reject.



The one that cost me an actual day was dumber than any of this. A single wrong character in the DKIM record when I pasted it into DNS. It looked configured. The signature just silently failed to verify, so I'd quietly lost my strongest trust signal and didn't notice until deliverability slipped days later. Now I always confirm the published key matches the private one before I trust it:




dig +short TXT mail._domainkey.example.com
opendkim-testkey -d example.com -s mail -vvv






opendkim-testkey is the one that actually catches the mismatch. dig only shows you what's published, which looks fine even when it's subtly wrong.






Reputation starts cold, so warm the domain and the IP



Even with perfect auth, a brand-new IP has no reputation. And it isn't only the IP: Gmail and Outlook lean heavily on domain reputation now, and the domain is the part that follows you when you change IPs. So warm both.



Blast your whole list on day one and you'll get throttled or binned. When I brought that fresh IP up, day one was maybe 50 messages, to my most engaged contacts only. As long as bounces and complaints stayed flat I roughly doubled the next day: 50, then a bit over 100, then a few hundred, backing off the instant either number twitched. A clean few thousand a day took about two weeks. For real volume, tens of thousands, plan on a month or more. The gate is a clean previous step, not the calendar.



And never send to a bought or scraped list. Spam traps don't care how good your auth is, and that's the fastest way to tank a domain you can't easily recover.






The unglamorous parts beat good copy



Own your Return-Path and actually process bounces, so you stop hammering dead addresses within a send or two instead of a month later. Feedback loops are worth the afternoon they take to set up (Microsoft's JMRP, Yahoo's CFL, and the like), so you hear about spam complaints directly instead of inferring them from a sagging open rate. And keep the list clean. Hard bounces get dropped on the spot, and anyone who hasn't opened in six months gets pruned.



Content and subject lines matter, but they sit way down this list. Every "why is my mail in spam" fire I've actually chased came back to auth or a dirty list. Almost never the copy.






This post is adapted from a longer write-up I keep on my own KB, the full record-by-record version, if you want every DNS line and gotcha spelled out. Fwiw, I build AcelleMail, a self-hosted email marketing tool (commercial, not open source, before anyone asks), so I stare at this more than is healthy. None of it is product-specific, though. Postfix, Sendy, or something you rolled yourself: same three records. Get those right first.

Ähnliche Beiträge
🔍 Verwandte News

Auch interessante Nachrichten Self-hosting your email? SPF, DKIM and DMARC decide your inbox rate

Thematisch verwandte Begriffe: Selfhosting, your, email, DKIM · 6 Treffer

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Zum Aktualisieren ziehen
ZERO-DAY CVE-2026-94097 | A vulnerability was determined in Netcore NBR200V2 1.3.241127.071246. Th…
Advisory →
TTS Reader • tsecurity.de Voice
tsecurity.de Icon
tsecurity.de App
Offline-Lesen, Eilmeldungen & 0ms Ladezeit

Installiere tsecurity.de direkt auf deinen Home-Bildschirm für das ultimative Vollbild-Magazinerlebnis ohne Browser-Leisten.

Nächster Beitrag
Themen-Radar & Intelligence Matrix
Echtzeit-Taxonomie nach Angriffsvektoren & Plattformen

tsecurity.de Live Threat Radar

🔴 LIVE RADAR
MONITORING
AKTIV
CVE-DATENBANK
LIVE
🔍
Community Radar & Live Chat
Sentinel Bot online • Live-Stream
Dein Cluster: Security Explorer
Match:
lädt…
Verbindung zum Community-Stream wird aufgebaut...
Bearbeitungsmodus — Senden überschreibt deine Nachricht
Community-Puls — was gerade passiert
lädt…
Aktivitäten deiner Analysten
lädt…
Neues Thema oder Eilmeldung einreichen

Reiche interessante Links, Zero-Days oder Debatten ein. Die Community entscheidet per Upvote über die Veröffentlichung.

Heiß diskutierte Einreichungen
🔖 Gespeicherte Artikel
📂 Keine gespeicherten Artikel vorhanden.
Zurück Ziehen Vor
Links: vorheriger Artikel Rechts: nächster Artikel unten: schließen
News NIS-2 Frühwarnung Tier-1 Intel ⏱️ 3 Min vor 10 Min
Artikeldaten werden geladen...

Zurück: vorheriger Vor: nächster
↗ Original-Quelle
Social Reaktionen Deine Reaktion zählt
Einstufung & Relevanz-Poll 0 Stimmen
In sozialen Netzwerken teilen 1-Klick