Without SPF, DKIM and DMARC, anyone can send email that appears to come from your domain, while your genuine messages land in spam. The three DNS records are free, take an afternoon to set up, and the large mailbox providers expect them from bulk senders.
SPF tells the receiving server which IP addresses may send for your domain; -all means any other source is rejected, while ~all only marks it. DKIM adds a cryptographic signature to the message header, checked against the public key in DNS, so a changed body or a sender without the key fails verification. DMARC ties both to the domain visible in the From field and tells receivers what to do on failure and where to send reports. Without DMARC, SPF and DKIM are hints; with it, they become policy.
Large providers first check that the sending IP has a PTR record that resolves back to the server's name; without it, the message can be rejected before SPF is even evaluated. TLS must be on for every submission port, with a valid certificate, so passwords never travel in clear text. The server relays mail only for authenticated users or your own networks, because an open relay lands on blocklists within hours. Limit the send rate per account so one stolen password cannot send ten thousand messages. Transactional mail leaves through a separate relay, on its own subdomain.
Mail on a company domain almost always contains personal data, so GDPR Article 32 applies. A compromised mailbox sending phishing to your customers is an incident you must assess and, if data was accessed, report to ANSPDCP within 72 hours. For entities under OUG 155/2024, protection of communications and multi-factor authentication are explicit minimum measures. Invoices sent by email are accounting documents: an IBAN swapped in a forged invoice sent in your name is exactly the scenario DMARC p=reject stops.
| Mechanism | Where it is configured | Recommended value | What it prevents |
|---|---|---|---|
| SPF | TXT on the domain | v=spf1 ip4:203.0.113.25 include:relay.example.net ~all, with DMARC p=reject | Sending from unauthorised servers |
| DKIM | TXT on selector._domainkey + signing in the MTA | RSA 2048, yearly rotation | Content tampering, sender forgery |
| DMARC | TXT on _dmarc | p=reject after a p=none period with rua | Forging the visible From address |
| PTR (rDNS) | At the IP provider | mail.example.ro → IP → mail.example.ro | Rejection before any other check |
| TLS | Postfix / Mailu | Valid certificate on 25, 587, 465 | Interception of passwords and messages |
| Relay | smtpd_relay_restrictions | Authenticated or own networks only | Open relay, blocklists |
example.ro. TXT "v=spf1 ip4:203.0.113.25 include:relay.example.net ~all"
s2026._domainkey.example.ro. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq...public-key...IDAQAB"
_dmarc.example.ro. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.ro; adkim=s; aspf=s; pct=100"# /etc/postfix/main.cf (fragment) — port 25, server to server: opportunistic TLS
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.ro/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.ro/privkey.pem
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_client_connection_rate_limit = 30
# /etc/postfix/master.cf — submission (587): TLS REQUIRED and authenticated users only
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,rejectdig +short TXT example.ro
dig +short TXT _dmarc.example.ro
dig +short -x 203.0.113.25
openssl s_client -starttls smtp -connect mail.example.ro:587 -servername mail.example.ro </dev/null | grep -E "Verify|subject="The application sent reset emails through the same server as the staff. One poorly received marketing campaign damaged the sender reputation and resets began landing in spam. Moving the application to a separate relay, with its own subdomain and DKIM key, isolated the two flows.
Clients received fake invoices 'from' the firm with a different IBAN, and the domain had no DMARC. SPF, DKIM and DMARC at p=none with reports exposed three unauthorised sources in the first week; after the move to p=reject the forged messages stopped reaching inboxes.
Until the DMARC reports show that every legitimate source, meaning your own server, the application, the newsletter tool and invoicing, passes SPF or aligned DKIM. That usually takes two to four weeks. Move to p=quarantine first, perhaps with pct=25, then to p=reject.
Yes, if you want control over your data and a fixed cost, and someone will maintain it: updates, sender reputation, DMARC reports. Mailu bundles Postfix, Dovecot, antispam and webmail into a manageable Docker installation. If nobody can maintain it, a hosted service is the safer choice.
Because reputation is calculated per domain and per IP. A badly received campaign or one compromised account hurts the delivery of everything sent from the same source. With a dedicated subdomain and relay, password resets and invoices reach the inbox whatever happens to the newsletter.
A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.