DMARC Creator for Self-Hosted Email — Authentication for Your Mail Server

Running your own mail server gives you full control over your email infrastructure. It also means there is no provider handling authentication on your behalf. If you are running Postfix, Exim, Dovecot, iRedMail, Mail-in-a-Box, or any other self-hosted mail stack, you are responsible for every layer of email authentication, and DMARC is the piece that ties it all together.

This guide explains why DMARC is especially important for self-hosted email, walks through the setup process, and covers the pitfalls that catch most self-hosted operators off guard.

Why Self-Hosted Email Needs DMARC More Than Anyone

When you use a managed provider like Google Workspace or Microsoft 365, they handle much of the authentication plumbing for you. SPF records often come preconfigured. DKIM signing is a toggle in an admin panel. Deliverability reputation rides on shared infrastructure that the provider actively maintains.

With a self-hosted server, none of that exists. Your IP address has its own reputation, your SPF record is entirely your responsibility, and DKIM keys need to be generated, published, and rotated by you. If any of these pieces drift out of alignment, your email starts failing authentication checks silently. Our email authentication guide explains how SPF, DKIM, and DMARC work together to form a complete authentication stack.

DMARC is what makes this visible. Without a DMARC record, you have no way to know whether receiving servers are rejecting or quarantining your mail due to authentication failures. With DMARC in monitoring mode, you get daily aggregate reports showing exactly what is passing and what is failing, so you can catch problems before they snowball.

Setting Up the Prerequisites: SPF and DKIM

Before DMARC can do its job, your self-hosted mail server needs both SPF and DKIM in place and working correctly.

SPF for Self-Hosted Mail

Your SPF record tells receiving servers which IP addresses are authorized to send mail for your domain. For a self-hosted server, this typically means including the public IP address of your mail server. A basic SPF record looks like this:

v=spf1 ip4:203.0.113.25 -all

If your server also relays mail through a smarthost or you use an external service for transactional email, those need to be included too. Build a complete SPF record at spfcreator.com to make sure nothing is missed.

Common self-hosted SPF mistakes include forgetting to update the record after an IP address change, omitting backup MX servers, and accidentally exceeding the ten DNS lookup limit when including multiple external services.

DKIM for Self-Hosted Mail

DKIM requires generating a key pair, publishing the public key in DNS, and configuring your mail server to sign outgoing messages with the private key.

On Postfix, most people use OpenDKIM or rspamd for signing. On Exim, DKIM signing is built in but needs explicit configuration in the transport section. Tools like iRedMail and Mail-in-a-Box often configure DKIM during initial setup, but you should verify the keys are published and signing is active. If you manage DNS through a control panel, our DMARC for cPanel guide covers the DNS side of things.

Generate DKIM keys and DNS records at dkimcreator.com. After publishing the public key in your DNS, send a test email and check the headers to confirm DKIM signatures are present and valid.

Common Self-Hosted Pitfalls That Break Authentication

Self-hosted mail servers face a set of challenges that managed providers handle automatically. Knowing these upfront saves hours of debugging.

Creating Your DMARC Record

With SPF and DKIM confirmed and working, you are ready to create your DMARC record. For self-hosted email, we strongly recommend starting with p=none to collect data before enforcing anything.

Using DMARC Reports to Catch Configuration Drift

For self-hosted mail, DMARC reports are not just a setup tool — they are an ongoing monitoring mechanism. Server configurations change. IP addresses rotate. Packages update. DMARC aggregate reports will show you when something breaks.

Pay attention to reports that show your own server's IP failing SPF or DKIM. This usually means something changed in your configuration. A common scenario is an OS upgrade that resets OpenDKIM's signing table, or a firewall change that causes outgoing mail to use a different source IP than the one in your SPF record.

If you also use external services alongside your self-hosted server, reports will show whether those services are properly authenticated too. This is particularly useful when a marketing team adds a new email tool without telling the person who manages DNS.

Protecting Non-Sending Domains

If you own multiple domains but only run a mail server on one of them, the others still need DMARC records. Our guide on DMARC for subdomains explains how to handle subdomain policies alongside your main domain. Domains without any email authentication are prime targets for spoofing. For any domain that does not send email, publish a simple reject policy:

v=DMARC1; p=reject; sp=reject;

Pair this with a restrictive SPF record (v=spf1 -all) and no DKIM keys. This tells the world that no email should ever come from that domain, and any that does should be rejected.

Monitor Your DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.