Fix Gmail 550 5.7.26 on DirectAdmin and VPS: DMARC-Safe Runbook for 2026

If Gmail is bouncing your message with 550 5.7.26, the practical meaning is simple: Gmail could not authenticate your mail strongly enough for the way your domain is set up. In the common case, both SPF and DKIM failed. In the stricter DMARC case, one or both may exist, but neither is aligned with the domain in your visible From: header. That is why the two most common bounce texts are either This email has been blocked because the sender is unauthenticated or Unauthenticated email from example.com is not accepted due to domain's DMARC policy. These are not random Gmail errors. They are authentication failures with very specific causes.

In our experience managing DirectAdmin mail stacks and self-managed VPS senders, admins waste the most time on 5.7.26 when they treat it like a generic delivery issue. It is not. It is usually one of these:

• The sending IP is not authorized in SPF.
• The message is not DKIM-signed, or the public DKIM key is missing or wrong in DNS.
• The message passes SPF or DKIM for one domain, but your visible From: header uses another domain, so DMARC alignment fails.
• A web form, PHP script, cron job, or app is sending as someone else's domain.
• On DirectAdmin, external DNS or outbound IP routing does not match what Exim is actually doing.

This runbook is for exactly that. Not a broad deliverability essay. Not a theoretical DNS overview. A practical fix path for DirectAdmin hosting and VPS-based mail sending, with DNS checks, Exim checks, and the common WordPress and app-level mistakes mapped step by step.

What Gmail 550 5.7.26 actually means

Google’s current sender guidance boils down to this: all senders to Gmail should authenticate with SPF or DKIM, and DMARC passes only if the authenticating domain matches the domain in the visible From: header. Google’s SMTP error reference then maps the actual bounce codes to the failure type. 550 5.7.26 is the code you see when the sender is unauthenticated, when SPF hard-fails, or when the message is rejected due to the sending domain’s DMARC policy. That distinction matters because “I have SPF” and “I pass DMARC” are not the same thing. :contentReference[oaicite:1]{index=1}

The shortest accurate explanation is this:

• SPF asks whether this server IP is allowed to send for this domain.
• DKIM asks whether the message was signed and the signature validates against DNS.
• DMARC asks whether SPF or DKIM passed for the same domain the user sees in the From: header.

That last point is what breaks non-expert setups. A message can look “authenticated enough” in a superficial test and still get rejected by Gmail because the aligned domain is wrong.

Read the bounce before you touch DNS

Do not start by changing records blindly. Start by reading the exact rejection Gmail returned. On DirectAdmin and most VPS mail stacks using Exim, the evidence is usually in /var/log/exim/mainlog.

grep -i "5.7.26" /var/log/exim/mainlog
grep -i "sender is unauthenticated" /var/log/exim/mainlog
grep -i "DMARC policy" /var/log/exim/mainlog

You are looking for lines like these:

550-5.7.26 This email has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF example.com with ip: 203.0.113.10 = did not pass

550-5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy.

If the bounce shows both SPF and DKIM failed, start with DNS and signing. If it specifically says the mail is rejected due to the domain’s DMARC policy, focus on alignment first. That often means the message is being sent with the wrong visible From: domain or the wrong envelope sender.

Step 1: identify the real sending path

This is the step people skip, and it is why they keep fixing the wrong thing. Ask which system is actually originating the message.

• A DirectAdmin mailbox sending through SMTP AUTH
• A website on shared hosting using PHP mail or local sendmail
• A WordPress plugin using SMTP
• An app on a VPS sending directly through Exim or another MTA
• A cron job, backup script, or monitoring system sending alerts
• A third-party sender using your domain in From:

Google’s SPF setup guide explicitly says your SPF record has to include all systems that send mail for your domain, including web servers, on-prem servers, outbound gateways, contact forms, and third-party services. If you do not identify the actual sender first, you will keep editing records that do not match reality. :contentReference[oaicite:2]{index=2}

Step 2: verify SPF against the real sending IP

SPF is not “does the domain have a TXT record.” SPF is “does the domain authorize this exact sender path.”

dig +short TXT example.com
dig +short MX example.com
dig +short A mail.example.com

If your domain sends mail from the server directly, your SPF must authorize that server IP or a hostname that resolves to it. On simple DirectAdmin setups, a minimal record might look like this:

