How I fixed system email blocking (SPF/DKIM) on DirectAdmin

If customer mail works but system notifications are rejected with 550-5.7.26, the issue is usually hostname identity authentication, not customer domain DNS.

The blind spot: hostname authentication

DirectAdmin system alerts may be sent using the server hostname (srv1.meudominio.com) as sender identity.

Without SPF/DKIM/DMARC on that hostname, providers such as Gmail may reject:

550-5.7.26: Gmail requires all senders to authenticate with either SPF or DKIM.

Fast diagnosis

In Exim logs (/var/log/exim/mainlog), check for:

SPF failure for hostname identity
missing DKIM signature for hostname

Customer domain auth can be correct while hostname auth is still broken.

Applied fix

1) Prepare mail config path and generate hostname DKIM

mkdir -p /etc/virtual/srv1.meudominio.com
chown mail:mail /etc/virtual/srv1.meudominio.com
chmod 711 /etc/virtual/srv1.meudominio.com

/usr/local/directadmin/scripts/dkim_create.sh srv1.meudominio.com

2) Configure DNS for hostname

Required records:

hostname A record
hostname SPF TXT
hostname DKIM selector TXT
hostname DMARC TXT

Example:

srv1 IN A 123.123.123.123
srv1 IN TXT "v=spf1 ip4:123.123.123.123 ~all"
x._domainkey.srv1 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.srv1 IN TXT "v=DMARC1; p=none"

Ensure reverse DNS (PTR) also points to the same hostname.

3) Validate zone syntax before reload

named-checkzone meudominio.com /var/named/meudominio.com.db

Only reload DNS service after clean validation.

Post-fix note: reputation recovery

Even with correct auth, reputation may take time to recover after repeated past blocks. Keep legitimate traffic steady and monitor delivery logs.

In DirectAdmin environments, authenticating customer domains is not enough. Server hostname must also have SPF, DKIM, and DMARC to ensure reliable system notification delivery.

This post is licensed under CC BY-NC.