DKIM, SPF, and DMARC Mail Server VPS Hosting

SPF, Sender Policy Framework, declares which IPv4 and IPv6 addresses are allowed to send mail for your domain. The record is a TXT entry at your domain root that lists IP addresses or include statements pointing at other domains. Anubiz Host offshore VPS customers should publish an SPF record that lists their VPS sending IPs and optionally a third-party relay if used during transition. The mechanics matter. Use -all at the end of your SPF record to indicate a hard fail for any unauthorized sender. Soft fail with tilde-all is a transitional state, not a permanent home. Avoid SPF records that exceed 10 DNS lookups because remote MTAs will return permerror, which is worse than no SPF at all. For Anubiz Host customers running a single VPS, the SPF record is usually just v=spf1 ip4:your.vps.ip -all. Simple and unambiguous.

DKIM, DomainKeys Identified Mail, adds a cryptographic signature to every outbound message that receivers can verify against a public key published in DNS. Without DKIM, your DMARC policy cannot align and your deliverability suffers significantly. On an Anubiz Host offshore VPS, install OpenDKIM or rspamd dkim_signing as the signing daemon. Generate a 2048-bit RSA key per domain, publish the public key as a TXT record at selector._domainkey.yourdomain.com, and configure Postfix to call the signing milter on every outbound message. Rotate DKIM keys at least once per year by deploying a new selector, publishing the new public key, waiting for DNS propagation, then switching the signing daemon to the new selector. Keep the old selector live long enough that pre-rotation mail in the wild can still be verified.

DMARC, Domain-based Message Authentication, Reporting and Conformance, ties SPF and DKIM together with an alignment requirement: the From header domain must match either the SPF or DKIM signing domain. DMARC also lets you publish a policy, none, quarantine, or reject, and request aggregate and forensic reports from remote MTAs. Anubiz Host customers should start at p=none with a rua reporting address, monitor reports for two to four weeks, fix any alignment issues that surface, then promote to p=quarantine, monitor for another two weeks, and finally promote to p=reject for full enforcement. Skipping the gradual rollout almost always causes preventable delivery problems. For aggregate reporting, use a parser like parsedmarc to ingest the daily XML reports from major receivers into a dashboard. The first few weeks of reports almost always surface forgotten subdomains or third-party senders you did not know about, and fixing those before enforcement is the entire point of starting at p=none.