v=spf1 a mx ip4:203.0.113.10 -all

But do not copy that blindly. If the domain also sends from Microsoft 365, Mailgun, Brevo, a CRM, or a marketing platform, all of those senders must be represented too. This is exactly how teams back themselves into SPF breakage. They add one sender, forget the website or relay, and Gmail sees the mail coming from an IP the domain never authorized.

If you need to clean up lookup sprawl while doing this, ServerSpan already has a related runbook on SPF lookup limits, and the ServerSpan tools page is a practical place to validate and rebuild basic SPF and DMARC text without guessing.

Step 3: verify DKIM signing and DNS publication

DirectAdmin’s docs are blunt on this point: each domain should have SPF, DKIM, and DMARC, and if you use external DNS, the DKIM TXT record must be copied there. Otherwise outbound mail may still be signed locally, but verification fails remotely because receivers cannot fetch the correct public key. DirectAdmin explicitly warns that this is worse than having no DKIM at all. :contentReference[oaicite:3]{index=3}

On DirectAdmin, the practical checks are:

• Is DKIM enabled for the domain in the panel?
• If the domain uses external DNS, was the DKIM TXT record copied there?
• Is the server actually signing mail for that domain?
• Does the selector in the message match the selector published in DNS?

On the server side, DirectAdmin documents both panel-based DKIM enablement and a console method:

cd /usr/local/directadmin/scripts
./dkim_create.sh example.com nodns force

Then query the published key using the actual selector for the domain:

dig +short TXT selector._domainkey.example.com

If the server signs outbound mail but DNS has no matching DKIM key, Gmail will report DKIM as failed, and 5.7.26 becomes very likely.

Step 4: fix DMARC safely, not theatrically

Google’s DMARC docs are clear about rollout order: set up SPF and DKIM first, let them authenticate mail for at least 48 hours, and only then turn on DMARC enforcement. If you publish p=reject before your real sender paths are aligned, you are creating your own outage. :contentReference[oaicite:4]{index=4}

A safe starting DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100

That is not a forever policy. It is a validation phase. Once SPF or DKIM is passing and aligned, you can move toward quarantine or reject. If the domain is already on p=reject and legitimate mail is bouncing, the DMARC-safe emergency move is to temporarily relax the policy while you fix SPF and DKIM. Then tighten it again. Do not leave a broken domain on none indefinitely and pretend the job is done.

Also note Google’s alignment rule. DMARC passes when SPF or DKIM passes for the same domain that appears in the visible From: header. This is the part many admins miss. “A DKIM signature exists” is not enough. It has to align. :contentReference[oaicite:5]{index=5}

Step 5: stop sending contact forms as the visitor’s address

This is one of the most common 5.7.26 causes on shared hosting, DirectAdmin, and small VPS websites.

A contact form plugin takes what the visitor typed into the email field and uses it as the visible From: address. That seems intuitive. It is also wrong. If a visitor enters someone@gmail.com and your website sends the message from your own server as if it were from someone@gmail.com, Gmail will reject it because your server is not authorized to send mail for gmail.com. DMARC is doing exactly what it is supposed to do.

The correct pattern is:

• From: a mailbox on your own domain, such as forms@example.com
• Reply-To: the visitor’s actual email address

That one change fixes a huge percentage of “my website suddenly cannot send to Gmail” tickets.

Step 6: fix DirectAdmin and Exim alignment issues

DirectAdmin has added stricter Exim sender validation in recent releases. Since 1.680, Exim can block user attempts to spoof the sender address by checking the SMTP-authenticated username against the SMTP MAIL FROM envelope sender. That is a good change, because it prevents one of the classic causes of DMARC and DKIM confusion: authenticated users sending mail from domains or addresses they should not be using. :contentReference[oaicite:6]{index=6}

Operationally, this means you should not build mail workflows that authenticate as one mailbox but send with an unrelated sender domain just because it “used to work.” Even when Gmail does not reject it outright, you are creating alignment debt.

If you are intentionally rewriting senders or handling app-originated mail in custom ways, revisit your Exim behavior and your app configuration together. ServerSpan’s related article on Exim address rewriting and client TLS issues is relevant here because sender rewriting can either repair or destroy alignment depending on how it is done.

Step 7: if the domain sends from a dedicated IP, make Exim and DNS agree

DirectAdmin also documents a very specific failure mode for multi-domain systems using dedicated IPs: Exim may need to send using the domain’s dedicated IP and matching HELO data, not the server’s default IP. If your SPF record authorizes the dedicated IP but Exim still sends from the main server IP, Gmail sees a mismatch and SPF fails. :contentReference[oaicite:7]{index=7}

da config-get add_domain_to_domainips

da config-set add_domain_to_domainips 1
systemctl restart directadmin

da taskq --run="action=rewrite&value=domainips"
da taskq --run="action=rewrite&value=helo_data"

DirectAdmin’s docs show the relevant files as:

/etc/virtual/domainips
/etc/virtual/helo_data

And the forward-confirmed reverse DNS should line up too. If the mail domain sends from mail.example.com, the A record, PTR, and Exim HELO identity should not point all over the place. That is not only a reputation issue. It often becomes the next blocker right after you fix 5.7.26.

Step 8: on a VPS, fix the app path, not just the DNS

On self-managed VPS systems, 5.7.26 is often not a DirectAdmin problem at all. It is an application problem.

• The app sends as notifications@example.com but the server IP is not in SPF.
• The app sends locally but no DKIM signer is configured.
• The app uses a visible From: on one domain and an envelope sender on another.
• The app uses PHP mail() or a local sendmail path with no authenticated SMTP discipline.

If this is a VPS and the mail volume matters, the cleanest fix is often to make the app submit through authenticated SMTP using the real domain mailbox or relay path that already has correct SPF and DKIM coverage. That is far safer than letting each app improvise sender behavior.

Be honest here. If your VPS is acting as web server, app server, cron sender, and mail sender with no clear ownership of DNS, MTA policy, and app sender settings, you do not have a mail setup. You have a pile of defaults that happened to work until Gmail enforced them harder.

The short validation sequence that actually works

1. Read the actual Gmail bounce in /var/log/exim/mainlog.
2. Identify the real sending path: mailbox, website, app, cron, relay, or third-party sender.
3. Check SPF against the exact sending IP.
4. Check that DKIM is enabled and the public key exists in live DNS.
5. Check DMARC and verify that SPF or DKIM aligns with the visible From: domain.
6. If it is a website form, stop using the visitor’s address in From:. Use Reply-To instead.
7. If it is DirectAdmin on dedicated IPs, verify domainips, helo_data, and PTR alignment.
8. Retest with a real Gmail mailbox and inspect the received message headers or bounce result.

If you want a quick reality check before retesting production mail, ServerSpan’s toolbox is the right place to sanity-check authentication records, and DirectAdmin itself recommends testing outbound mail quality after publishing SPF, DKIM, and DMARC. :contentReference[oaicite:8]{index=8}

What usually goes wrong during the fix

• You fix SPF but ignore DKIM. Gmail may stop showing one 5.7.26 variant and expose the next weakness.
• You publish DKIM locally but forget external DNS. DirectAdmin explicitly warns about this.
• You have a DMARC record on reject before SPF and DKIM are stable.
• You authenticate as one mailbox and send as another domain.
• Your website sends contact forms as the visitor’s address.
• Your domain’s SPF authorizes one IP, but Exim sends from another.

A production insight here: the longest 5.7.26 tickets are not the ones with the most technical depth. They are the ones where more than one sender path exists and nobody wrote them down. One web app uses local Exim. One mailbox uses SMTP AUTH. One CRM uses a third-party relay. One backup system sends from the VPS itself. Then everyone argues about “the SPF record” as if there were only one sender.

When to stop patching and fix the mail layer properly

If this is one hosted site with one mailbox, you can usually clean it up yourself. If this is a shared hosting portfolio, a reseller environment, or a VPS stack with multiple apps, sender paths, and customer domains, the real problem is usually not just one Gmail bounce. The real problem is that outbound mail policy is being managed ad hoc.

For teams on panel-based hosting, ServerSpan’s web hosting gives you a DirectAdmin-backed path with a more controlled mail layer than improvised website-side sending. For custom stacks and apps that need real sender ownership, IP control, and MTA discipline, a virtual server is the right place to do it properly instead of fighting around shared hosting assumptions.

And if your actual issue is not Gmail alone but recurring mail-stack cleanup, it is usually cheaper to fix the policy once than to keep losing time on bounce-by-bounce firefighting.